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

3.0 merge status

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

19 messages Options

Nick

3.0 merge status

I reviewed all my merges and discovered I'd lost changes in:

PRPierFrame>>initialRequest

PRViewCommand>>initialRequest

MAOneToManyComponent>>add

With the corrections in place, Pier appears to working once again. There are a couple of anomalies - the Pier logo doesn't appear on the home screen and I received one walkback while clicking around. I'll investigate these problems later. I've also yet to look at any add-ons including the Pier-Blog.

I've loaded the code into a fresh seaside3.0a5 image (with updated Gofer) and the code loads cleanly.

For reference the load script I used was:

"Load Magritte for Seaside 3"

Gofer new

renggli: 'magritte2';

package: 'Magritte-Model';

package: 'Magritte-Pharo-Model';

package: 'Magritte-Tests-Model';

package: 'Magritte-Tests-Pharo-Model';

package: 'Magritte-Seaside';

package: 'Magritte-Pharo-Seaside';

package: 'Magritte-Morph';

load.

"Load Pier for Seaside 3"

Gofer new

renggli: 'pier2';

package: 'Pier-Core';

package: 'Pier-Pharo-Core';

package: 'Pier-Model';

package: 'Pier-Pharo-Model';

package: 'Pier-Tests-Model';

package: 'Pier-Seaside';

package: 'Pier-Pharo-Seaside';

package: 'Pier-Security';

package: 'Pier-Pharo-Persistency';

package: 'Pier-Tests-Security';

load.

PRPierFrame registerAsApplication: 'pier' kernel: (PRKernel new root: (PRPage new title: 'test'; contents: 'Pier on Seaside 3.0'))

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

Julian Fitzell-2

Re: 3.0 merge status

On Fri, Jan 8, 2010 at 12:02 PM, Nick Ager <[hidden email]> wrote:
>
> I reviewed all my merges and discovered I'd lost changes in:
> PRPierFrame>>initialRequest
> PRViewCommand>>initialRequest
> MAOneToManyComponent>>add

Good stuff!

>
> With the corrections in place, Pier appears to working once again. There are a couple of anomalies - the Pier logo doesn't appear on the home screen and I received one walkback while clicking around. I'll investigate these problems later. I've also yet to look at any add-ons including the Pier-Blog.

The logo is broken by the change you committed to
PRViewCommand>>initialRequest:. If I revert that, it shows up. Not
sure why that was done in the 2.8 branch and, if so, whether it is
broken or whether it depends on some other change that hasn't come
over. Perhaps lukas remembers...

I also see that this is broken (it used to work - I think this might
be from the addition of PRFile>>contents?):

http://localhost:8080/pier/environment/style.css

It prints:
-----------
Style.css

#[47 42 32 98 108 117 101 112 114 105 110 ... (and so on)
----------

> I've loaded the code into a fresh seaside3.0a5 image (with updated Gofer) and the code loads cleanly.

I loaded it and made a few corrections to the merge (easier to spot
when I have some memory of what I did before). Seems to more or less
work with the exception of files, as noted above.

Julian

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

Lukas Renggli

Re: 3.0 merge status

In reply to this post by Nick

Thank you for these scripts. I use them to load the new code into
Seaside 3.0 images, see
<http://hudson.lukas-renggli.ch/job/Seaside%203.0/>.

This job builds a Seaside 3.0, saves it; loads Magritte 2 into that
image, saves it; and finally loads Pier 2 and saves it. It also runs
the tests and generates a report. I haven't yet tried the actual
images, but this should make it easier to see what works and what is
broken.

Lukas

2010/1/8 Nick Ager <[hidden email]>:

> I reviewed all my merges and discovered I'd lost changes in:
> PRPierFrame>>initialRequest
> PRViewCommand>>initialRequest
> MAOneToManyComponent>>add
> With the corrections in place, Pier appears to working once again. There are
> a couple of anomalies - the Pier logo doesn't appear on the home screen and
> I received one walkback while clicking around. I'll investigate these
> problems later. I've also yet to look at any add-ons including the
> Pier-Blog.
> I've loaded the code into a fresh seaside3.0a5 image (with updated Gofer)
> and the code loads cleanly.
> For reference the load script I used was:
> "Load Magritte for Seaside 3"
> Gofer new
> renggli: 'magritte2';
> package: 'Magritte-Model';
> package: 'Magritte-Pharo-Model';
> package: 'Magritte-Tests-Model';
> package: 'Magritte-Tests-Pharo-Model';
> package: 'Magritte-Seaside';
> package: 'Magritte-Pharo-Seaside';
> package: 'Magritte-Morph';
> load.
> "Load Pier for Seaside 3"
> Gofer new
> renggli: 'pier2';
> package: 'Pier-Core';
> package: 'Pier-Pharo-Core';
> package: 'Pier-Model';
> package: 'Pier-Pharo-Model';
> package: 'Pier-Tests-Model';
> package: 'Pier-Seaside';
> package: 'Pier-Pharo-Seaside';
> package: 'Pier-Security';
> package: 'Pier-Pharo-Persistency';
> package: 'Pier-Tests-Security';
> load.
> PRPierFrame registerAsApplication: 'pier' kernel: (PRKernel new root:
> (PRPage new title: 'test'; contents: 'Pier on Seaside 3.0'))
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

rshiple

Re: 3.0 merge status (observations and a code variant)

This was good to hear, as I have been having a pretty rough time building images from scratch recently.

I have made some changes to WAAdmin to stop bogus errors arising in >>register: at: than often relate to register:asApplicationAt: becuase I have a whole set of classes for which I run class-side >>initialization
as a final step before

WAAdmin clearAll.
WAEnvironment initialize.
WAEnvironment reloadApplications.

WAKom startOn: 18080.

There are also many places where OmniBrowser is broken or where classes in O2 have instances being sent messages by OB - I have not even bothered debuggin those as they do not generally impede finding what is needed to get a base image (Squeak 3.10) or Pharo RC-1 (pharo1.0-10502-rc1web09.12.2) to run Seaside 3.0 on Win XP SP3

None of the web app examples would run in my last build (Jan 7) - most impacted by changes that seemed intended for Pier ...

For my non-HTML web markup I was concerned to see htmlEncoder move up a level to the tag parent of WAHtmlDocument and concerned by the state of path methods in WAUrl ( I get there due to walkbacks occurring in a few places )

I have not yet had a script that worked from top to bottom: the last problem was with the script calling an install.st to fileIn so I now pull in Installer on my own first BUT that will not run error-free until I pull in Grease ...

Here is my last list of classes where I comment out the class-side initialize until I have all nec loaded, then uncomment all of those and let fire

WAVersionUploader initialize.
WAWalkbackErrorHandler initialize.
WADevelopmentConfiguration initialize.
WAWalkbackErrorHandler initialize.
WADispatcherBrowser initialize.
WAStatus initialize.
WAVNCController initialize.
SUAllTests initialize.
SULightboxTest initialize.
WAAllTests initialize.
WABrowser initialize.
WACounter initialize.
WAExampleBrowser initialize.
WAMultiCounter initialize.
WARenderCanvas initialize.

Here is my make-shift get-the-classes to fileIn variant for WAAdmin

>>register: aRequestHandlerClass at: aString in: aDispatcher
| path dispatcher |
path := aString subStrings: '/'.
dispatcher := path allButLast
inject: aDispatcher
into: [ :result :each |
result handlers notNil
ifTrue: [
result handlers
at: each
ifAbsent: [ result register: WADispatcher new at: each ] ]
ifFalse: [ result register: WADispatcher new at: each]
].
^dispatcher register: aRequestHandlerClass new at: path last

--- On Sat, 1/9/10, Lukas Renggli <[hidden email]> wrote:

> From: Lukas Renggli <[hidden email]>
> Subject: Re: 3.0 merge status
> To: "Magritte, Pier and Related Tools ..." <[hidden email]>
> Date: Saturday, January 9, 2010, 9:32 AM
> Thank you for these scripts. I use
> them to load the new code into
> Seaside 3.0 images, see
> <http://hudson.lukas-renggli.ch/job/Seaside%203.0/>.
>
> This job builds a Seaside 3.0, saves it; loads Magritte 2
> into that
> image, saves it; and finally loads Pier 2 and saves it. It
> also runs
> the tests and generates a report. I haven't yet tried the
> actual
> images, but this should make it easier to see what works
> and what is
> broken.
>
> Lukas
>
> 2010/1/8 Nick Ager <[hidden email]>:
> > I reviewed all my merges and discovered I'd lost
> changes in:
> > PRPierFrame>>initialRequest
> > PRViewCommand>>initialRequest
> > MAOneToManyComponent>>add
> > With the corrections in place, Pier appears to working
> once again. There are
> > a couple of anomalies - the Pier logo doesn't appear
> on the home screen and
> > I received one walkback while clicking around. I'll
> investigate these
> > problems later. I've also yet to look at any add-ons
> including the
> > Pier-Blog.
> > I've loaded the code into a fresh seaside3.0a5 image
> (with updated Gofer)
> > and the code loads cleanly.
> > For reference the load script I used was:
> > "Load Magritte for Seaside 3"
> > Gofer new
> > renggli: 'magritte2';
> > package: 'Magritte-Model';
> > package: 'Magritte-Pharo-Model';
> > package: 'Magritte-Tests-Model';
> > package: 'Magritte-Tests-Pharo-Model';
> > package: 'Magritte-Seaside';
> > package: 'Magritte-Pharo-Seaside';
> > package: 'Magritte-Morph';
> > load.
> > "Load Pier for Seaside 3"
> > Gofer new
> > renggli: 'pier2';
> > package: 'Pier-Core';
> > package: 'Pier-Pharo-Core';
> > package: 'Pier-Model';
> > package: 'Pier-Pharo-Model';
> > package: 'Pier-Tests-Model';
> > package: 'Pier-Seaside';
> > package: 'Pier-Pharo-Seaside';
> > package: 'Pier-Security';
> > package: 'Pier-Pharo-Persistency';
> > package: 'Pier-Tests-Security';
> > load.
> > PRPierFrame registerAsApplication: 'pier' kernel:
> (PRKernel new root:
> > (PRPage new title: 'test'; contents: 'Pier on Seaside
> 3.0'))
> > _______________________________________________
> > Magritte, Pier and Related Tools ...
> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki
> >
>
>
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
> _______________________________________________
> 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

Lukas Renggli

Re: 3.0 merge status (observations and a code variant)

> There are also many places where OmniBrowser is broken or where classes in O2 have instances being sent messages by OB - I have not even bothered debuggin those as they do not generally impede finding what is needed to get a base image (Squeak 3.10) or Pharo RC-1 (pharo1.0-10502-rc1web09.12.2) to run Seaside 3.0 on Win XP SP3

O2 has overrides in OB code. You cannot load both into one image.

> Here is my last list of classes where I comment out the class-side initialize until I have all nec loaded, then uncomment all of those and let fire

This is more a Seaside related comment, but I use the following
script. It works out of the box for me:

[ Gofer new
squeaksource: 'Seaside30';
package: 'LoadOrderTests';
load ]
valueSupplyingAnswers: {
{'Load Seaside'. true}.
{'SqueakSource User Name'. ''}.
{'SqueakSource Password'. ''}.
{'Run tests'. false}.
}

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

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

rshiple

Re: 3.0 merge status (observations and a code variant)

As I recall, the OB and O2 collisions occured using the 2 build recommendations from seaside.st - the cs script and the mcm file - on top of default base images. I use only the vanilla Win32 Squeak 3.10 and the latest available Pharo and always in a fresh directory with the addition of the squeak.exe and 2 DLL + splash + ini + .sources

I find that many Seaside class load problems are averted if you load packages into images which have already had a Seaside running - but I have to be able to build and deploy.

I will try the method you suggest for Pharo.

--- On Sat, 1/9/10, Lukas Renggli <[hidden email]> wrote:

> From: Lukas Renggli <[hidden email]>
> Subject: Re: 3.0 merge status (observations and a code variant)
> To: "Magritte, Pier and Related Tools ..." <[hidden email]>
> Date: Saturday, January 9, 2010, 7:26 PM
> > There are also many places where
> OmniBrowser is broken or where classes in O2 have instances
> being sent messages by OB - I have not even bothered
> debuggin those as they do not generally impede finding what
> is needed to get a base image (Squeak 3.10) or Pharo RC-1
> (pharo1.0-10502-rc1web09.12.2) to run Seaside 3.0 on Win XP
> SP3
>
> O2 has overrides in OB code. You cannot load both into one
> image.
>
> > Here is my last list of classes where I comment out
> the class-side initialize until I have all nec loaded, then
> uncomment all of those and let fire
>
> This is more a Seaside related comment, but I use the
> following
> script. It works out of the box for me:
>
> [ Gofer new
> squeaksource: 'Seaside30';
> package: 'LoadOrderTests';
> load ]
>
> valueSupplyingAnswers: {
>
> {'Load Seaside'. true}.
>
> {'SqueakSource User Name'. ''}.
>
> {'SqueakSource Password'. ''}.
>
> {'Run tests'. false}.
> }
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> 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

rshiple

Re: 3.0 merge status (observations and a code variant)

In reply to this post by Lukas Renggli

1)
Gofer script failed immediately in the 11.4 Pharo in the >>package: method

2)
Using the script from seaside.st, the first failure is a syntax error:

InstallerScripts as yet unclassified scriptUnloadTraits

scriptUnloadTraits

"Phase 1: Disable traits activity and stub out the instance variables that will be removed in Phase 2"

SystemChangeNotifier uniqueInstance
noMoreNotificationsFor: ProvidedSelectors current;
noMoreNotificationsFor: RequiredSelectors current;
noMoreNotificationsFor: LocalSends current.
Installer installUrl: 'http://installer.pbwiki.org/f/UnloadTraits-StubOutAcessors.cs'.

--- On Sat, 1/9/10, Lukas Renggli <[hidden email]> wrote:

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

rshiple

Re: 3.0 merge status (observations and a code variant)

In reply to this post by Lukas Renggli

Using a vanilla Pharo 11.4 install as recommended today at the pharo downloads page with the Seaside.st mcm file all looks to be going well until methods begin to recompile late in the load: the image is 60 MB and Pharo.exe simply consumes the available CPU cycles but the working memory size stays fixed.
After 15 - 20 minutes I conclude that it is dead (the UI is unresponsive) and kill it with Process Explorer.
There is no busy cursor, no visible message box, no minimized msg box at the bottom.

Nothing new gets logged. I would say it was very close to being done given what is in the frozen view of the Monticello browser ...

The last change written to .changes was this:

RBAssignmentNode removeSelector: #assignmentPosition!
!RBLiteralNode commentStamp: 'md 8/9/2005 14:58' prior: 34068596!
RBLiteralNode is an AST node that represents literals (e.g., #foo, #(1 2 3), true, etc.).

Instance Variables:
token <RBLiteralToken> the token that contains the literal value as well as its source positions

!
!RBLiteralNode commentStamp: 'md 8/9/2005 14:58' prior: 40424826!
RBLiteralNode is an AST node that represents literals (e.g., #foo, #(1 2 3), true, etc.).

Instance Variables:
token <RBLiteralToken> the token that contains the literal value as well as its source positions

!

--- On Sat, 1/9/10, Lukas Renggli <[hidden email]> wrote:

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

Lukas Renggli

Re: 3.0 merge status (observations and a code variant)

In reply to this post by rshiple

> Gofer script failed immediately in the 11.4 Pharo in the >>package: method

There must be a mismatch between Gofer versions here.

Use the latest core image, replace #package: with #addPackage:, or
update Gofer using:

[ Gofer gofer load ]
on: Error
do: [ :err | err retry ].
Gofer gofer recompile.

> 2)
> Using the script from seaside.st, the first failure is a syntax error:
>
> InstallerScripts as yet unclassified scriptUnloadTraits

Uhh? I don't know that script. This looks very strange. Neither
Seaside, Magritte, nor Pier does something with Traits.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

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

Lukas Renggli

Re: 3.0 merge status (observations and a code variant)

In reply to this post by rshiple

> Using a vanilla Pharo 11.4 install as recommended today at the pharo downloads page with the Seaside.st mcm file all looks to be going well until methods begin to recompile late in the load: the image is 60 MB and Pharo.exe simply consumes the available CPU cycles but the working memory size stays fixed.

I don't know a Pharo 11.4 image. That looks more like a VM version.

Aha, now I understand. This is installer that tries to unload traits.
Very strange, almost like a trojan.

I've removed the installer and sake script because they both depend on
installer. The other scripts work for me though, I get a working image
within a few minutes.

Lukas

> After 15 - 20 minutes I conclude that it is dead (the UI is unresponsive) and kill it with Process Explorer.
> There is no busy cursor, no visible message box, no minimized msg box at the bottom.
>
> Nothing new gets logged. I would say it was very close to being done given what is in the frozen view of the Monticello browser ...
>
> The last change written to .changes was this:
>
> RBAssignmentNode removeSelector: #assignmentPosition!
> !RBLiteralNode commentStamp: 'md 8/9/2005 14:58' prior: 34068596!
> RBLiteralNode is an AST node that represents literals (e.g., #foo, #(1 2 3), true, etc.).
>
> Instance Variables:
> token <RBLiteralToken> the token that contains the literal value as well as its source positions
>
> !
> !RBLiteralNode commentStamp: 'md 8/9/2005 14:58' prior: 40424826!
> RBLiteralNode is an AST node that represents literals (e.g., #foo, #(1 2 3), true, etc.).
>
> Instance Variables:
> token <RBLiteralToken> the token that contains the literal value as well as its source positions
>
> !
>
> --- On Sat, 1/9/10, Lukas Renggli <[hidden email]> wrote:
>
>> From: Lukas Renggli <[hidden email]>
>> Subject: Re: 3.0 merge status (observations and a code variant)
>> To: "Magritte, Pier and Related Tools ..." <[hidden email]>
>> Date: Saturday, January 9, 2010, 7:26 PM
>> > There are also many places where
>> OmniBrowser is broken or where classes in O2 have instances
>> being sent messages by OB - I have not even bothered
>> debuggin those as they do not generally impede finding what
>> is needed to get a base image (Squeak 3.10) or Pharo RC-1
>> (pharo1.0-10502-rc1web09.12.2) to run Seaside 3.0 on Win XP
>> SP3
>>
>> O2 has overrides in OB code. You cannot load both into one
>> image.
>>
>> > Here is my last list of classes where I comment out
>> the class-side initialize until I have all nec loaded, then
>> uncomment all of those and let fire
>>
>> This is more a Seaside related comment, but I use the
>> following
>> script. It works out of the box for me:
>>
>> [ Gofer new
>> squeaksource: 'Seaside30';
>> package: 'LoadOrderTests';
>> load ]
>>
>> valueSupplyingAnswers: {
>>
>> {'Load Seaside'. true}.
>>
>> {'SqueakSource User Name'. ''}.
>>
>> {'SqueakSource Password'. ''}.
>>
>> {'Run tests'. false}.
>> }
>>
>> Lukas
>>
>> --
>> Lukas Renggli
>> http://www.lukas-renggli.ch
>>
>> _______________________________________________
>> 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
>

--
Lukas Renggli
http://www.lukas-renggli.ch

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

rshiple

Re: 3.0 merge status (observations and a code variant)

I can get a working (and current) Seaside Pharo image eventually by putting in the installer and Grease on my own and then giving the file browser a simlified script to fileIn.

But it may be a moot point for my efforts.

I have to appeal to someone (JUlian?) to reconsider this method:

>>createHtmlRootWithContext: aRenderContext
^WAHtmlRoot context: aRenderContext

Even with my non-Html canvas and non-Html tags this sort of thing defeats my efforts.

Could this method not be

>>createRootWithContext: aRenderContext
^WARenderer default rootClass context: aRenderContext

as I have already set in my Seaside init script

WARenderCanvas unselectAsDefault.
WACurlCanvas selectAsDefault.

as my root class is WACurlRoot

--- On Sun, 1/10/10, Lukas Renggli <[hidden email]> wrote:

> From: Lukas Renggli <[hidden email]>
> Subject: Re: 3.0 merge status (observations and a code variant)
> To: "Magritte, Pier and Related Tools ..." <[hidden email]>
> Date: Sunday, January 10, 2010, 1:25 PM
> > Using a vanilla Pharo 11.4
> install as recommended today at the pharo downloads page
> with the Seaside.st mcm file all looks to be going well
> until methods begin to recompile late in the load: the image
> is 60 MB and Pharo.exe simply consumes the available CPU
> cycles but the working memory size stays fixed.
>
> I don't know a Pharo 11.4 image. That looks more like a VM
> version.
>
> Aha, now I understand. This is installer that tries to
> unload traits.
> Very strange, almost like a trojan.
>
> I've removed the installer and sake script because they
> both depend on
> installer. The other scripts work for me though, I get a
> working image
> within a few minutes.
>
> Lukas
>
>
> > After 15 - 20 minutes I conclude that it is dead (the
> UI is unresponsive) and kill it with Process Explorer.
> > There is no busy cursor, no visible message box, no
> minimized msg box at the bottom.
> >
> > Nothing new gets logged. I would say it was very
> close to being done given what is in the frozen view of the
> Monticello browser ...
> >
> > The last change written to .changes was this:
> >
> > RBAssignmentNode removeSelector: #assignmentPosition!
> > !RBLiteralNode commentStamp: 'md 8/9/2005 14:58'
> prior: 34068596!
> > RBLiteralNode is an AST node that represents literals
> (e.g., #foo, #(1 2 3), true, etc.).
> >
> > Instance Variables:
> > token <RBLiteralToken>
> the token that contains the literal value as well as its
> source positions
> >
> > !
> > !RBLiteralNode commentStamp: 'md 8/9/2005 14:58'
> prior: 40424826!
> > RBLiteralNode is an AST node that represents literals
> (e.g., #foo, #(1 2 3), true, etc.).
> >
> > Instance Variables:
> > token <RBLiteralToken>
> the token that contains the literal value as well as its
> source positions
> >
> > !
> >
> > --- On Sat, 1/9/10, Lukas Renggli <[hidden email]>
> wrote:
> >
> >> From: Lukas Renggli <[hidden email]>
> >> Subject: Re: 3.0 merge status (observations and a
> code variant)
> >> To: "Magritte, Pier and Related Tools ..." <[hidden email]>
> >> Date: Saturday, January 9, 2010, 7:26 PM
> >> > There are also many places where
> >> OmniBrowser is broken or where classes in O2 have
> instances
> >> being sent messages by OB - I have not even
> bothered
> >> debuggin those as they do not generally impede
> finding what
> >> is needed to get a base image (Squeak 3.10) or
> Pharo RC-1
> >> (pharo1.0-10502-rc1web09.12.2) to run Seaside 3.0
> on Win XP
> >> SP3
> >>
> >> O2 has overrides in OB code. You cannot load both
> into one
> >> image.
> >>
> >> > Here is my last list of classes where I
> comment out
> >> the class-side initialize until I have all nec
> loaded, then
> >> uncomment all of those and let fire
> >>
> >> This is more a Seaside related comment, but I use
> the
> >> following
> >> script. It works out of the box for me:
> >>
> >> [ Gofer new
> >> squeaksource: 'Seaside30';
> >> package: 'LoadOrderTests';
> >> load ]
> >>
> >> valueSupplyingAnswers: {
> >>
> >> {'Load Seaside'. true}.
> >>
> >> {'SqueakSource User Name'. ''}.
> >>
> >> {'SqueakSource Password'. ''}.
> >>
> >> {'Run tests'. false}.
> >> }
> >>
> >> Lukas
> >>
> >> --
> >> Lukas Renggli
> >> http://www.lukas-renggli.ch
> >>
> >> _______________________________________________
> >> 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
> >
>
>
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> 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

rshiple

Re: 3.0 merge status (observations and a code variant)

In reply to this post by Lukas Renggli

That image is

pharo1.0-10496-rc1dev09.11.4.image

The class-side of a canvas used to declare its rootClass like so:

builder
^ super builder
rootClass: WAHtmlRoot;
documentClass: WAHtmlDocument;
yourself

which I prefer to be

builder
^ super builder
rootClass: self rootClass;
documentClass: self documentClass;
yourself

I had provided my WATagCanvas subclass with

builder
^ super builder
rootClass: WACurlRoot;
documentClass: WACurlDocument;
yourself
but that comes too late.

Up in WARenderPhaseContinuation the
>>handleRequest
leads into
>>processRendering: aResponse
which where I first hit this HTML-only barrier by the method not asking.

--- On Sun, 1/10/10, Lukas Renggli <[hidden email]> wrote:

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

rshiple

Re: 3.0 merge status (observations and a code variant)

In reply to this post by Lukas Renggli

"I have to re-write the method "
WARequestContext
>>newDocument
"Answer a new Document configured to write onto our Response's stream using the current Codec. Try to use the Document class specified by the closest Handler but fall back on WAHtmlDocument if there is none."

^ (self handler isNil
ifTrue: [ WAHtmlDocument ]
ifFalse: [ self handler documentClass ])
on: self response stream codec: self codec

"as"

>>newDocument
"Answer a new Document configured to write onto our Response's stream using the current Codec. Try to use the Document class specified by the closest Handler but fall back on the WARenderer default documentClass if there is none."

^ (self handler isNil
ifTrue: [ WARenderer default documentClass]
ifFalse: [ self handler documentClass ])
on: self response stream codec: self codec

to even get my Curl app off the ground.

There are a few other places where I am hitting this (most anywhere up in the high level of the framework where we drop in an HTML default rather than asking for the default - even immediately after having asked for the app contentType in this case ... which in my case is not WAMimeType>>textHtml )

--- On Sun, 1/10/10, Lukas Renggli <[hidden email]> wrote:

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

Lukas Renggli

Re: 3.0 merge status (observations and a code variant)

Can you please add these things to the Seaside issue tracker?

http://code.google.com/p/seaside/issues/list

Or alternatively discuss them on seaside-dev? This is the wrong list.

Lukas

2010/1/10 Robert Shiplett <[hidden email]>:

> "I have to re-write the method "
> WARequestContext
>>>newDocument
> "Answer a new Document configured to write onto our Response's stream using the current Codec. Try to use the Document class specified by the closest Handler but fall back on WAHtmlDocument if there is none."
>
> ^ (self handler isNil
> ifTrue: [ WAHtmlDocument ]
> ifFalse: [ self handler documentClass ])
> on: self response stream codec: self codec
>
> "as"
>
>>>newDocument
> "Answer a new Document configured to write onto our Response's stream using the current Codec. Try to use the Document class specified by the closest Handler but fall back on the WARenderer default documentClass if there is none."
>
> ^ (self handler isNil
> ifTrue: [ WARenderer default documentClass]
> ifFalse: [ self handler documentClass ])
> on: self response stream codec: self codec
>
> to even get my Curl app off the ground.
>
> There are a few other places where I am hitting this (most anywhere up in the high level of the framework where we drop in an HTML default rather than asking for the default - even immediately after having asked for the app contentType in this case ... which in my case is not WAMimeType>>textHtml )
>
> --- On Sun, 1/10/10, Lukas Renggli <[hidden email]> wrote:
>
>> From: Lukas Renggli <[hidden email]>
>> Subject: Re: 3.0 merge status (observations and a code variant)
>> To: "Magritte, Pier and Related Tools ..." <[hidden email]>
>> Date: Sunday, January 10, 2010, 1:25 PM
>> > Using a vanilla Pharo 11.4
>> install as recommended today at the pharo downloads page
>> with the Seaside.st mcm file all looks to be going well
>> until methods begin to recompile late in the load: the image
>> is 60 MB and Pharo.exe simply consumes the available CPU
>> cycles but the working memory size stays fixed.
>>
>> I don't know a Pharo 11.4 image. That looks more like a VM
>> version.
>>
>> Aha, now I understand. This is installer that tries to
>> unload traits.
>> Very strange, almost like a trojan.
>>
>> I've removed the installer and sake script because they
>> both depend on
>> installer. The other scripts work for me though, I get a
>> working image
>> within a few minutes.
>>
>> Lukas
>>
>>
>> > After 15 - 20 minutes I conclude that it is dead (the
>> UI is unresponsive) and kill it with Process Explorer.
>> > There is no busy cursor, no visible message box, no
>> minimized msg box at the bottom.
>> >
>> > Nothing new gets logged. I would say it was very
>> close to being done given what is in the frozen view of the
>> Monticello browser ...
>> >
>> > The last change written to .changes was this:
>> >
>> > RBAssignmentNode removeSelector: #assignmentPosition!
>> > !RBLiteralNode commentStamp: 'md 8/9/2005 14:58'
>> prior: 34068596!
>> > RBLiteralNode is an AST node that represents literals
>> (e.g., #foo, #(1 2 3), true, etc.).
>> >
>> > Instance Variables:
>> > token <RBLiteralToken>
>> the token that contains the literal value as well as its
>> source positions
>> >
>> > !
>> > !RBLiteralNode commentStamp: 'md 8/9/2005 14:58'
>> prior: 40424826!
>> > RBLiteralNode is an AST node that represents literals
>> (e.g., #foo, #(1 2 3), true, etc.).
>> >
>> > Instance Variables:
>> > token <RBLiteralToken>
>> the token that contains the literal value as well as its
>> source positions
>> >
>> > !
>> >
>> > --- On Sat, 1/9/10, Lukas Renggli <[hidden email]>
>> wrote:
>> >
>> >> From: Lukas Renggli <[hidden email]>
>> >> Subject: Re: 3.0 merge status (observations and a
>> code variant)
>> >> To: "Magritte, Pier and Related Tools ..." <[hidden email]>
>> >> Date: Saturday, January 9, 2010, 7:26 PM
>> >> > There are also many places where
>> >> OmniBrowser is broken or where classes in O2 have
>> instances
>> >> being sent messages by OB - I have not even
>> bothered
>> >> debuggin those as they do not generally impede
>> finding what
>> >> is needed to get a base image (Squeak 3.10) or
>> Pharo RC-1
>> >> (pharo1.0-10502-rc1web09.12.2) to run Seaside 3.0
>> on Win XP
>> >> SP3
>> >>
>> >> O2 has overrides in OB code. You cannot load both
>> into one
>> >> image.
>> >>
>> >> > Here is my last list of classes where I
>> comment out
>> >> the class-side initialize until I have all nec
>> loaded, then
>> >> uncomment all of those and let fire
>> >>
>> >> This is more a Seaside related comment, but I use
>> the
>> >> following
>> >> script. It works out of the box for me:
>> >>
>> >> [ Gofer new
>> >> squeaksource: 'Seaside30';
>> >> package: 'LoadOrderTests';
>> >> load ]
>> >>
>> >> valueSupplyingAnswers: {
>> >>
>> >> {'Load Seaside'. true}.
>> >>
>> >> {'SqueakSource User Name'. ''}.
>> >>
>> >> {'SqueakSource Password'. ''}.
>> >>
>> >> {'Run tests'. false}.
>> >> }
>> >>
>> >> Lukas
>> >>
>> >> --
>> >> Lukas Renggli
>> >> http://www.lukas-renggli.ch
>> >>
>> >> _______________________________________________
>> >> 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
>> >
>>
>>
>>
>> --
>> Lukas Renggli
>> http://www.lukas-renggli.ch
>>
>> _______________________________________________
>> 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
>

--
Lukas Renggli
http://www.lukas-renggli.ch

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

Julian Fitzell-2

Re: 3.0 merge status (observations and a code variant)

In reply to this post by rshiple

Hi Robert,

This would all be more appropriate on the Seaside list... (I'm posting
there and CC'ing to Pier's list... could you follow up on the Seaside
list if needed? thanks)

And we've been through this previously, if I recall. The code you
mention below could probably be reduced to just "self handler
documentClass on: self response stream codec: self codec". handler
really never should be nil so what the default is is pretty
irrelevant. If you are using a different class of Document, you need
to configure that document class for your handler. If you don't want
to use the web config UI, it's as simple as:

myApplication preferenceAt: #documentClass put: MyDocumentSubclass

As for the other suggestions, I'm still not convinced. As I said
before, I support your goal of outputting something other than HTML,
but Seaside's RenderLoop is designed to render HTML and
WARenderPhaseContinuation makes several assumptions about doing Html.
Its #updateRoot: calls several HtmlRoot-specific methods and passes
the root to the Libraries, which also all expect an HtmlRoot. If you
want to use something else with the RenderLoop, that's fine, but I
think you'll need to subclass the Continuations to do it, thus you can
override #processRendering: to do whatever you like. The Continuations
were designed to be subclasses; that's why there's a configuration for
them:

myApplication preferenceAt: #renderPhaseContinuationClass put:
MyContinuationSubclass
myApplication preferenceAt: #actionPhaseContinuationClass put:
MyContinuationSubclass

Julian

On Sun, Jan 10, 2010 at 2:39 PM, Robert Shiplett <[hidden email]> wrote:

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

rshiple

Re: 3.0 merge status (observations and a code variant)

Julian

Perhaps if you consider this:

Most of my issues vanish if the >>processRendering method asks the document for its content-type instead of asking an application to look in its preferences, i.e.,

"Prepare the response"
"Create objects we need"
document := self requestContext newDocument.
aResponse contentType: document contentType.

For example: how is the WAApplication to be sure of what the character-encoding is without asking the document? At the moment the WAApplication class sets charset for the response in its >>contentType method.

Robert

--- On Sun, 1/10/10, Julian Fitzell <[hidden email]> wrote:

> From: Julian Fitzell <[hidden email]>
> Subject: Re: 3.0 merge status (observations and a code variant)
> To: "Seaside - general discussion" <[hidden email]>
> Cc: "Magritte, Pier and Related Tools ..." <[hidden email]>
> Date: Sunday, January 10, 2010, 5:03 PM
> Hi Robert,
>
> This would all be more appropriate on the Seaside list...
> (I'm posting
> there and CC'ing to Pier's list... could you follow up on
> the Seaside
> list if needed? thanks)
>
> And we've been through this previously, if I recall. The
> code you
> mention below could probably be reduced to just "self
> handler
> documentClass on: self response stream codec: self codec".
> handler
> really never should be nil so what the default is is
> pretty
> irrelevant. If you are using a different class of Document,
> you need
> to configure that document class for your handler. If you
> don't want
> to use the web config UI, it's as simple as:
>
> myApplication preferenceAt: #documentClass put:
> MyDocumentSubclass
>
> As for the other suggestions, I'm still not convinced. As I
> said
> before, I support your goal of outputting something other
> than HTML,
> but Seaside's RenderLoop is designed to render HTML and
> WARenderPhaseContinuation makes several assumptions about
> doing Html.
> Its #updateRoot: calls several HtmlRoot-specific methods
> and passes
> the root to the Libraries, which also all expect an
> HtmlRoot. If you
> want to use something else with the RenderLoop, that's
> fine, but I
> think you'll need to subclass the Continuations to do it,
> thus you can
> override #processRendering: to do whatever you like. The
> Continuations
> were designed to be subclasses; that's why there's a
> configuration for
> them:
>
> myApplication preferenceAt: #renderPhaseContinuationClass
> put:
> MyContinuationSubclass
> myApplication preferenceAt: #actionPhaseContinuationClass
> put:
> MyContinuationSubclass
>
>
> Julian
>
> On Sun, Jan 10, 2010 at 2:39 PM, Robert Shiplett <[hidden email]>
> wrote:
> > "I have to re-write the method "
> > WARequestContext
> >>>newDocument
> > "Answer a new Document configured to write
> onto our Response's stream using the current Codec. Try to
> use the Document class specified by the closest Handler but
> fall back on WAHtmlDocument if there is none."
> >
> > ^ (self handler isNil
> > ifTrue: [ WAHtmlDocument ]
> > ifFalse: [ self handler
> documentClass ])
> > on: self response
> stream codec: self codec
> >
> > "as"
> >
> >>>newDocument
> > "Answer a new Document configured to write
> onto our Response's stream using the current Codec. Try to
> use the Document class specified by the closest Handler but
> fall back on the WARenderer default documentClass if there
> is none."
> >
> > ^ (self handler isNil
> > ifTrue: [ WARenderer default
> documentClass]
> > ifFalse: [ self handler
> documentClass ])
> > on: self response
> stream codec: self codec
> >
> > to even get my Curl app off the ground.
> >
> > There are a few other places where I am hitting this
> (most anywhere up in the high level of the framework where
> we drop in an HTML default rather than asking for the
> default - even immediately after having asked for the app
> contentType in this case ... which in my case is not
> WAMimeType>>textHtml )
> >
> > --- On Sun, 1/10/10, Lukas Renggli <[hidden email]>
> wrote:
> >
> >> From: Lukas Renggli <[hidden email]>
> >> Subject: Re: 3.0 merge status (observations and a
> code variant)
> >> To: "Magritte, Pier and Related Tools ..." <[hidden email]>
> >> Date: Sunday, January 10, 2010, 1:25 PM
> >> > Using a vanilla Pharo 11.4
> >> install as recommended today at the pharo
> downloads page
> >> with the Seaside.st mcm file all looks to be going
> well
> >> until methods begin to recompile late in the load:
> the image
> >> is 60 MB and Pharo.exe simply consumes the
> available CPU
> >> cycles but the working memory size stays fixed.
> >>
> >> I don't know a Pharo 11.4 image. That looks more
> like a VM
> >> version.
> >>
> >> Aha, now I understand. This is installer that
> tries to
> >> unload traits.
> >> Very strange, almost like a trojan.
> >>
> >> I've removed the installer and sake script because
> they
> >> both depend on
> >> installer. The other scripts work for me though, I
> get a
> >> working image
> >> within a few minutes.
> >>
> >> Lukas
> >>
> >>
> >> > After 15 - 20 minutes I conclude that it is
> dead (the
> >> UI is unresponsive) and kill it with Process
> Explorer.
> >> > There is no busy cursor, no visible message
> box, no
> >> minimized msg box at the bottom.
> >> >
> >> > Nothing new gets logged. I would say it was
> very
> >> close to being done given what is in the frozen
> view of the
> >> Monticello browser ...
> >> >
> >> > The last change written to .changes was
> this:
> >> >
> >> > RBAssignmentNode removeSelector:
> #assignmentPosition!
> >> > !RBLiteralNode commentStamp: 'md 8/9/2005
> 14:58'
> >> prior: 34068596!
> >> > RBLiteralNode is an AST node that represents
> literals
> >> (e.g., #foo, #(1 2 3), true, etc.).
> >> >
> >> > Instance Variables:
> >> > token <RBLiteralToken>
> >> the token that contains the literal value as
> well as its
> >> source positions
> >> >
> >> > !
> >> > !RBLiteralNode commentStamp: 'md 8/9/2005
> 14:58'
> >> prior: 40424826!
> >> > RBLiteralNode is an AST node that represents
> literals
> >> (e.g., #foo, #(1 2 3), true, etc.).
> >> >
> >> > Instance Variables:
> >> > token <RBLiteralToken>
> >> the token that contains the literal value as
> well as its
> >> source positions
> >> >
> >> > !
> >> >
> >> > --- On Sat, 1/9/10, Lukas Renggli <[hidden email]>
> >> wrote:
> >> >
> >> >> From: Lukas Renggli <[hidden email]>
> >> >> Subject: Re: 3.0 merge status
> (observations and a
> >> code variant)
> >> >> To: "Magritte, Pier and Related Tools
> ..." <[hidden email]>
> >> >> Date: Saturday, January 9, 2010, 7:26 PM
> >> >> > There are also many places where
> >> >> OmniBrowser is broken or where classes in
> O2 have
> >> instances
> >> >> being sent messages by OB - I have not
> even
> >> bothered
> >> >> debuggin those as they do not generally
> impede
> >> finding what
> >> >> is needed to get a base image (Squeak
> 3.10) or
> >> Pharo RC-1
> >> >> (pharo1.0-10502-rc1web09.12.2) to run
> Seaside 3.0
> >> on Win XP
> >> >> SP3
> >> >>
> >> >> O2 has overrides in OB code. You cannot
> load both
> >> into one
> >> >> image.
> >> >>
> >> >> > Here is my last list of classes
> where I
> >> comment out
> >> >> the class-side initialize until I have
> all nec
> >> loaded, then
> >> >> uncomment all of those and let fire
> >> >>
> >> >> This is more a Seaside related comment,
> but I use
> >> the
> >> >> following
> >> >> script. It works out of the box for me:
> >> >>
> >> >> [ Gofer new
> >> >> squeaksource: 'Seaside30';
> >> >> package: 'LoadOrderTests';
> >> >> load ]
> >> >>
> >> >> valueSupplyingAnswers: {
> >> >>
> >> >> {'Load Seaside'. true}.
> >> >>
> >> >> {'SqueakSource User Name'.
> ''}.
> >> >>
> >> >> {'SqueakSource Password'.
> ''}.
> >> >>
> >> >> {'Run tests'. false}.
> >> >> }
> >> >>
> >> >> Lukas
> >> >>
> >> >> --
> >> >> Lukas Renggli
> >> >> http://www.lukas-renggli.ch
> >> >>
> >> >>
> _______________________________________________
> >> >> 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
> >> >
> >>
> >>
> >>
> >> --
> >> Lukas Renggli
> >> http://www.lukas-renggli.ch
> >>
> >> _______________________________________________
> >> 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
> >
>
> _______________________________________________
> 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

rshiple

Re: 3.0 merge status (observations and a code variant)

In reply to this post by Julian Fitzell-2

Julian

Perhaps this would help: I am not asking for different behavior in the render loop. I firmly believe that we should only subclass for behavior.

I also think that a web framework is the sort of thing that should tell you what you are expected to provide - but not to reimplement key pieces of the framework for an alternate text content-type.

Nothing that alternative document content markup requires necessitates those changes: the markup simply does not close the tag with the name of the element. Its name for "hr" is "hrule" but its name for "br" is "br". It is not XML. It is as declarative as HTML. So I handle that as a document class and some tag classes and a canvas subclass and maybe a Brush subclass if needed. Some of my tag subclasses just subclass an Html Tag class.

I think that the content type of the page that a web app opens is the content type of the cargo of that http response.

Putting the class for a RenderPhaseContinuation subclass into configuration properties seems a stretch ... at least the charset issue is surely going to have to come back to the document from the app class (if Seaside is to be used in India, for example: app is in English or Hindi or Telegu or whatever and documents are in whatever char-encoding they are in.
Even more so in those countries with a mix of Han and non-Chinese or Arabic and roman.

In the spirit of /htdocs but with UNICODE URI's

Robert
hypertext-doc guy

--- On Sun, 1/10/10, Julian Fitzell <[hidden email]> wrote:

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

rshiple

Re: 3.0 merge status (observations and a code variant)

In reply to this post by Julian Fitzell-2

"currently WARenderPhaseContinuation>>processRendering: sets contentType for a response with WAApplication" as

WARenderPhaseContinuation>>processRendering: aResponse
aResponse contentType: self application contentType. [...]

WAApplication
>>contentType
^ self mimeType seasideMimeType
charset: self charSet;
yourself

"and that is sent before getting the document instantiated (which follows immediately.)
Of course that is no issue if all you ever return are web documents using that application 'preference' e.g. iso-8859-1 and text/html. But my application is running in a browser where a 404 page is just a 404 (i.e, an html page) but one content page may be Content-Type h-markup and another may be Content-Type c-markup and this in English but that in Telegu."

The system configuration option for a render loop subclass looks even worse from where I sit - and quite unnecessary even if it is a design feature.

Not that other web frameworks are not stickier. One that almost gets this web content type issue right is Apache Wicket. Some other frameworks do truly descend into properties file/configuration Hades and some, like Lift, code themselves into an HTML-only strait-jacket where text documents are concerned (bizarre for a language like Scala.) Yet for bare-bones CGI, JSP and PHP, Content-Type is an utterly trivial matter. Only when a framework is built do things start to go wrong on this one simple issue.

Doing something simple should be simple; doing something complex should be possible.

R

--- On Sun, 1/10/10, Julian Fitzell <[hidden email]> wrote:

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

Nick

Re: 3.0 merge status

In reply to this post by Lukas Renggli

For the record I've changed the script I run to create a simple Pier instance once I've loaded the code:

PRPierFrame registerAsApplication: 'pier' kernel: (PRKernel new root: (PRPage new title: 'test title'; contents: 'Pier on Seaside 3.0'; name: 'testPage'); name: 'testKernel').

I realised I needed to name the page, otherwise errors result when trying to edit the page.

2010/1/9 Lukas Renggli <[hidden email]>

Thank you for these scripts. I use them to load the new code into
Seaside 3.0 images, see
<http://hudson.lukas-renggli.ch/job/Seaside%203.0/>.

This job builds a Seaside 3.0, saves it; loads Magritte 2 into that
image, saves it; and finally loads Pier 2 and saves it. It also runs
the tests and generates a report. I haven't yet tried the actual
images, but this should make it easier to see what works and what is
broken.

Lukas

2010/1/8 Nick Ager <[hidden email]>:

> I reviewed all my merges and discovered I'd lost changes in:
> PRPierFrame>>initialRequest
> PRViewCommand>>initialRequest
> MAOneToManyComponent>>add
> With the corrections in place, Pier appears to working once again. There are
> a couple of anomalies - the Pier logo doesn't appear on the home screen and
> I received one walkback while clicking around. I'll investigate these
> problems later. I've also yet to look at any add-ons including the
> Pier-Blog.
> I've loaded the code into a fresh seaside3.0a5 image (with updated Gofer)
> and the code loads cleanly.
> For reference the load script I used was:
> "Load Magritte for Seaside 3"
> Gofer new
> renggli: 'magritte2';
> package: 'Magritte-Model';
> package: 'Magritte-Pharo-Model';
> package: 'Magritte-Tests-Model';
> package: 'Magritte-Tests-Pharo-Model';
> package: 'Magritte-Seaside';
> package: 'Magritte-Pharo-Seaside';
> package: 'Magritte-Morph';
> load.
> "Load Pier for Seaside 3"
> Gofer new
> renggli: 'pier2';
> package: 'Pier-Core';
> package: 'Pier-Pharo-Core';
> package: 'Pier-Model';
> package: 'Pier-Pharo-Model';
> package: 'Pier-Tests-Model';
> package: 'Pier-Seaside';
> package: 'Pier-Pharo-Seaside';
> package: 'Pier-Security';
> package: 'Pier-Pharo-Persistency';
> package: 'Pier-Tests-Security';
> load.
> PRPierFrame registerAsApplication: 'pier' kernel: (PRKernel new root:
> (PRPage new title: 'test'; contents: 'Pier on Seaside 3.0'))

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

--

Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________

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