From nick.ager at gmail.com Mon Jan 4 17:27:33 2010 From: nick.ager at gmail.com (Nick Ager) Date: Mon, 4 Jan 2010 16:27:33 +0000 Subject: pier and seaside 3.0 Message-ID: <3a06f76f1001040827j5792622fv6f0c736e50fd3279@mail.gmail.com> Happy New Year to the list. I've been developing a site using vanilla seaside 3.0a5, and have belated released that there's much functionality in base Pier and the add-ons which would save me significant time. From what I can gather from a brief search of the list there is an early port to 3.0, though I've struggled to load it into my image. Is there a load script I can use for 3.0? Is it really sensible to try an early 3.0 port when I'm still struggling to get to grips with the basic concepts - would I be better off using 2.8 and revert my jQuery code to prototype/scriptaculous? Thanks Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvdsandt at gmail.com Mon Jan 4 17:33:03 2010 From: jvdsandt at gmail.com (Jan van de Sandt) Date: Mon, 4 Jan 2010 17:33:03 +0100 Subject: pier and seaside 3.0 In-Reply-To: <3a06f76f1001040827j5792622fv6f0c736e50fd3279@mail.gmail.com> References: <3a06f76f1001040827j5792622fv6f0c736e50fd3279@mail.gmail.com> Message-ID: <50d1d2c91001040833q63465847wab90070c20170958@mail.gmail.com> Hello Nick, I use the following "Gofer code" to load Magritte and Pier into a Seaside 3 image. Magritte is a prerequisite for Pier: "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'; package: 'Pier-Tests-Model'; package: 'Pier-Seaside'; package: 'Pier-Pharo-Seaside'; package: 'Pier-Security'; package: 'Pier-Pharo-Persistency'; package: 'Pier-Tests-Security'; load. Jan On Mon, Jan 4, 2010 at 5:27 PM, Nick Ager wrote: > Happy New Year to the list. > I've been developing a site using vanilla seaside 3.0a5, and have belated > released that there's much functionality in base Pier and the add-ons which > would save me significant time. From what I can gather from a brief search > of the list there is an early port to 3.0, though I've struggled to load it > into my image. Is there a load script I can use for 3.0? Is it really > sensible to try an early 3.0 port when I'm still struggling to get to grips > with the basic concepts - would I be better off using 2.8 and revert my > jQuery code to prototype/scriptaculous? > Thanks Nick > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Tue Jan 5 11:15:45 2010 From: nick.ager at gmail.com (Nick Ager) Date: Tue, 5 Jan 2010 10:15:45 +0000 Subject: pier and seaside 3.0 In-Reply-To: <50d1d2c91001040833q63465847wab90070c20170958@mail.gmail.com> References: <3a06f76f1001040827j5792622fv6f0c736e50fd3279@mail.gmail.com> <50d1d2c91001040833q63465847wab90070c20170958@mail.gmail.com> Message-ID: <3a06f76f1001050215s26a7a06ao9346ba7e6b93b9f0@mail.gmail.com> Hi Jan, Thanks that was exactly what I was after. Pier and Magritte loaded with a few errors (see later), then I registered Pier with: PRPierFrame registerAsApplication: 'pier' kernel: PRKernel new When I then go to browse localhost:8080/pier I receive the error: MNU: receiver of viewCommandClass is nil Digging into the call-stack originating at PRPierFrame>>initialRequest the structure passed to PRContext>>kernel:structure: is nil which originates from a call to PRKernel>>root returning nil. Any thoughts anyone? BTW the load errors: "FileList2 is Undeclared", in MAFileMorph - doesn't seem too concerning as I'm only interested in the seaside bindings. I ignored the error: "Pier-Core depends on PRPackage class>>pierTestsModel" PRCommandTest>>testDate(WAPlatform is undefined) PRCommandTest>>testTimestamp (WAPlatform is Undeclared) PRPersistencyTest>>testMutexForked(WAPlatform is undefined) PRSegmentPersistency>>cleanupSeaside (WAEntryPoint is Undeclared) Should I be concerned by any of these load errors? Nick 2010/1/4 Jan van de Sandt > Hello Nick, > > I use the following "Gofer code" to load Magritte and Pier into a Seaside 3 > image. Magritte is a prerequisite for Pier: > > "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'; > package: 'Pier-Tests-Model'; > package: 'Pier-Seaside'; > package: 'Pier-Pharo-Seaside'; > > > > package: 'Pier-Security'; > package: 'Pier-Pharo-Persistency'; > package: 'Pier-Tests-Security'; > load. > > > Jan > > > > On Mon, Jan 4, 2010 at 5:27 PM, Nick Ager wrote: > >> Happy New Year to the list. >> I've been developing a site using vanilla seaside 3.0a5, and have belated >> released that there's much functionality in base Pier and the add-ons which >> would save me significant time. From what I can gather from a brief search >> of the list there is an early port to 3.0, though I've struggled to load it >> into my image. Is there a load script I can use for 3.0? Is it really >> sensible to try an early 3.0 port when I'm still struggling to get to grips >> with the basic concepts - would I be better off using 2.8 and revert my >> jQuery code to prototype/scriptaculous? >> Thanks 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marianopeck at gmail.com Tue Jan 5 11:20:49 2010 From: marianopeck at gmail.com (Mariano Martinez Peck) Date: Tue, 5 Jan 2010 11:20:49 +0100 Subject: pier and seaside 3.0 In-Reply-To: <3a06f76f1001050215s26a7a06ao9346ba7e6b93b9f0@mail.gmail.com> References: <3a06f76f1001040827j5792622fv6f0c736e50fd3279@mail.gmail.com> <50d1d2c91001040833q63465847wab90070c20170958@mail.gmail.com> <3a06f76f1001050215s26a7a06ao9346ba7e6b93b9f0@mail.gmail.com> Message-ID: On Tue, Jan 5, 2010 at 11:15 AM, Nick Ager wrote: > Hi Jan, > > Thanks that was exactly what I was after. > > Pier and Magritte loaded with a few errors (see later), then I registered > Pier with: > PRPierFrame registerAsApplication: 'pier' kernel: PRKernel new > > When I then go to browse localhost:8080/pier I receive the error: > MNU: receiver of viewCommandClass is nil > > Digging into the call-stack originating at PRPierFrame>>initialRequest the > structure passed to PRContext>>kernel:structure: is nil which originates > from a call to PRKernel>>root returning nil. Any thoughts anyone? > > BTW the load errors: > "FileList2 is Undeclared", in MAFileMorph - doesn't seem too concerning as > I'm only interested in the seaside bindings. > FileList2 does not exist any more in Pharo, you must use FileList. See http://code.google.com/p/pharo/issues/detail?id=269 > I ignored the error: "Pier-Core depends on PRPackage class>>pierTestsModel" > PRCommandTest>>testDate(WAPlatform is undefined) > PRCommandTest>>testTimestamp (WAPlatform is Undeclared) > PRPersistencyTest>>testMutexForked(WAPlatform is undefined) > PRSegmentPersistency>>cleanupSeaside (WAEntryPoint is Undeclared) > > Should I be concerned by any of these load errors? > > Nick > > 2010/1/4 Jan van de Sandt > > Hello Nick, >> >> I use the following "Gofer code" to load Magritte and Pier into a Seaside >> 3 image. Magritte is a prerequisite for Pier: >> >> "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'; >> package: 'Pier-Tests-Model'; >> package: 'Pier-Seaside'; >> package: 'Pier-Pharo-Seaside'; >> >> >> >> >> package: 'Pier-Security'; >> package: 'Pier-Pharo-Persistency'; >> package: 'Pier-Tests-Security'; >> load. >> >> >> Jan >> >> >> >> On Mon, Jan 4, 2010 at 5:27 PM, Nick Ager wrote: >> >>> Happy New Year to the list. >>> I've been developing a site using vanilla seaside 3.0a5, and have belated >>> released that there's much functionality in base Pier and the add-ons which >>> would save me significant time. From what I can gather from a brief search >>> of the list there is an early port to 3.0, though I've struggled to load it >>> into my image. Is there a load script I can use for 3.0? Is it really >>> sensible to try an early 3.0 port when I'm still struggling to get to grips >>> with the basic concepts - would I be better off using 2.8 and revert my >>> jQuery code to prototype/scriptaculous? >>> Thanks 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 >> > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Tue Jan 5 13:12:35 2010 From: nick.ager at gmail.com (Nick Ager) Date: Tue, 5 Jan 2010 12:12:35 +0000 Subject: pier and seaside 3.0 In-Reply-To: <3a06f76f1001050215s26a7a06ao9346ba7e6b93b9f0@mail.gmail.com> References: <3a06f76f1001040827j5792622fv6f0c736e50fd3279@mail.gmail.com> <50d1d2c91001040833q63465847wab90070c20170958@mail.gmail.com> <3a06f76f1001050215s26a7a06ao9346ba7e6b93b9f0@mail.gmail.com> Message-ID: <3a06f76f1001050412r76c40d3ao5ad13d38bd4f8e9d@mail.gmail.com> To answer myself the magic incantation I've arrived at for registration is: PRPierFrame registerAsApplication: 'pier' kernel: (PRKernel new root: (PRPage new title: 'test'; contents: 'Pier on Seaside 3.0')) Still trying to understand how to register PRPierFrame class>>exampleBasic and exampleDocumentation. I'll see if I get anywhere this afternoon... Nick 2010/1/5 Nick Ager > Hi Jan, > > Thanks that was exactly what I was after. > > Pier and Magritte loaded with a few errors (see later), then I registered > Pier with: > PRPierFrame registerAsApplication: 'pier' kernel: PRKernel new > > When I then go to browse localhost:8080/pier I receive the error: > MNU: receiver of viewCommandClass is nil > > Digging into the call-stack originating at PRPierFrame>>initialRequest the > structure passed to PRContext>>kernel:structure: is nil which originates > from a call to PRKernel>>root returning nil. Any thoughts anyone? > > BTW the load errors: > "FileList2 is Undeclared", in MAFileMorph - doesn't seem too concerning as > I'm only interested in the seaside bindings. > I ignored the error: "Pier-Core depends on PRPackage class>>pierTestsModel" > PRCommandTest>>testDate(WAPlatform is undefined) > PRCommandTest>>testTimestamp (WAPlatform is Undeclared) > PRPersistencyTest>>testMutexForked(WAPlatform is undefined) > PRSegmentPersistency>>cleanupSeaside (WAEntryPoint is Undeclared) > > Should I be concerned by any of these load errors? > > Nick > > 2010/1/4 Jan van de Sandt > > Hello Nick, >> >> I use the following "Gofer code" to load Magritte and Pier into a Seaside >> 3 image. Magritte is a prerequisite for Pier: >> >> "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'; >> package: 'Pier-Tests-Model'; >> package: 'Pier-Seaside'; >> package: 'Pier-Pharo-Seaside'; >> >> >> >> >> package: 'Pier-Security'; >> package: 'Pier-Pharo-Persistency'; >> package: 'Pier-Tests-Security'; >> load. >> >> >> Jan >> >> >> >> On Mon, Jan 4, 2010 at 5:27 PM, Nick Ager wrote: >> >>> Happy New Year to the list. >>> I've been developing a site using vanilla seaside 3.0a5, and have belated >>> released that there's much functionality in base Pier and the add-ons which >>> would save me significant time. From what I can gather from a brief search >>> of the list there is an early port to 3.0, though I've struggled to load it >>> into my image. Is there a load script I can use for 3.0? Is it really >>> sensible to try an early 3.0 port when I'm still struggling to get to grips >>> with the basic concepts - would I be better off using 2.8 and revert my >>> jQuery code to prototype/scriptaculous? >>> Thanks 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Tue Jan 5 13:24:13 2010 From: nick.ager at gmail.com (Nick Ager) Date: Tue, 5 Jan 2010 12:24:13 +0000 Subject: pier and seaside 3.0 In-Reply-To: References: <3a06f76f1001040827j5792622fv6f0c736e50fd3279@mail.gmail.com> <50d1d2c91001040833q63465847wab90070c20170958@mail.gmail.com> <3a06f76f1001050215s26a7a06ao9346ba7e6b93b9f0@mail.gmail.com> Message-ID: <3a06f76f1001050424l2db38ad8ka7dffda0bbac2c63@mail.gmail.com> Hi Mariano, I'm afraid my knowledge of Monticello is limited. Is it odd that FileList2 change was closed in November 2008, but the repository I loaded MAFileMorph from http://source.lukas-renggli.ch/magritte2, only dates from September 2009? I'm happy to update the Magritte-Morph package in the repository to refer to FileList instead, though I feel I'm stumbling in the dark. Nick 2010/1/5 Mariano Martinez Peck > > > On Tue, Jan 5, 2010 at 11:15 AM, Nick Ager wrote: > >> Hi Jan, >> >> Thanks that was exactly what I was after. >> >> Pier and Magritte loaded with a few errors (see later), then I registered >> Pier with: >> PRPierFrame registerAsApplication: 'pier' kernel: PRKernel new >> >> When I then go to browse localhost:8080/pier I receive the error: >> MNU: receiver of viewCommandClass is nil >> >> Digging into the call-stack originating at PRPierFrame>>initialRequest the >> structure passed to PRContext>>kernel:structure: is nil which originates >> from a call to PRKernel>>root returning nil. Any thoughts anyone? >> >> BTW the load errors: >> "FileList2 is Undeclared", in MAFileMorph - doesn't seem too concerning as >> I'm only interested in the seaside bindings. >> > > FileList2 does not exist any more in Pharo, you must use FileList. > See http://code.google.com/p/pharo/issues/detail?id=269 > > >> I ignored the error: "Pier-Core depends on PRPackage >> class>>pierTestsModel" >> PRCommandTest>>testDate(WAPlatform is undefined) >> PRCommandTest>>testTimestamp (WAPlatform is Undeclared) >> PRPersistencyTest>>testMutexForked(WAPlatform is undefined) >> PRSegmentPersistency>>cleanupSeaside (WAEntryPoint is Undeclared) >> >> Should I be concerned by any of these load errors? >> >> Nick >> >> 2010/1/4 Jan van de Sandt >> >> Hello Nick, >>> >>> I use the following "Gofer code" to load Magritte and Pier into a Seaside >>> 3 image. Magritte is a prerequisite for Pier: >>> >>> "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'; >>> package: 'Pier-Tests-Model'; >>> package: 'Pier-Seaside'; >>> package: 'Pier-Pharo-Seaside'; >>> >>> >>> >>> >>> >>> package: 'Pier-Security'; >>> package: 'Pier-Pharo-Persistency'; >>> package: 'Pier-Tests-Security'; >>> load. >>> >>> >>> Jan >>> >>> >>> >>> On Mon, Jan 4, 2010 at 5:27 PM, Nick Ager wrote: >>> >>>> Happy New Year to the list. >>>> I've been developing a site using vanilla seaside 3.0a5, and have >>>> belated released that there's much functionality in base Pier and the >>>> add-ons which would save me significant time. From what I can gather from a >>>> brief search of the list there is an early port to 3.0, though I've >>>> struggled to load it into my image. Is there a load script I can use for >>>> 3.0? Is it really sensible to try an early 3.0 port when I'm still >>>> struggling to get to grips with the basic concepts - would I be better off >>>> using 2.8 and revert my jQuery code to prototype/scriptaculous? >>>> Thanks 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 >>> >> >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Tue Jan 5 14:59:16 2010 From: renggli at gmail.com (Lukas Renggli) Date: Tue, 5 Jan 2010 14:59:16 +0100 Subject: pier and seaside 3.0 In-Reply-To: <3a06f76f1001050215s26a7a06ao9346ba7e6b93b9f0@mail.gmail.com> References: <3a06f76f1001040827j5792622fv6f0c736e50fd3279@mail.gmail.com> <50d1d2c91001040833q63465847wab90070c20170958@mail.gmail.com> <3a06f76f1001050215s26a7a06ao9346ba7e6b93b9f0@mail.gmail.com> Message-ID: <67628d691001050559s3d98b7d2o7a7e7d40c922cc75@mail.gmail.com> > BTW the load errors: > "FileList2 is Undeclared", in?MAFileMorph - doesn't seem too concerning as > I'm only interested in the seaside bindings. Yep, the Magritte-Morph is not really required. > I ignored the error: "Pier-Core depends on PRPackage class>>pierTestsModel" > PRCommandTest>>testDate(WAPlatform is undefined) > PRCommandTest>>testTimestamp (WAPlatform is Undeclared) > PRPersistencyTest>>testMutexForked(WAPlatform is undefined) > PRSegmentPersistency>>cleanupSeaside (WAEntryPoint is Undeclared) > Should I be concerned by any of these load errors? That looks like there is version mismatch between Magritte/Pier and Seaside. The port of of Magritte/Pier was done for VA Smalltalk by Julian, and it looks like the code hasn't been adapted to very latest version of Seaside. Also the code is quite behind the Magritte/Pier code for Seaside 2.8. Shame on me that I still didn't had time to look into this. Lukas -- Lukas Renggli http://www.lukas-renggli.ch From nick.ager at gmail.com Tue Jan 5 17:49:31 2010 From: nick.ager at gmail.com (Nick Ager) Date: Tue, 5 Jan 2010 16:49:31 +0000 Subject: pier and seaside 3.0 In-Reply-To: <67628d691001050559s3d98b7d2o7a7e7d40c922cc75@mail.gmail.com> References: <3a06f76f1001040827j5792622fv6f0c736e50fd3279@mail.gmail.com> <50d1d2c91001040833q63465847wab90070c20170958@mail.gmail.com> <3a06f76f1001050215s26a7a06ao9346ba7e6b93b9f0@mail.gmail.com> <67628d691001050559s3d98b7d2o7a7e7d40c922cc75@mail.gmail.com> Message-ID: <3a06f76f1001050849v441f8857we41fda1b070315e4@mail.gmail.com> Hi Lukas, I'm happy to help if you can point me in the right direction. On a different issue - I'm trying to understand PRPierFrame class>>exampleBasic and PRPierFrame class>>exampleDocumentation. Browsing at: localhost:8080/examples/examplebrowser results in WAAtrributeNotFound but only *with Pier installed*. The problem is in PRPierFrame>>initialRequest which calls: self application preferenceAt: #kernel there's no kernel defined, although it is defined within a PRContext in exampleBasic. I'm afraid I don't understand enough about how PRKernel and PRContext are related to WAUserConfiguration to debug further. However this doesn't just appear to be a 3.0 issue - my 2.8 image with Pier installed also generates an error when I browse to localhost:8080/seaside/examples/examplebrowser Any thoughts? Nick 2010/1/5 Lukas Renggli > > BTW the load errors: > > "FileList2 is Undeclared", in MAFileMorph - doesn't seem too concerning > as > > I'm only interested in the seaside bindings. > > Yep, the Magritte-Morph is not really required. > > > I ignored the error: "Pier-Core depends on PRPackage > class>>pierTestsModel" > > PRCommandTest>>testDate(WAPlatform is undefined) > > PRCommandTest>>testTimestamp (WAPlatform is Undeclared) > > PRPersistencyTest>>testMutexForked(WAPlatform is undefined) > > PRSegmentPersistency>>cleanupSeaside (WAEntryPoint is Undeclared) > > Should I be concerned by any of these load errors? > > That looks like there is version mismatch between Magritte/Pier and > Seaside. > > The port of of Magritte/Pier was done for VA Smalltalk by Julian, and > it looks like the code hasn't been adapted to very latest version of > Seaside. Also the code is quite behind the Magritte/Pier code for > Seaside 2.8. Shame on me that I still didn't had time to look into > this. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Tue Jan 5 18:07:19 2010 From: renggli at gmail.com (Lukas Renggli) Date: Tue, 5 Jan 2010 18:07:19 +0100 Subject: pier and seaside 3.0 In-Reply-To: <3a06f76f1001050849v441f8857we41fda1b070315e4@mail.gmail.com> References: <3a06f76f1001040827j5792622fv6f0c736e50fd3279@mail.gmail.com> <50d1d2c91001040833q63465847wab90070c20170958@mail.gmail.com> <3a06f76f1001050215s26a7a06ao9346ba7e6b93b9f0@mail.gmail.com> <67628d691001050559s3d98b7d2o7a7e7d40c922cc75@mail.gmail.com> <3a06f76f1001050849v441f8857we41fda1b070315e4@mail.gmail.com> Message-ID: <67628d691001050907x7d001c60l27955359cae74936@mail.gmail.com> 2010/1/5 Nick Ager : > Hi Lukas, > I'm happy to help if you can point me in the right direction. > On a different issue - I'm trying to understand PRPierFrame > class>>exampleBasic and PRPierFrame class>>exampleDocumentation. Browsing > at: localhost:8080/examples/examplebrowser results in WAAtrributeNotFound > but only *with Pier installed*. The problem is in > PRPierFrame>>initialRequest which calls: > ?? self application preferenceAt: #kernel > there's no kernel defined, although it is defined within a PRContext in > exampleBasic. I'm afraid I don't understand enough about how PRKernel and > PRContext are related to WAUserConfiguration to debug further. However this > doesn't just appear to be a 3.0 issue - my 2.8 image with Pier installed > also generates an error when I browse to > localhost:8080/seaside/examples/examplebrowser > Any thoughts? I fixed the example browser thing in: Name: Pier-Seaside-lr.447 Author: lr Time: 5 January 2010, 6:06:35 pm UUID: 97530b50-c2c1-4f49-8a1d-580fae81eae6 Ancestors: Pier-Seaside-lr.445 - fixed the examples Lukas -- Lukas Renggli http://www.lukas-renggli.ch From jfitzell at gmail.com Tue Jan 5 19:38:19 2010 From: jfitzell at gmail.com (Julian Fitzell) Date: Tue, 5 Jan 2010 10:38:19 -0800 Subject: pier and seaside 3.0 In-Reply-To: <67628d691001050559s3d98b7d2o7a7e7d40c922cc75@mail.gmail.com> References: <3a06f76f1001040827j5792622fv6f0c736e50fd3279@mail.gmail.com> <50d1d2c91001040833q63465847wab90070c20170958@mail.gmail.com> <3a06f76f1001050215s26a7a06ao9346ba7e6b93b9f0@mail.gmail.com> <67628d691001050559s3d98b7d2o7a7e7d40c922cc75@mail.gmail.com> Message-ID: <4a5dbd431001051038x5d71d362r9f57e8c254654fc2@mail.gmail.com> On Tue, Jan 5, 2010 at 5:59 AM, Lukas Renggli wrote: >> BTW the load errors: >> "FileList2 is Undeclared", in?MAFileMorph - doesn't seem too concerning as >> I'm only interested in the seaside bindings. > > Yep, the Magritte-Morph is not really required. > >> I ignored the error: "Pier-Core depends on PRPackage class>>pierTestsModel" >> PRCommandTest>>testDate(WAPlatform is undefined) >> PRCommandTest>>testTimestamp (WAPlatform is Undeclared) >> PRPersistencyTest>>testMutexForked(WAPlatform is undefined) >> PRSegmentPersistency>>cleanupSeaside (WAEntryPoint is Undeclared) >> Should I be concerned by any of these load errors? > > That looks like there is version mismatch between Magritte/Pier and Seaside. > > The port of of Magritte/Pier was done for VA Smalltalk by Julian, and > it looks like the code hasn't been adapted to very latest version of > Seaside. Also the code is quite behind the Magritte/Pier code for > Seaside 2.8. Shame on me that I still didn't had time to look into > this. Mmm... yes, I'm having trouble recalling now. Did I do the initial port against Seaside 3.0a4? It's been a couple of months since I branched, so the Magritte/Pier code would definitely be a bit behind the 2.8 codebase and I wouldn't be surprised to know it needs minor updates for the latest Seaside one way or another. I'm also, unfortunately, not actually *using* the port. As Lukas said, I did the port as part of work to then port it to VA smalltalk. Nationaal Spaarfonds would be using it with the version of Seaside distributed by Instantiations (though that should now be a5, so they may need updates as well) but even they aren't yet actively using it I think. Someone, either a Pier developer or a user, needs to start actually *using* the code with the latest Seaside release (I would suggest maybe not the bleeding edge code, though, or nobody will be able to follow) so they can stay on top of fixes and merging in code from the other branch. Otherwise the code will rot, which would be kind of a shame. The changes weren't even that major, but they did require repackaging which makes maintaining the two branches more complicated - I had hoped primary development could move to the new repositories before they diverged too much. Julian From nick.ager at gmail.com Wed Jan 6 00:23:10 2010 From: nick.ager at gmail.com (Nick Ager) Date: Tue, 5 Jan 2010 23:23:10 +0000 Subject: pier and seaside 3.0 In-Reply-To: <4a5dbd431001051038x5d71d362r9f57e8c254654fc2@mail.gmail.com> References: <3a06f76f1001040827j5792622fv6f0c736e50fd3279@mail.gmail.com> <50d1d2c91001040833q63465847wab90070c20170958@mail.gmail.com> <3a06f76f1001050215s26a7a06ao9346ba7e6b93b9f0@mail.gmail.com> <67628d691001050559s3d98b7d2o7a7e7d40c922cc75@mail.gmail.com> <4a5dbd431001051038x5d71d362r9f57e8c254654fc2@mail.gmail.com> Message-ID: <3a06f76f1001051523w4dc623c7g33cb4af7c23405dd@mail.gmail.com> Hi Julian/Lukas, I'm happy to have a go bringing the Pier 3.0 repository upto the latest 2.8 codebase, but I'll need support. For example I'm not sure how to diff code from two different repositories in Pharo..., plus my knowledge of Pier is still rudimentary - but I guess I've got to start somewhere... Would it be a horrendous undertaking?? Nick 2010/1/5 Julian Fitzell > On Tue, Jan 5, 2010 at 5:59 AM, Lukas Renggli wrote: > >> BTW the load errors: > >> "FileList2 is Undeclared", in MAFileMorph - doesn't seem too concerning > as > >> I'm only interested in the seaside bindings. > > > > Yep, the Magritte-Morph is not really required. > > > >> I ignored the error: "Pier-Core depends on PRPackage > class>>pierTestsModel" > >> PRCommandTest>>testDate(WAPlatform is undefined) > >> PRCommandTest>>testTimestamp (WAPlatform is Undeclared) > >> PRPersistencyTest>>testMutexForked(WAPlatform is undefined) > >> PRSegmentPersistency>>cleanupSeaside (WAEntryPoint is Undeclared) > >> Should I be concerned by any of these load errors? > > > > That looks like there is version mismatch between Magritte/Pier and > Seaside. > > > > The port of of Magritte/Pier was done for VA Smalltalk by Julian, and > > it looks like the code hasn't been adapted to very latest version of > > Seaside. Also the code is quite behind the Magritte/Pier code for > > Seaside 2.8. Shame on me that I still didn't had time to look into > > this. > > Mmm... yes, I'm having trouble recalling now. Did I do the initial > port against Seaside 3.0a4? It's been a couple of months since I > branched, so the Magritte/Pier code would definitely be a bit behind > the 2.8 codebase and I wouldn't be surprised to know it needs minor > updates for the latest Seaside one way or another. > > I'm also, unfortunately, not actually *using* the port. As Lukas said, > I did the port as part of work to then port it to VA smalltalk. > Nationaal Spaarfonds would be using it with the version of Seaside > distributed by Instantiations (though that should now be a5, so they > may need updates as well) but even they aren't yet actively using it I > think. > > Someone, either a Pier developer or a user, needs to start actually > *using* the code with the latest Seaside release (I would suggest > maybe not the bleeding edge code, though, or nobody will be able to > follow) so they can stay on top of fixes and merging in code from the > other branch. Otherwise the code will rot, which would be kind of a > shame. The changes weren't even that major, but they did require > repackaging which makes maintaining the two branches more complicated > - I had hoped primary development could move to the new repositories > before they diverged too much. > > Julian > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Wed Jan 6 07:53:22 2010 From: renggli at gmail.com (Lukas Renggli) Date: Wed, 6 Jan 2010 07:53:22 +0100 Subject: pier and seaside 3.0 In-Reply-To: <3a06f76f1001051523w4dc623c7g33cb4af7c23405dd@mail.gmail.com> References: <3a06f76f1001040827j5792622fv6f0c736e50fd3279@mail.gmail.com> <50d1d2c91001040833q63465847wab90070c20170958@mail.gmail.com> <3a06f76f1001050215s26a7a06ao9346ba7e6b93b9f0@mail.gmail.com> <67628d691001050559s3d98b7d2o7a7e7d40c922cc75@mail.gmail.com> <4a5dbd431001051038x5d71d362r9f57e8c254654fc2@mail.gmail.com> <3a06f76f1001051523w4dc623c7g33cb4af7c23405dd@mail.gmail.com> Message-ID: <67628d691001052253o37de9b2eg4859e100ffd97b33@mail.gmail.com> > I'm happy to have a go bringing the Pier 3.0 repository upto the latest 2.8 > codebase, but I'll need support. For example I'm not sure how to diff code > from two different repositories in Pharo..., plus my knowledge of Pier is > still?rudimentary - but I guess I've got to start somewhere... Would it be a > horrendous undertaking?? The process is simple: You load the latest Magritte/Pier 3.0 code into your image, then you add the old Magritte and Pier repositories using the "+Repository" button, open the repository browser on that repository, select the latest version of each package (e.g. Magritte-Core) and click on "Merge". Normally merging should be really easy, but I don't know how much Magritte and Pier changed from the previous version. Also the merging does not work if the packages got renamed. Lukas -- Lukas Renggli http://www.lukas-renggli.ch From jfitzell at gmail.com Wed Jan 6 08:32:48 2010 From: jfitzell at gmail.com (Julian Fitzell) Date: Tue, 5 Jan 2010 23:32:48 -0800 Subject: pier and seaside 3.0 In-Reply-To: <67628d691001052253o37de9b2eg4859e100ffd97b33@mail.gmail.com> References: <3a06f76f1001040827j5792622fv6f0c736e50fd3279@mail.gmail.com> <50d1d2c91001040833q63465847wab90070c20170958@mail.gmail.com> <3a06f76f1001050215s26a7a06ao9346ba7e6b93b9f0@mail.gmail.com> <67628d691001050559s3d98b7d2o7a7e7d40c922cc75@mail.gmail.com> <4a5dbd431001051038x5d71d362r9f57e8c254654fc2@mail.gmail.com> <3a06f76f1001051523w4dc623c7g33cb4af7c23405dd@mail.gmail.com> <67628d691001052253o37de9b2eg4859e100ffd97b33@mail.gmail.com> Message-ID: <4a5dbd431001052332u54386f1bk27679d222ca15729@mail.gmail.com> On Tue, Jan 5, 2010 at 10:53 PM, Lukas Renggli wrote: > Normally merging should be really easy, but I don't know how much > Magritte and Pier changed from the previous version. Also the merging > does not work if the packages got renamed. > In both cases, I pulled platform-specific code out into separate packages (and had to split up the Tests package into smaller chunks). The main packages (-Seaside, -Model, -Security) still have the same names though, so hopefully it won't be *too* bad. For the most part, the changes were *relatively* minor as I recall. I'm certainly happy to answer any questions about my intent, though I suspect my commit messages were relatively clear. You'll have to be careful that the changes you are merging are still platform-safe (ie. some of my commits will have been removing senders of unsafe selectors and the new code you're merging might still use them) but of course whoever next updates one of the other platform ports will catch those eventually if you miss them anyway. Julian -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Wed Jan 6 17:16:56 2010 From: nick.ager at gmail.com (Nick Ager) Date: Wed, 6 Jan 2010 16:16:56 +0000 Subject: pier and seaside 3.0 In-Reply-To: <67628d691001052253o37de9b2eg4859e100ffd97b33@mail.gmail.com> References: <3a06f76f1001040827j5792622fv6f0c736e50fd3279@mail.gmail.com> <50d1d2c91001040833q63465847wab90070c20170958@mail.gmail.com> <3a06f76f1001050215s26a7a06ao9346ba7e6b93b9f0@mail.gmail.com> <67628d691001050559s3d98b7d2o7a7e7d40c922cc75@mail.gmail.com> <4a5dbd431001051038x5d71d362r9f57e8c254654fc2@mail.gmail.com> <3a06f76f1001051523w4dc623c7g33cb4af7c23405dd@mail.gmail.com> <67628d691001052253o37de9b2eg4859e100ffd97b33@mail.gmail.com> Message-ID: <3a06f76f1001060816h639141earf4950e0173d6df5a@mail.gmail.com> I've created a fresh seaside3.0a5 image, loaded Magritte and Pier into it and I've failed at the first merge hurdle. I'm starting with Magritte-Model and when I try merging from 'http://source.lukas-renggli.ch/magritte' I get the error: 'Could not find version ''Magritte-Model-lr.358''. Maybe you need to add a repository?' any thoughts on my beginners error? Thanks Nick 2010/1/6 Lukas Renggli > > I'm happy to have a go bringing the Pier 3.0 repository upto the latest > 2.8 > > codebase, but I'll need support. For example I'm not sure how to diff > code > > from two different repositories in Pharo..., plus my knowledge of Pier is > > still rudimentary - but I guess I've got to start somewhere... Would it > be a > > horrendous undertaking?? > > The process is simple: You load the latest Magritte/Pier 3.0 code into > your image, then you add the old Magritte and Pier repositories using > the "+Repository" button, open the repository browser on that > repository, select the latest version of each package (e.g. > Magritte-Core) and click on "Merge". > > Normally merging should be really easy, but I don't know how much > Magritte and Pier changed from the previous version. Also the merging > does not work if the packages got renamed. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Wed Jan 6 17:45:25 2010 From: nick.ager at gmail.com (Nick Ager) Date: Wed, 6 Jan 2010 16:45:25 +0000 Subject: pier and seaside 3.0 In-Reply-To: <3a06f76f1001060816h639141earf4950e0173d6df5a@mail.gmail.com> References: <3a06f76f1001040827j5792622fv6f0c736e50fd3279@mail.gmail.com> <50d1d2c91001040833q63465847wab90070c20170958@mail.gmail.com> <3a06f76f1001050215s26a7a06ao9346ba7e6b93b9f0@mail.gmail.com> <67628d691001050559s3d98b7d2o7a7e7d40c922cc75@mail.gmail.com> <4a5dbd431001051038x5d71d362r9f57e8c254654fc2@mail.gmail.com> <3a06f76f1001051523w4dc623c7g33cb4af7c23405dd@mail.gmail.com> <67628d691001052253o37de9b2eg4859e100ffd97b33@mail.gmail.com> <3a06f76f1001060816h639141earf4950e0173d6df5a@mail.gmail.com> Message-ID: <3a06f76f1001060845gb2a578m31a281a3cc551203@mail.gmail.com> While I'm stuck with the merge errors I had a look at the load errors: PRCommandTest>>testTime (WAPlatform is Undeclared) PRCommandTest>>testTimestamp (WAPlatform is Undeclared) PRCommandTest>>testDate (WAPlatform is Undeclared) PRPersistencyTest>>testMutexForked (WAPlatform is Undeclared) PRSegmentPersistency>>cleanupSeaside (WAEntryPoint is Undeclared) They were easy to fix simply by changing WAPlatform to GRPlatform. However I'm uncertain how to changethe code in PRSegmentPersistency>>cleanupSeaside: cleanupSeaside "Clear all the entry points that reference other entry points, state and continuations by overriding them with a blank version. Do not try to call #clearAllHandlers because this spawns a new process. Also dump the default dispatcher just to be sure." WAEntryPoint allSubInstances do: [ :entry | entry copyFrom: entry class basicNew ]. WADispatcher instVarNamed: 'default' put: nil My best guess is to replace the code with the call: WARegistry clearAll marks out out 10? 2010/1/6 Nick Ager > I've created a fresh seaside3.0a5 image, loaded Magritte and Pier into it > and I've failed at the first merge hurdle. I'm starting with Magritte-Model > and when I try merging from 'http://source.lukas-renggli.ch/magritte' I > get the error: > > 'Could not find version ''Magritte-Model-lr.358''. Maybe you need to add a > repository?' > > any thoughts on my beginners error? > > Thanks Nick > > 2010/1/6 Lukas Renggli > > > I'm happy to have a go bringing the Pier 3.0 repository upto the latest >> 2.8 >> > codebase, but I'll need support. For example I'm not sure how to diff >> code >> > from two different repositories in Pharo..., plus my knowledge of Pier >> is >> > still rudimentary - but I guess I've got to start somewhere... Would it >> be a >> > horrendous undertaking?? >> >> The process is simple: You load the latest Magritte/Pier 3.0 code into >> your image, then you add the old Magritte and Pier repositories using >> the "+Repository" button, open the repository browser on that >> repository, select the latest version of each package (e.g. >> Magritte-Core) and click on "Merge". >> >> Normally merging should be really easy, but I don't know how much >> Magritte and Pier changed from the previous version. Also the merging >> does not work if the packages got renamed. >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Wed Jan 6 19:05:31 2010 From: nick.ager at gmail.com (Nick Ager) Date: Wed, 6 Jan 2010 18:05:31 +0000 Subject: pier and seaside 3.0 In-Reply-To: <3a06f76f1001060845gb2a578m31a281a3cc551203@mail.gmail.com> References: <3a06f76f1001040827j5792622fv6f0c736e50fd3279@mail.gmail.com> <50d1d2c91001040833q63465847wab90070c20170958@mail.gmail.com> <3a06f76f1001050215s26a7a06ao9346ba7e6b93b9f0@mail.gmail.com> <67628d691001050559s3d98b7d2o7a7e7d40c922cc75@mail.gmail.com> <4a5dbd431001051038x5d71d362r9f57e8c254654fc2@mail.gmail.com> <3a06f76f1001051523w4dc623c7g33cb4af7c23405dd@mail.gmail.com> <67628d691001052253o37de9b2eg4859e100ffd97b33@mail.gmail.com> <3a06f76f1001060816h639141earf4950e0173d6df5a@mail.gmail.com> <3a06f76f1001060845gb2a578m31a281a3cc551203@mail.gmail.com> Message-ID: <3a06f76f1001061005s52e72124uc593a1bc1efdbda5@mail.gmail.com> I thought I'd try merging these trivial changes (minus cleanupSeaside), but when I checked the changes I was about to check in I noticed that a lot of the methods had changed. My installation script loads the packages in the following order: Pier-Tests, Pier-Tests-Model, Pier-Tests-Security. Here I show my ignorance again. I'm assuming that Pier-Tests should be a "super package" for Pier-Tests-Model and Pier-Test-Security, however it seems that there's a significant difference between the packages. I'm assuming that Pier-Tests-Model and Pier-Tests_Security supersedes Pier-Tests as the date stamps are later (September vs November). In which case I should check my changes into Pier-Tests-Model and then check in Pier-Tests so that the packages are again consistent. Does that make sense? Nick 2010/1/6 Nick Ager > While I'm stuck with the merge errors I had a look at the load errors: > > PRCommandTest>>testTime (WAPlatform is Undeclared) > > PRCommandTest>>testTimestamp (WAPlatform is Undeclared) > > PRCommandTest>>testDate (WAPlatform is Undeclared) > > PRPersistencyTest>>testMutexForked (WAPlatform is Undeclared) > > PRSegmentPersistency>>cleanupSeaside (WAEntryPoint is Undeclared) > > They were easy to fix simply by changing WAPlatform to GRPlatform. > > However I'm uncertain how to changethe code in > PRSegmentPersistency>>cleanupSeaside: > > cleanupSeaside > "Clear all the entry points that reference other entry points, state and > continuations by overriding them with a blank version. Do not try to call > #clearAllHandlers because this spawns a new process. Also dump the default > dispatcher just to be sure." > > > WAEntryPoint allSubInstances > do: [ :entry | entry copyFrom: entry class basicNew ]. > WADispatcher instVarNamed: 'default' put: nil > > My best guess is to replace the code with the call: > WARegistry clearAll > > marks out out 10? > > 2010/1/6 Nick Ager > > I've created a fresh seaside3.0a5 image, loaded Magritte and Pier into it >> and I've failed at the first merge hurdle. I'm starting with Magritte-Model >> and when I try merging from 'http://source.lukas-renggli.ch/magritte' I >> get the error: >> >> 'Could not find version ''Magritte-Model-lr.358''. Maybe you need to add a >> repository?' >> >> any thoughts on my beginners error? >> >> Thanks Nick >> >> 2010/1/6 Lukas Renggli >> >> > I'm happy to have a go bringing the Pier 3.0 repository upto the latest >>> 2.8 >>> > codebase, but I'll need support. For example I'm not sure how to diff >>> code >>> > from two different repositories in Pharo..., plus my knowledge of Pier >>> is >>> > still rudimentary - but I guess I've got to start somewhere... Would it >>> be a >>> > horrendous undertaking?? >>> >>> The process is simple: You load the latest Magritte/Pier 3.0 code into >>> your image, then you add the old Magritte and Pier repositories using >>> the "+Repository" button, open the repository browser on that >>> repository, select the latest version of each package (e.g. >>> Magritte-Core) and click on "Merge". >>> >>> Normally merging should be really easy, but I don't know how much >>> Magritte and Pier changed from the previous version. Also the merging >>> does not work if the packages got renamed. >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Magritte, Pier and Related Tools ... >>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfitzell at gmail.com Wed Jan 6 19:18:12 2010 From: jfitzell at gmail.com (Julian Fitzell) Date: Wed, 6 Jan 2010 10:18:12 -0800 Subject: pier and seaside 3.0 In-Reply-To: <3a06f76f1001061005s52e72124uc593a1bc1efdbda5@mail.gmail.com> References: <3a06f76f1001040827j5792622fv6f0c736e50fd3279@mail.gmail.com> <50d1d2c91001040833q63465847wab90070c20170958@mail.gmail.com> <3a06f76f1001050215s26a7a06ao9346ba7e6b93b9f0@mail.gmail.com> <67628d691001050559s3d98b7d2o7a7e7d40c922cc75@mail.gmail.com> <4a5dbd431001051038x5d71d362r9f57e8c254654fc2@mail.gmail.com> <3a06f76f1001051523w4dc623c7g33cb4af7c23405dd@mail.gmail.com> <67628d691001052253o37de9b2eg4859e100ffd97b33@mail.gmail.com> <3a06f76f1001060816h639141earf4950e0173d6df5a@mail.gmail.com> <3a06f76f1001060845gb2a578m31a281a3cc551203@mail.gmail.com> <3a06f76f1001061005s52e72124uc593a1bc1efdbda5@mail.gmail.com> Message-ID: <4a5dbd431001061018l6bc23f8ck996f024daf8b0624@mail.gmail.com> You're sort of right on both counts. Monticello will consider the contents of -Tests-Security and -Tests-Model to also be part of -Tests. -Tests is no longer part of the code in the new repositories, though, because it was split into the various smaller packages. You shouldn't need to commit new versions of Pier-Tests to the /pier2 repository. Hopefully you can merge in the newest -Tests from /pier, move any new classes around as necessary and then commit the changes to -Tests-Security and -Tests-Model, etc. You'll need to pay very close attention to the diffs of packages as you are committing though to make sure you haven't lost code or added code that you don't intend (glad to see you're looking at the diffs already! :) ). Julian On Wed, Jan 6, 2010 at 10:05 AM, Nick Ager wrote: > I thought I'd try merging these trivial changes (minus cleanupSeaside), but > when I checked the changes I was about to check in I noticed that a lot of > the methods had changed. My installation script loads the packages in the > following order: Pier-Tests, Pier-Tests-Model, Pier-Tests-Security. Here I > show my ignorance again. I'm assuming that Pier-Tests should be a "super > package" for Pier-Tests-Model and Pier-Test-Security, however it seems that > there's a significant difference between the packages. I'm assuming that > Pier-Tests-Model and Pier-Tests_Security supersedes Pier-Tests as the date > stamps are later (September vs November). In which case I should check my > changes into Pier-Tests-Model and then check in Pier-Tests so that the > packages are again consistent. Does that make sense? > > Nick > > > 2010/1/6 Nick Ager > >> While I'm stuck with the merge errors I had a look at the load errors: >> >> PRCommandTest>>testTime (WAPlatform is Undeclared) >> >> PRCommandTest>>testTimestamp (WAPlatform is Undeclared) >> >> PRCommandTest>>testDate (WAPlatform is Undeclared) >> >> PRPersistencyTest>>testMutexForked (WAPlatform is Undeclared) >> >> PRSegmentPersistency>>cleanupSeaside (WAEntryPoint is Undeclared) >> >> They were easy to fix simply by changing WAPlatform to GRPlatform. >> >> However I'm uncertain how to changethe code in >> PRSegmentPersistency>>cleanupSeaside: >> >> cleanupSeaside >> "Clear all the entry points that reference other entry points, state and >> continuations by overriding them with a blank version. Do not try to call >> #clearAllHandlers because this spawns a new process. Also dump the default >> dispatcher just to be sure." >> >> >> WAEntryPoint allSubInstances >> do: [ :entry | entry copyFrom: entry class basicNew ]. >> WADispatcher instVarNamed: 'default' put: nil >> >> My best guess is to replace the code with the call: >> WARegistry clearAll >> >> marks out out 10? >> >> 2010/1/6 Nick Ager >> >> I've created a fresh seaside3.0a5 image, loaded Magritte and Pier into it >>> and I've failed at the first merge hurdle. I'm starting with Magritte-Model >>> and when I try merging from 'http://source.lukas-renggli.ch/magritte' I >>> get the error: >>> >>> 'Could not find version ''Magritte-Model-lr.358''. Maybe you need to add >>> a repository?' >>> >>> any thoughts on my beginners error? >>> >>> Thanks Nick >>> >>> 2010/1/6 Lukas Renggli >>> >>> > I'm happy to have a go bringing the Pier 3.0 repository upto the latest >>>> 2.8 >>>> > codebase, but I'll need support. For example I'm not sure how to diff >>>> code >>>> > from two different repositories in Pharo..., plus my knowledge of Pier >>>> is >>>> > still rudimentary - but I guess I've got to start somewhere... Would >>>> it be a >>>> > horrendous undertaking?? >>>> >>>> The process is simple: You load the latest Magritte/Pier 3.0 code into >>>> your image, then you add the old Magritte and Pier repositories using >>>> the "+Repository" button, open the repository browser on that >>>> repository, select the latest version of each package (e.g. >>>> Magritte-Core) and click on "Merge". >>>> >>>> Normally merging should be really easy, but I don't know how much >>>> Magritte and Pier changed from the previous version. Also the merging >>>> does not work if the packages got renamed. >>>> >>>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Wed Jan 6 19:28:57 2010 From: nick.ager at gmail.com (Nick Ager) Date: Wed, 6 Jan 2010 18:28:57 +0000 Subject: pier and seaside 3.0 In-Reply-To: <4a5dbd431001061018l6bc23f8ck996f024daf8b0624@mail.gmail.com> References: <3a06f76f1001040827j5792622fv6f0c736e50fd3279@mail.gmail.com> <3a06f76f1001050215s26a7a06ao9346ba7e6b93b9f0@mail.gmail.com> <67628d691001050559s3d98b7d2o7a7e7d40c922cc75@mail.gmail.com> <4a5dbd431001051038x5d71d362r9f57e8c254654fc2@mail.gmail.com> <3a06f76f1001051523w4dc623c7g33cb4af7c23405dd@mail.gmail.com> <67628d691001052253o37de9b2eg4859e100ffd97b33@mail.gmail.com> <3a06f76f1001060816h639141earf4950e0173d6df5a@mail.gmail.com> <3a06f76f1001060845gb2a578m31a281a3cc551203@mail.gmail.com> <3a06f76f1001061005s52e72124uc593a1bc1efdbda5@mail.gmail.com> <4a5dbd431001061018l6bc23f8ck996f024daf8b0624@mail.gmail.com> Message-ID: <3a06f76f1001061028ma013e0cpd898296fa279ebcb@mail.gmail.com> Hi Julian, I'm very confused. I reloaded Pier-Tests-Model manually and it turns out that the correct code was already in place ie s/WAPlatform/GRPlatform & s/seasideString/greaseString/ All I can guess is that Pier-Tests loaded after Pier-Tests-Model even though it's later in my Gofer script. Pier-Tests is in the http://source.lukas-renggli.ch/pier2 repository. My interpretation of what you say is that either it shouldn't exist or the code in it should be consistent with Pier-Tests-* Can you clarify Thanks Nick 2010/1/6 Julian Fitzell > You're sort of right on both counts. Monticello will consider the contents > of -Tests-Security and -Tests-Model to also be part of -Tests. -Tests is no > longer part of the code in the new repositories, though, because it was > split into the various smaller packages. You shouldn't need to commit new > versions of Pier-Tests to the /pier2 repository. Hopefully you can merge in > the newest -Tests from /pier, move any new classes around as necessary and > then commit the changes to -Tests-Security and -Tests-Model, etc. You'll > need to pay very close attention to the diffs of packages as you are > committing though to make sure you haven't lost code or added code that you > don't intend (glad to see you're looking at the diffs already! :) ). > > Julian > > > On Wed, Jan 6, 2010 at 10:05 AM, Nick Ager wrote: > >> I thought I'd try merging these trivial changes (minus cleanupSeaside), >> but when I checked the changes I was about to check in I noticed that a lot >> of the methods had changed. My installation script loads the packages in the >> following order: Pier-Tests, Pier-Tests-Model, Pier-Tests-Security. Here I >> show my ignorance again. I'm assuming that Pier-Tests should be a "super >> package" for Pier-Tests-Model and Pier-Test-Security, however it seems that >> there's a significant difference between the packages. I'm assuming that >> Pier-Tests-Model and Pier-Tests_Security supersedes Pier-Tests as the date >> stamps are later (September vs November). In which case I should check my >> changes into Pier-Tests-Model and then check in Pier-Tests so that the >> packages are again consistent. Does that make sense? >> >> Nick >> >> >> 2010/1/6 Nick Ager >> >>> While I'm stuck with the merge errors I had a look at the load errors: >>> >>> PRCommandTest>>testTime (WAPlatform is Undeclared) >>> >>> PRCommandTest>>testTimestamp (WAPlatform is Undeclared) >>> >>> PRCommandTest>>testDate (WAPlatform is Undeclared) >>> >>> PRPersistencyTest>>testMutexForked (WAPlatform is Undeclared) >>> >>> PRSegmentPersistency>>cleanupSeaside (WAEntryPoint is Undeclared) >>> >>> They were easy to fix simply by changing WAPlatform to GRPlatform. >>> >>> However I'm uncertain how to changethe code in >>> PRSegmentPersistency>>cleanupSeaside: >>> >>> cleanupSeaside >>> "Clear all the entry points that reference other entry points, state and >>> continuations by overriding them with a blank version. Do not try to call >>> #clearAllHandlers because this spawns a new process. Also dump the default >>> dispatcher just to be sure." >>> >>> >>> WAEntryPoint allSubInstances >>> do: [ :entry | entry copyFrom: entry class basicNew ]. >>> WADispatcher instVarNamed: 'default' put: nil >>> >>> My best guess is to replace the code with the call: >>> WARegistry clearAll >>> >>> marks out out 10? >>> >>> 2010/1/6 Nick Ager >>> >>> I've created a fresh seaside3.0a5 image, loaded Magritte and Pier into it >>>> and I've failed at the first merge hurdle. I'm starting with Magritte-Model >>>> and when I try merging from 'http://source.lukas-renggli.ch/magritte' I >>>> get the error: >>>> >>>> 'Could not find version ''Magritte-Model-lr.358''. Maybe you need to add >>>> a repository?' >>>> >>>> any thoughts on my beginners error? >>>> >>>> Thanks Nick >>>> >>>> 2010/1/6 Lukas Renggli >>>> >>>> > I'm happy to have a go bringing the Pier 3.0 repository upto the >>>>> latest 2.8 >>>>> > codebase, but I'll need support. For example I'm not sure how to diff >>>>> code >>>>> > from two different repositories in Pharo..., plus my knowledge of >>>>> Pier is >>>>> > still rudimentary - but I guess I've got to start somewhere... Would >>>>> it be a >>>>> > horrendous undertaking?? >>>>> >>>>> The process is simple: You load the latest Magritte/Pier 3.0 code into >>>>> your image, then you add the old Magritte and Pier repositories using >>>>> the "+Repository" button, open the repository browser on that >>>>> repository, select the latest version of each package (e.g. >>>>> Magritte-Core) and click on "Merge". >>>>> >>>>> Normally merging should be really easy, but I don't know how much >>>>> Magritte and Pier changed from the previous version. Also the merging >>>>> does not work if the packages got renamed. >>>>> >>>>> 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 >> > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Thu Jan 7 08:40:10 2010 From: nick.ager at gmail.com (Nick Ager) Date: Thu, 7 Jan 2010 07:40:10 +0000 Subject: pier and seaside 3.0 In-Reply-To: <3a06f76f1001060816h639141earf4950e0173d6df5a@mail.gmail.com> References: <3a06f76f1001040827j5792622fv6f0c736e50fd3279@mail.gmail.com> <50d1d2c91001040833q63465847wab90070c20170958@mail.gmail.com> <3a06f76f1001050215s26a7a06ao9346ba7e6b93b9f0@mail.gmail.com> <67628d691001050559s3d98b7d2o7a7e7d40c922cc75@mail.gmail.com> <4a5dbd431001051038x5d71d362r9f57e8c254654fc2@mail.gmail.com> <3a06f76f1001051523w4dc623c7g33cb4af7c23405dd@mail.gmail.com> <67628d691001052253o37de9b2eg4859e100ffd97b33@mail.gmail.com> <3a06f76f1001060816h639141earf4950e0173d6df5a@mail.gmail.com> Message-ID: <3a06f76f1001062340g7edcae1fx76a28bf49a99ead7@mail.gmail.com> Any ideas on why I get the following error message when I press merge from the original pier repository: 'Could not find version ''Magritte-Model-lr.358''. Maybe you need to add a repository?' However the changes button works as I'd expect. 2010/1/6 Nick Ager > I've created a fresh seaside3.0a5 image, loaded Magritte and Pier into it > and I've failed at the first merge hurdle. I'm starting with Magritte-Model > and when I try merging from 'http://source.lukas-renggli.ch/magritte' I > get the error: > > 'Could not find version ''Magritte-Model-lr.358''. Maybe you need to add a > repository?' > > any thoughts on my beginners error? > > Thanks Nick > > 2010/1/6 Lukas Renggli > > > I'm happy to have a go bringing the Pier 3.0 repository upto the latest >> 2.8 >> > codebase, but I'll need support. For example I'm not sure how to diff >> code >> > from two different repositories in Pharo..., plus my knowledge of Pier >> is >> > still rudimentary - but I guess I've got to start somewhere... Would it >> be a >> > horrendous undertaking?? >> >> The process is simple: You load the latest Magritte/Pier 3.0 code into >> your image, then you add the old Magritte and Pier repositories using >> the "+Repository" button, open the repository browser on that >> repository, select the latest version of each package (e.g. >> Magritte-Core) and click on "Merge". >> >> Normally merging should be really easy, but I don't know how much >> Magritte and Pier changed from the previous version. Also the merging >> does not work if the packages got renamed. >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Thu Jan 7 08:50:56 2010 From: renggli at gmail.com (Lukas Renggli) Date: Thu, 7 Jan 2010 08:50:56 +0100 Subject: pier and seaside 3.0 In-Reply-To: <3a06f76f1001062340g7edcae1fx76a28bf49a99ead7@mail.gmail.com> References: <3a06f76f1001040827j5792622fv6f0c736e50fd3279@mail.gmail.com> <50d1d2c91001040833q63465847wab90070c20170958@mail.gmail.com> <3a06f76f1001050215s26a7a06ao9346ba7e6b93b9f0@mail.gmail.com> <67628d691001050559s3d98b7d2o7a7e7d40c922cc75@mail.gmail.com> <4a5dbd431001051038x5d71d362r9f57e8c254654fc2@mail.gmail.com> <3a06f76f1001051523w4dc623c7g33cb4af7c23405dd@mail.gmail.com> <67628d691001052253o37de9b2eg4859e100ffd97b33@mail.gmail.com> <3a06f76f1001060816h639141earf4950e0173d6df5a@mail.gmail.com> <3a06f76f1001062340g7edcae1fx76a28bf49a99ead7@mail.gmail.com> Message-ID: <67628d691001062350q1d12620cp55a3a1d79a26ca8d@mail.gmail.com> That version is in http://source.lukas-renggli.ch/magritte and is needed to merge because it is a common ancestor of the two version you are merging. Are you sure that Magritte-Model has http://source.lukas-renggli.ch/magritte as a repository added? Lukas 2010/1/7 Nick Ager : > Any ideas on why I get the following?error message when I press merge from > the original pier repository: 'Could not find version > ''Magritte-Model-lr.358''. Maybe you need to add a repository?' > However the changes button works as I'd expect. > 2010/1/6 Nick Ager >> >> I've created a fresh seaside3.0a5 image, loaded Magritte and Pier into it >> and I've failed at the first merge hurdle. I'm starting with Magritte-Model >> and when I try merging from 'http://source.lukas-renggli.ch/magritte' I get >> the error: >> 'Could not find version ''Magritte-Model-lr.358''. Maybe you need to add a >> repository?' >> >> any thoughts on my beginners error? >> Thanks Nick >> 2010/1/6 Lukas Renggli >>> >>> > I'm happy to have a go bringing the Pier 3.0 repository upto the latest >>> > 2.8 >>> > codebase, but I'll need support. For example I'm not sure how to diff >>> > code >>> > from two different repositories in Pharo..., plus my knowledge of Pier >>> > is >>> > still?rudimentary - but I guess I've got to start somewhere... Would it >>> > be a >>> > horrendous undertaking?? >>> >>> The process is simple: You load the latest Magritte/Pier 3.0 code into >>> your image, then you add the old Magritte and Pier repositories using >>> the "+Repository" button, open the repository browser on that >>> repository, select the latest version of each package (e.g. >>> Magritte-Core) and click on "Merge". >>> >>> Normally merging should be really easy, but I don't know how much >>> Magritte and Pier changed from the previous version. Also the merging >>> does not work if the packages got renamed. >>> >>> 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 From jfitzell at gmail.com Thu Jan 7 08:55:12 2010 From: jfitzell at gmail.com (Julian Fitzell) Date: Wed, 6 Jan 2010 23:55:12 -0800 Subject: pier and seaside 3.0 In-Reply-To: <3a06f76f1001061028ma013e0cpd898296fa279ebcb@mail.gmail.com> References: <3a06f76f1001040827j5792622fv6f0c736e50fd3279@mail.gmail.com> <67628d691001050559s3d98b7d2o7a7e7d40c922cc75@mail.gmail.com> <4a5dbd431001051038x5d71d362r9f57e8c254654fc2@mail.gmail.com> <3a06f76f1001051523w4dc623c7g33cb4af7c23405dd@mail.gmail.com> <67628d691001052253o37de9b2eg4859e100ffd97b33@mail.gmail.com> <3a06f76f1001060816h639141earf4950e0173d6df5a@mail.gmail.com> <3a06f76f1001060845gb2a578m31a281a3cc551203@mail.gmail.com> <3a06f76f1001061005s52e72124uc593a1bc1efdbda5@mail.gmail.com> <4a5dbd431001061018l6bc23f8ck996f024daf8b0624@mail.gmail.com> <3a06f76f1001061028ma013e0cpd898296fa279ebcb@mail.gmail.com> Message-ID: <4a5dbd431001062355g659773d2n7411be5321297010@mail.gmail.com> No, it's there because I made modifications to it before splitting it into several smaller packages. The versions of Pier-Tests form part of the history of my development but are no longer part of the "current state" of the project (ie. at some point I unloaded Pier-Tests from my image). I don't think it should be removed from the repository because it does form part of the development history, but you definitely shouldn't be loading it (other than possibly to merge changes from the other branch forward, of course). Julian On Wed, Jan 6, 2010 at 10:28 AM, Nick Ager wrote: > Hi Julian, > > I'm very confused. I reloaded Pier-Tests-Model manually and it turns out > that the correct code was already in place ie s/WAPlatform/GRPlatform & > s/seasideString/greaseString/ All I can guess is that Pier-Tests loaded > after Pier-Tests-Model even though it's later in my Gofer script. Pier-Tests > is in the http://source.lukas-renggli.ch/pier2 repository. My > interpretation of what you say is that either it shouldn't exist or the code > in it should be consistent with Pier-Tests-* Can you clarify > > Thanks > > Nick > > 2010/1/6 Julian Fitzell > > You're sort of right on both counts. Monticello will consider the contents >> of -Tests-Security and -Tests-Model to also be part of -Tests. -Tests is no >> longer part of the code in the new repositories, though, because it was >> split into the various smaller packages. You shouldn't need to commit new >> versions of Pier-Tests to the /pier2 repository. Hopefully you can merge in >> the newest -Tests from /pier, move any new classes around as necessary and >> then commit the changes to -Tests-Security and -Tests-Model, etc. You'll >> need to pay very close attention to the diffs of packages as you are >> committing though to make sure you haven't lost code or added code that you >> don't intend (glad to see you're looking at the diffs already! :) ). >> >> Julian >> >> >> On Wed, Jan 6, 2010 at 10:05 AM, Nick Ager wrote: >> >>> I thought I'd try merging these trivial changes (minus cleanupSeaside), >>> but when I checked the changes I was about to check in I noticed that a lot >>> of the methods had changed. My installation script loads the packages in the >>> following order: Pier-Tests, Pier-Tests-Model, Pier-Tests-Security. Here I >>> show my ignorance again. I'm assuming that Pier-Tests should be a "super >>> package" for Pier-Tests-Model and Pier-Test-Security, however it seems that >>> there's a significant difference between the packages. I'm assuming that >>> Pier-Tests-Model and Pier-Tests_Security supersedes Pier-Tests as the date >>> stamps are later (September vs November). In which case I should check my >>> changes into Pier-Tests-Model and then check in Pier-Tests so that the >>> packages are again consistent. Does that make sense? >>> >>> Nick >>> >>> >>> 2010/1/6 Nick Ager >>> >>>> While I'm stuck with the merge errors I had a look at the load errors: >>>> >>>> PRCommandTest>>testTime (WAPlatform is Undeclared) >>>> >>>> PRCommandTest>>testTimestamp (WAPlatform is Undeclared) >>>> >>>> PRCommandTest>>testDate (WAPlatform is Undeclared) >>>> >>>> PRPersistencyTest>>testMutexForked (WAPlatform is Undeclared) >>>> >>>> PRSegmentPersistency>>cleanupSeaside (WAEntryPoint is Undeclared) >>>> >>>> They were easy to fix simply by changing WAPlatform to GRPlatform. >>>> >>>> However I'm uncertain how to changethe code in >>>> PRSegmentPersistency>>cleanupSeaside: >>>> >>>> cleanupSeaside >>>> "Clear all the entry points that reference other entry points, state and >>>> continuations by overriding them with a blank version. Do not try to call >>>> #clearAllHandlers because this spawns a new process. Also dump the default >>>> dispatcher just to be sure." >>>> >>>> >>>> WAEntryPoint allSubInstances >>>> do: [ :entry | entry copyFrom: entry class basicNew ]. >>>> WADispatcher instVarNamed: 'default' put: nil >>>> >>>> My best guess is to replace the code with the call: >>>> WARegistry clearAll >>>> >>>> marks out out 10? >>>> >>>> 2010/1/6 Nick Ager >>>> >>>> I've created a fresh seaside3.0a5 image, loaded Magritte and Pier into >>>>> it and I've failed at the first merge hurdle. I'm starting with >>>>> Magritte-Model and when I try merging from ' >>>>> http://source.lukas-renggli.ch/magritte' I get the error: >>>>> >>>>> 'Could not find version ''Magritte-Model-lr.358''. Maybe you need to >>>>> add a repository?' >>>>> >>>>> any thoughts on my beginners error? >>>>> >>>>> Thanks Nick >>>>> >>>>> 2010/1/6 Lukas Renggli >>>>> >>>>> > I'm happy to have a go bringing the Pier 3.0 repository upto the >>>>>> latest 2.8 >>>>>> > codebase, but I'll need support. For example I'm not sure how to >>>>>> diff code >>>>>> > from two different repositories in Pharo..., plus my knowledge of >>>>>> Pier is >>>>>> > still rudimentary - but I guess I've got to start somewhere... Would >>>>>> it be a >>>>>> > horrendous undertaking?? >>>>>> >>>>>> The process is simple: You load the latest Magritte/Pier 3.0 code into >>>>>> your image, then you add the old Magritte and Pier repositories using >>>>>> the "+Repository" button, open the repository browser on that >>>>>> repository, select the latest version of each package (e.g. >>>>>> Magritte-Core) and click on "Merge". >>>>>> >>>>>> Normally merging should be really easy, but I don't know how much >>>>>> Magritte and Pier changed from the previous version. Also the merging >>>>>> does not work if the packages got renamed. >>>>>> >>>>>> 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 >>> >> >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Thu Jan 7 08:57:27 2010 From: nick.ager at gmail.com (Nick Ager) Date: Thu, 7 Jan 2010 07:57:27 +0000 Subject: pier and seaside 3.0 In-Reply-To: <67628d691001062350q1d12620cp55a3a1d79a26ca8d@mail.gmail.com> References: <3a06f76f1001040827j5792622fv6f0c736e50fd3279@mail.gmail.com> <50d1d2c91001040833q63465847wab90070c20170958@mail.gmail.com> <3a06f76f1001050215s26a7a06ao9346ba7e6b93b9f0@mail.gmail.com> <67628d691001050559s3d98b7d2o7a7e7d40c922cc75@mail.gmail.com> <4a5dbd431001051038x5d71d362r9f57e8c254654fc2@mail.gmail.com> <3a06f76f1001051523w4dc623c7g33cb4af7c23405dd@mail.gmail.com> <67628d691001052253o37de9b2eg4859e100ffd97b33@mail.gmail.com> <3a06f76f1001060816h639141earf4950e0173d6df5a@mail.gmail.com> <3a06f76f1001062340g7edcae1fx76a28bf49a99ead7@mail.gmail.com> <67628d691001062350q1d12620cp55a3a1d79a26ca8d@mail.gmail.com> Message-ID: <3a06f76f1001062357i1b04057cn48da0ac49fce638a@mail.gmail.com> Suddenly it seems to work. I looked at a merge on the common ancestor then gradually worked forward in time and found merge to be working on the most recent version, which previously produced the error I mentioned. Very odd, but happy I can make progress, though still a little mystified... 2010/1/7 Lukas Renggli > That version is in http://source.lukas-renggli.ch/magritte and is > needed to merge because it is a common ancestor of the two version you > are merging. Are you sure that Magritte-Model has > http://source.lukas-renggli.ch/magritte as a repository added? > > Lukas > > 2010/1/7 Nick Ager : > > Any ideas on why I get the following error message when I press merge > from > > the original pier repository: 'Could not find version > > ''Magritte-Model-lr.358''. Maybe you need to add a repository?' > > However the changes button works as I'd expect. > > 2010/1/6 Nick Ager > >> > >> I've created a fresh seaside3.0a5 image, loaded Magritte and Pier into > it > >> and I've failed at the first merge hurdle. I'm starting with > Magritte-Model > >> and when I try merging from 'http://source.lukas-renggli.ch/magritte' I > get > >> the error: > >> 'Could not find version ''Magritte-Model-lr.358''. Maybe you need to add > a > >> repository?' > >> > >> any thoughts on my beginners error? > >> Thanks Nick > >> 2010/1/6 Lukas Renggli > >>> > >>> > I'm happy to have a go bringing the Pier 3.0 repository upto the > latest > >>> > 2.8 > >>> > codebase, but I'll need support. For example I'm not sure how to diff > >>> > code > >>> > from two different repositories in Pharo..., plus my knowledge of > Pier > >>> > is > >>> > still rudimentary - but I guess I've got to start somewhere... Would > it > >>> > be a > >>> > horrendous undertaking?? > >>> > >>> The process is simple: You load the latest Magritte/Pier 3.0 code into > >>> your image, then you add the old Magritte and Pier repositories using > >>> the "+Repository" button, open the repository browser on that > >>> repository, select the latest version of each package (e.g. > >>> Magritte-Core) and click on "Merge". > >>> > >>> Normally merging should be really easy, but I don't know how much > >>> Magritte and Pier changed from the previous version. Also the merging > >>> does not work if the packages got renamed. > >>> > >>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Thu Jan 7 09:02:30 2010 From: nick.ager at gmail.com (Nick Ager) Date: Thu, 7 Jan 2010 08:02:30 +0000 Subject: pier and seaside 3.0 In-Reply-To: <4a5dbd431001062355g659773d2n7411be5321297010@mail.gmail.com> References: <3a06f76f1001040827j5792622fv6f0c736e50fd3279@mail.gmail.com> <4a5dbd431001051038x5d71d362r9f57e8c254654fc2@mail.gmail.com> <3a06f76f1001051523w4dc623c7g33cb4af7c23405dd@mail.gmail.com> <67628d691001052253o37de9b2eg4859e100ffd97b33@mail.gmail.com> <3a06f76f1001060816h639141earf4950e0173d6df5a@mail.gmail.com> <3a06f76f1001060845gb2a578m31a281a3cc551203@mail.gmail.com> <3a06f76f1001061005s52e72124uc593a1bc1efdbda5@mail.gmail.com> <4a5dbd431001061018l6bc23f8ck996f024daf8b0624@mail.gmail.com> <3a06f76f1001061028ma013e0cpd898296fa279ebcb@mail.gmail.com> <4a5dbd431001062355g659773d2n7411be5321297010@mail.gmail.com> Message-ID: <3a06f76f1001070002s46d426c9g10df2b7562431807@mail.gmail.com> OK - I'll ignore Pier-Tests and focus on Pier-Tests-* instead. Thanks for patiently answering my beginner's questions. 2010/1/7 Julian Fitzell > No, it's there because I made modifications to it before splitting it into > several smaller packages. The versions of Pier-Tests form part of the > history of my development but are no longer part of the "current state" of > the project (ie. at some point I unloaded Pier-Tests from my image). I don't > think it should be removed from the repository because it does form part of > the development history, but you definitely shouldn't be loading it (other > than possibly to merge changes from the other branch forward, of course). > > Julian > > > On Wed, Jan 6, 2010 at 10:28 AM, Nick Ager wrote: > >> Hi Julian, >> >> I'm very confused. I reloaded Pier-Tests-Model manually and it turns out >> that the correct code was already in place ie s/WAPlatform/GRPlatform & >> s/seasideString/greaseString/ All I can guess is that Pier-Tests loaded >> after Pier-Tests-Model even though it's later in my Gofer script. Pier-Tests >> is in the http://source.lukas-renggli.ch/pier2 repository. My >> interpretation of what you say is that either it shouldn't exist or the code >> in it should be consistent with Pier-Tests-* Can you clarify >> >> Thanks >> >> Nick >> >> 2010/1/6 Julian Fitzell >> >> You're sort of right on both counts. Monticello will consider the contents >>> of -Tests-Security and -Tests-Model to also be part of -Tests. -Tests is no >>> longer part of the code in the new repositories, though, because it was >>> split into the various smaller packages. You shouldn't need to commit new >>> versions of Pier-Tests to the /pier2 repository. Hopefully you can merge in >>> the newest -Tests from /pier, move any new classes around as necessary and >>> then commit the changes to -Tests-Security and -Tests-Model, etc. You'll >>> need to pay very close attention to the diffs of packages as you are >>> committing though to make sure you haven't lost code or added code that you >>> don't intend (glad to see you're looking at the diffs already! :) ). >>> >>> Julian >>> >>> >>> On Wed, Jan 6, 2010 at 10:05 AM, Nick Ager wrote: >>> >>>> I thought I'd try merging these trivial changes (minus cleanupSeaside), >>>> but when I checked the changes I was about to check in I noticed that a lot >>>> of the methods had changed. My installation script loads the packages in the >>>> following order: Pier-Tests, Pier-Tests-Model, Pier-Tests-Security. Here I >>>> show my ignorance again. I'm assuming that Pier-Tests should be a "super >>>> package" for Pier-Tests-Model and Pier-Test-Security, however it seems that >>>> there's a significant difference between the packages. I'm assuming that >>>> Pier-Tests-Model and Pier-Tests_Security supersedes Pier-Tests as the date >>>> stamps are later (September vs November). In which case I should check my >>>> changes into Pier-Tests-Model and then check in Pier-Tests so that the >>>> packages are again consistent. Does that make sense? >>>> >>>> Nick >>>> >>>> >>>> 2010/1/6 Nick Ager >>>> >>>>> While I'm stuck with the merge errors I had a look at the load errors: >>>>> >>>>> PRCommandTest>>testTime (WAPlatform is Undeclared) >>>>> >>>>> PRCommandTest>>testTimestamp (WAPlatform is Undeclared) >>>>> >>>>> PRCommandTest>>testDate (WAPlatform is Undeclared) >>>>> >>>>> PRPersistencyTest>>testMutexForked (WAPlatform is Undeclared) >>>>> >>>>> PRSegmentPersistency>>cleanupSeaside (WAEntryPoint is Undeclared) >>>>> >>>>> They were easy to fix simply by changing WAPlatform to GRPlatform. >>>>> >>>>> However I'm uncertain how to changethe code in >>>>> PRSegmentPersistency>>cleanupSeaside: >>>>> >>>>> cleanupSeaside >>>>> "Clear all the entry points that reference other entry points, state >>>>> and continuations by overriding them with a blank version. Do not try to >>>>> call #clearAllHandlers because this spawns a new process. Also dump the >>>>> default dispatcher just to be sure." >>>>> >>>>> >>>>> WAEntryPoint allSubInstances >>>>> do: [ :entry | entry copyFrom: entry class basicNew ]. >>>>> WADispatcher instVarNamed: 'default' put: nil >>>>> >>>>> My best guess is to replace the code with the call: >>>>> WARegistry clearAll >>>>> >>>>> marks out out 10? >>>>> >>>>> 2010/1/6 Nick Ager >>>>> >>>>> I've created a fresh seaside3.0a5 image, loaded Magritte and Pier into >>>>>> it and I've failed at the first merge hurdle. I'm starting with >>>>>> Magritte-Model and when I try merging from ' >>>>>> http://source.lukas-renggli.ch/magritte' I get the error: >>>>>> >>>>>> 'Could not find version ''Magritte-Model-lr.358''. Maybe you need to >>>>>> add a repository?' >>>>>> >>>>>> any thoughts on my beginners error? >>>>>> >>>>>> Thanks Nick >>>>>> >>>>>> 2010/1/6 Lukas Renggli >>>>>> >>>>>> > I'm happy to have a go bringing the Pier 3.0 repository upto the >>>>>>> latest 2.8 >>>>>>> > codebase, but I'll need support. For example I'm not sure how to >>>>>>> diff code >>>>>>> > from two different repositories in Pharo..., plus my knowledge of >>>>>>> Pier is >>>>>>> > still rudimentary - but I guess I've got to start somewhere... >>>>>>> Would it be a >>>>>>> > horrendous undertaking?? >>>>>>> >>>>>>> The process is simple: You load the latest Magritte/Pier 3.0 code >>>>>>> into >>>>>>> your image, then you add the old Magritte and Pier repositories using >>>>>>> the "+Repository" button, open the repository browser on that >>>>>>> repository, select the latest version of each package (e.g. >>>>>>> Magritte-Core) and click on "Merge". >>>>>>> >>>>>>> Normally merging should be really easy, but I don't know how much >>>>>>> Magritte and Pier changed from the previous version. Also the merging >>>>>>> does not work if the packages got renamed. >>>>>>> >>>>>>> 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 >>>> >>> >>> >>> _______________________________________________ >>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Thu Jan 7 20:37:48 2010 From: nick.ager at gmail.com (Nick Ager) Date: Thu, 7 Jan 2010 19:37:48 +0000 Subject: seaside 3.0 merging details. Message-ID: <3a06f76f1001071137j53e3762fv78a34de9527c8e26@mail.gmail.com> As I'm still not terribly comfortable with the merging tools in Pharo, I've tried to be as cautious as possible: 1) check there are no changes against in my image from magritte2 or pier2 repositories. 2) merge with magritte or pier repository - if uncertain check changes over last few months in 2.8 repositories 3) check the merged code for expected differences in the magritte2 or pier2 repositories Magritte-Model & Magritte-Pharo-Model Merge was straightforward. examining the differences after merge between the two repositories I noticed: MACompatibility doesn't exist with most of the methods being moved to GRPlatform. However request:default: has been added in MACompatibility for which there doesn't appear to be a equivalent in GRPlatform Also I couldn't find an equivalent of openWorkspace:titled: in GRPlatform. So I added magritteRequest:default: and magritteOpenWorkspace:title to GRPlatform with Pharo implementations in GRPharoPlatform. Magritte-Tests Lots of merge conflicts, but then I realised that I'd only loaded Magritte-Tests-Model and Magritte-Tests-Pharo-Model *not* Magritte-Tests - Suddenly what was being said previously in the list about maintaining version history made sense. I reloaded the tests and tried to merge again. No merge conflicts, only three updated methods. -all tests pass- Magritte-Morph No changes - though I fixed the load error in MAFileMorph>>choose I changed FileList2 -> FileList Magritte-Seaside & Magritte-Pharo-Seaside Straightforward merge, didn't spot anything which needed to be changed for cross-platform Pier ------ What's the purpose of the Magritte-Model, Magritte-Seaside and Magritte-Tests packages in the pier2 repository? I used the packages in the magritte2 repository. Hope that was the plan. Pier-Core - empty package Pier-Model lots of changes but only a couple of merge conflicts and a couple of s/asString/greaseString/ and one s/allSubInstancesOf:do:/magritteAllSubInstancesOf:do:/ Pier-Seaside lots of changes, but again only a couple of merge conflicts and one s/displayString/greaseString/ Pier-Security only a couple of methods had changed, one merge conflict Pier-Tests lots of changes, only one merge conflict -all tests pass- I'm about the save the merged code, but when I try I get an Error: HTTP1.1 401 Unauthorized Does someone need to give me write permissions to http://source.lukas-renggli.ch/magritte2 and http://source.lukas-renggli.ch/pier2 Cheers Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Thu Jan 7 21:13:12 2010 From: renggli at gmail.com (Lukas Renggli) Date: Thu, 7 Jan 2010 21:13:12 +0100 Subject: seaside 3.0 merging details. In-Reply-To: <3a06f76f1001071137j53e3762fv78a34de9527c8e26@mail.gmail.com> References: <3a06f76f1001071137j53e3762fv78a34de9527c8e26@mail.gmail.com> Message-ID: <67628d691001071213o4b71f325nf8be40dfb55f90ac@mail.gmail.com> > [...] I guess Julian has to comment on that, but to me it sounds good :-) > What's the purpose of the Magritte-Model, Magritte-Seaside and Magritte-Tests > packages in the pier2 repository? I used the packages in the magritte2 repository. > Hope that was the plan. @Julian: Should these versions be moved or deleted? > I'm about the save the merged code, but when I try I get an Error: HTTP1.1 > 401 Unauthorized Accidentally the Magritte repository didn't had public write permissions. I changed that. Lukas -- Lukas Renggli http://www.lukas-renggli.ch From nick.ager at gmail.com Thu Jan 7 21:34:39 2010 From: nick.ager at gmail.com (Nick Ager) Date: Thu, 7 Jan 2010 20:34:39 +0000 Subject: seaside 3.0 merging details. In-Reply-To: <67628d691001071213o4b71f325nf8be40dfb55f90ac@mail.gmail.com> References: <3a06f76f1001071137j53e3762fv78a34de9527c8e26@mail.gmail.com> <67628d691001071213o4b71f325nf8be40dfb55f90ac@mail.gmail.com> Message-ID: <3a06f76f1001071234s2c8c91dax51b9d3f6f4bcbbdf@mail.gmail.com> I've saved the merged packages into pier2 and magritte2. When I merged magritte I updated Magritte-Tests (the super package?) as well as Magritte-Tests-Model. For pier I only updated Pier-Tests-Model *not* Pier-Tests, but it makes sense to me to update Pier-Tests as well. Should I. I'll now try to loading all into a clean seaside 3.0a5 image. 2010/1/7 Lukas Renggli > > [...] > > I guess Julian has to comment on that, but to me it sounds good :-) > > > What's the purpose of the Magritte-Model, Magritte-Seaside and > Magritte-Tests > > packages in the pier2 repository? I used the packages in the magritte2 > repository. > > Hope that was the plan. > > @Julian: Should these versions be moved or deleted? > > > I'm about the save the merged code, but when I try I get an Error: > HTTP1.1 > > 401 Unauthorized > > Accidentally the Magritte repository didn't had public write > permissions. I changed that. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfitzell at gmail.com Thu Jan 7 22:36:42 2010 From: jfitzell at gmail.com (Julian Fitzell) Date: Thu, 7 Jan 2010 13:36:42 -0800 Subject: seaside 3.0 merging details. In-Reply-To: <67628d691001071213o4b71f325nf8be40dfb55f90ac@mail.gmail.com> References: <3a06f76f1001071137j53e3762fv78a34de9527c8e26@mail.gmail.com> <67628d691001071213o4b71f325nf8be40dfb55f90ac@mail.gmail.com> Message-ID: <4a5dbd431001071336u71ac5d3vcd01374fca3ac377@mail.gmail.com> On Thu, Jan 7, 2010 at 12:13 PM, Lukas Renggli wrote: > > [...] > > I guess Julian has to comment on that, but to me it sounds good :-) > I don't have time to look carefully at it right now, but the description sounded reasonable. > > What's the purpose of the Magritte-Model, Magritte-Seaside and > Magritte-Tests > > packages in the pier2 repository? I used the packages in the magritte2 > repository. > > Hope that was the plan. > > @Julian: Should these versions be moved or deleted? > Moved, I think (unless I already copied them, which is possible). Those would be from before you created the /magritte2 repo. > > I'm about the save the merged code, but when I try I get an Error: > HTTP1.1 > > 401 Unauthorized > > Accidentally the Magritte repository didn't had public write > permissions. I changed that. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfitzell at gmail.com Thu Jan 7 22:39:52 2010 From: jfitzell at gmail.com (Julian Fitzell) Date: Thu, 7 Jan 2010 13:39:52 -0800 Subject: seaside 3.0 merging details. In-Reply-To: <3a06f76f1001071234s2c8c91dax51b9d3f6f4bcbbdf@mail.gmail.com> References: <3a06f76f1001071137j53e3762fv78a34de9527c8e26@mail.gmail.com> <67628d691001071213o4b71f325nf8be40dfb55f90ac@mail.gmail.com> <3a06f76f1001071234s2c8c91dax51b9d3f6f4bcbbdf@mail.gmail.com> Message-ID: <4a5dbd431001071339p630b291cna7b5ecf4c56c562e@mail.gmail.com> I just check my image and the same should be true of Magritte-Tests as of Pier-Tests (ie. I split the package into several sub-packages and thus the original all-encompassing package is now obsolete). Julian On Thu, Jan 7, 2010 at 12:34 PM, Nick Ager wrote: > I've saved the merged packages into pier2 and magritte2. When I merged > magritte I updated Magritte-Tests (the super package?) as well as > Magritte-Tests-Model. For pier I only updated Pier-Tests-Model *not* > Pier-Tests, but it makes sense to me to update Pier-Tests as well. Should I. > > I'll now try to loading all into a clean seaside 3.0a5 image. > > 2010/1/7 Lukas Renggli > > > [...] >> >> I guess Julian has to comment on that, but to me it sounds good :-) >> >> > What's the purpose of the Magritte-Model, Magritte-Seaside and >> Magritte-Tests >> > packages in the pier2 repository? I used the packages in the magritte2 >> repository. >> > Hope that was the plan. >> >> @Julian: Should these versions be moved or deleted? >> >> > I'm about the save the merged code, but when I try I get an Error: >> HTTP1.1 >> > 401 Unauthorized >> >> Accidentally the Magritte repository didn't had public write >> permissions. I changed that. >> >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Thu Jan 7 22:45:48 2010 From: nick.ager at gmail.com (Nick Ager) Date: Thu, 7 Jan 2010 21:45:48 +0000 Subject: seaside 3.0 merging details. In-Reply-To: <4a5dbd431001071339p630b291cna7b5ecf4c56c562e@mail.gmail.com> References: <3a06f76f1001071137j53e3762fv78a34de9527c8e26@mail.gmail.com> <67628d691001071213o4b71f325nf8be40dfb55f90ac@mail.gmail.com> <3a06f76f1001071234s2c8c91dax51b9d3f6f4bcbbdf@mail.gmail.com> <4a5dbd431001071339p630b291cna7b5ecf4c56c562e@mail.gmail.com> Message-ID: <3a06f76f1001071345i64161872h6ed0d1b9a7a1a9a4@mail.gmail.com> Does that mean I should revert the changes I made to Magritte-Tests or save the latest version of Pier-Tests? I now realise their value for merging, though the problem at the moment is that if you inadvertently load Pier-Tests you'll end up with load errors, which at least for me was initially off-putting. 2010/1/7 Julian Fitzell > I just check my image and the same should be true of Magritte-Tests as of > Pier-Tests (ie. I split the package into several sub-packages and thus the > original all-encompassing package is now obsolete). > > Julian > > > On Thu, Jan 7, 2010 at 12:34 PM, Nick Ager wrote: > >> I've saved the merged packages into pier2 and magritte2. When I merged >> magritte I updated Magritte-Tests (the super package?) as well as >> Magritte-Tests-Model. For pier I only updated Pier-Tests-Model *not* >> Pier-Tests, but it makes sense to me to update Pier-Tests as well. Should I. >> >> I'll now try to loading all into a clean seaside 3.0a5 image. >> >> 2010/1/7 Lukas Renggli >> >> > [...] >>> >>> I guess Julian has to comment on that, but to me it sounds good :-) >>> >>> > What's the purpose of the Magritte-Model, Magritte-Seaside and >>> Magritte-Tests >>> > packages in the pier2 repository? I used the packages in the magritte2 >>> repository. >>> > Hope that was the plan. >>> >>> @Julian: Should these versions be moved or deleted? >>> >>> > I'm about the save the merged code, but when I try I get an Error: >>> HTTP1.1 >>> > 401 Unauthorized >>> >>> Accidentally the Magritte repository didn't had public write >>> permissions. I changed that. >>> >>> 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 >> > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Thu Jan 7 22:49:17 2010 From: nick.ager at gmail.com (Nick Ager) Date: Thu, 7 Jan 2010 21:49:17 +0000 Subject: seaside 3.0 merging details. In-Reply-To: <3a06f76f1001071234s2c8c91dax51b9d3f6f4bcbbdf@mail.gmail.com> References: <3a06f76f1001071137j53e3762fv78a34de9527c8e26@mail.gmail.com> <67628d691001071213o4b71f325nf8be40dfb55f90ac@mail.gmail.com> <3a06f76f1001071234s2c8c91dax51b9d3f6f4bcbbdf@mail.gmail.com> Message-ID: <3a06f76f1001071349s64dc7a60mbac2c0f9682e0948@mail.gmail.com> Magritte and Pier loaded successfully with one load error: PRSegmentPersistency>>cleanupSeaside (WAEntryPoint is Undeclared) the code is: PRSegmentPersistency>>cleanupSeaside "Clear all the entry points that reference other entry points, state and continuations by overriding them with a blank version. Do not try to call #clearAllHandlers because this spawns a new process. Also dump the default dispatcher just to be sure." WAEntryPoint allSubInstances do: [ :entry | entry copyFrom: entry class basicNew ]. WADispatcher instVarNamed: 'default' put: nil which I think should be changed to: PRSegmentPersistency>>cleanupSeaside WAAdmin clearAll but I'm not sure WAAdmin clearAll is doing exactly what the original code intended -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Fri Jan 8 03:42:18 2010 From: nick.ager at gmail.com (Nick Ager) Date: Fri, 8 Jan 2010 02:42:18 +0000 Subject: seaside 3.0 merging details. In-Reply-To: <3a06f76f1001071234s2c8c91dax51b9d3f6f4bcbbdf@mail.gmail.com> References: <3a06f76f1001071137j53e3762fv78a34de9527c8e26@mail.gmail.com> <67628d691001071213o4b71f325nf8be40dfb55f90ac@mail.gmail.com> <3a06f76f1001071234s2c8c91dax51b9d3f6f4bcbbdf@mail.gmail.com> Message-ID: <3a06f76f1001071842p6c944115naa4def840a74b32c@mail.gmail.com> Now the hard part ensuring the code works.. I merged in some code in PRPierFrame (package Pier-Seaside) which assumed that urls were strings not WAUrls. I've found another suspicious use in PREmbeddedRenderer>>visitExternalLink, but there might be more. I've re-added a couple of methods, so that I could successfully render the first page which had been removed from the pier2 repository; PRPierFrame>>dispatcher & PRPierFrame>>invalidDispatcher. The opening page now appears, however clicking on a link results in a MNU 'receiver of context is nil' from the call 'PRCurrentContext value: self' in PRContext>>activationCallback ^ WAActionCallback on: [ PRCurrentContext value: self. (self command isView and: [ self command viewComponent isFullResponse ]) ifTrue: [ self command viewComponent handle: self requestContext ] ] I can see that the code results in an exception being called which returns nil from the signal method, at which stage I'm lost... 2010/1/7 Nick Ager > I've saved the merged packages into pier2 and magritte2. When I merged > magritte I updated Magritte-Tests (the super package?) as well as > Magritte-Tests-Model. For pier I only updated Pier-Tests-Model *not* > Pier-Tests, but it makes sense to me to update Pier-Tests as well. Should I. > > I'll now try to loading all into a clean seaside 3.0a5 image. > > 2010/1/7 Lukas Renggli > > > [...] >> >> I guess Julian has to comment on that, but to me it sounds good :-) >> >> > What's the purpose of the Magritte-Model, Magritte-Seaside and >> Magritte-Tests >> > packages in the pier2 repository? I used the packages in the magritte2 >> repository. >> > Hope that was the plan. >> >> @Julian: Should these versions be moved or deleted? >> >> > I'm about the save the merged code, but when I try I get an Error: >> HTTP1.1 >> > 401 Unauthorized >> >> Accidentally the Magritte repository didn't had public write >> permissions. I changed that. >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfitzell at gmail.com Fri Jan 8 18:42:52 2010 From: jfitzell at gmail.com (Julian Fitzell) Date: Fri, 8 Jan 2010 09:42:52 -0800 Subject: seaside 3.0 merging details. In-Reply-To: <3a06f76f1001071349s64dc7a60mbac2c0f9682e0948@mail.gmail.com> References: <3a06f76f1001071137j53e3762fv78a34de9527c8e26@mail.gmail.com> <67628d691001071213o4b71f325nf8be40dfb55f90ac@mail.gmail.com> <3a06f76f1001071234s2c8c91dax51b9d3f6f4bcbbdf@mail.gmail.com> <3a06f76f1001071349s64dc7a60mbac2c0f9682e0948@mail.gmail.com> Message-ID: <4a5dbd431001080942i446ebe32oe56e8f650c0b71b3@mail.gmail.com> That code's a bit weird and I don't entirely understand the goal... Lukas would have to comment. Julian On Thu, Jan 7, 2010 at 1:49 PM, Nick Ager wrote: > Magritte and Pier loaded successfully with one load error: > PRSegmentPersistency>>cleanupSeaside (WAEntryPoint is Undeclared) > > the code is: > > PRSegmentPersistency>>cleanupSeaside > "Clear all the entry points that reference other entry points, state and > continuations by overriding them with a blank version. Do not try to call > #clearAllHandlers because this spawns a new process. Also dump the default > dispatcher just to be sure." > > > WAEntryPoint allSubInstances > do: [ :entry | entry copyFrom: entry class basicNew ]. > WADispatcher instVarNamed: 'default' put: nil > > which I think should be changed to: > PRSegmentPersistency>>cleanupSeaside > > WAAdmin clearAll > > but I'm not sure WAAdmin clearAll is doing exactly what the original code > intended > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Fri Jan 8 21:02:44 2010 From: nick.ager at gmail.com (Nick Ager) Date: Fri, 8 Jan 2010 20:02:44 +0000 Subject: 3.0 merge status Message-ID: <3a06f76f1001081202h59d99fe8na9b249c3f75ee555@mail.gmail.com> 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')) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfitzell at gmail.com Sat Jan 9 07:44:26 2010 From: jfitzell at gmail.com (Julian Fitzell) Date: Fri, 8 Jan 2010 22:44:26 -0800 Subject: 3.0 merge status In-Reply-To: <3a06f76f1001081202h59d99fe8na9b249c3f75ee555@mail.gmail.com> References: <3a06f76f1001081202h59d99fe8na9b249c3f75ee555@mail.gmail.com> Message-ID: <4a5dbd431001082244n3a4a9758y6db023cda301e780@mail.gmail.com> On Fri, Jan 8, 2010 at 12:02 PM, Nick Ager 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 From renggli at gmail.com Sat Jan 9 16:32:48 2010 From: renggli at gmail.com (Lukas Renggli) Date: Sat, 9 Jan 2010 16:32:48 +0100 Subject: 3.0 merge status In-Reply-To: <3a06f76f1001081202h59d99fe8na9b249c3f75ee555@mail.gmail.com> References: <3a06f76f1001081202h59d99fe8na9b249c3f75ee555@mail.gmail.com> Message-ID: <67628d691001090732l327443d6nb503b0e6ddc5322b@mail.gmail.com> Thank you for these scripts. I use them to load the new code into Seaside 3.0 images, see . 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 : > 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 From grshiplett2 at yahoo.com Sun Jan 10 02:13:46 2010 From: grshiplett2 at yahoo.com (Robert Shiplett) Date: Sat, 9 Jan 2010 17:13:46 -0800 (PST) Subject: 3.0 merge status (observations and a code variant) In-Reply-To: <67628d691001090732l327443d6nb503b0e6ddc5322b@mail.gmail.com> Message-ID: <783112.16655.qm@web51606.mail.re2.yahoo.com> 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 wrote: > From: Lukas Renggli > Subject: Re: 3.0 merge status > To: "Magritte, Pier and Related Tools ..." > 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 > . > > 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 : > > 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 > From renggli at gmail.com Sun Jan 10 02:26:23 2010 From: renggli at gmail.com (Lukas Renggli) Date: Sun, 10 Jan 2010 02:26:23 +0100 Subject: 3.0 merge status (observations and a code variant) In-Reply-To: <783112.16655.qm@web51606.mail.re2.yahoo.com> References: <67628d691001090732l327443d6nb503b0e6ddc5322b@mail.gmail.com> <783112.16655.qm@web51606.mail.re2.yahoo.com> Message-ID: <67628d691001091726k58d65689ja7a9819d59c8bff0@mail.gmail.com> > 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 From grshiplett2 at yahoo.com Sun Jan 10 19:09:48 2010 From: grshiplett2 at yahoo.com (Robert Shiplett) Date: Sun, 10 Jan 2010 10:09:48 -0800 (PST) Subject: 3.0 merge status (observations and a code variant) In-Reply-To: <67628d691001091726k58d65689ja7a9819d59c8bff0@mail.gmail.com> Message-ID: <168852.9662.qm@web51605.mail.re2.yahoo.com> 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 wrote: > From: Lukas Renggli > Subject: Re: 3.0 merge status (observations and a code variant) > To: "Magritte, Pier and Related Tools ..." > 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 > From grshiplett2 at yahoo.com Sun Jan 10 19:24:55 2010 From: grshiplett2 at yahoo.com (Robert Shiplett) Date: Sun, 10 Jan 2010 10:24:55 -0800 (PST) Subject: 3.0 merge status (observations and a code variant) In-Reply-To: <67628d691001091726k58d65689ja7a9819d59c8bff0@mail.gmail.com> Message-ID: <608580.61107.qm@web51602.mail.re2.yahoo.com> 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 wrote: > From: Lukas Renggli > Subject: Re: 3.0 merge status (observations and a code variant) > To: "Magritte, Pier and Related Tools ..." > 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 > From grshiplett2 at yahoo.com Sun Jan 10 19:50:38 2010 From: grshiplett2 at yahoo.com (Robert Shiplett) Date: Sun, 10 Jan 2010 10:50:38 -0800 (PST) Subject: 3.0 merge status (observations and a code variant) In-Reply-To: <67628d691001091726k58d65689ja7a9819d59c8bff0@mail.gmail.com> Message-ID: <538724.73386.qm@web51602.mail.re2.yahoo.com> 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 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 the token that contains the literal value as well as its source positions ! --- On Sat, 1/9/10, Lukas Renggli wrote: > From: Lukas Renggli > Subject: Re: 3.0 merge status (observations and a code variant) > To: "Magritte, Pier and Related Tools ..." > 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 > From renggli at gmail.com Sun Jan 10 20:13:03 2010 From: renggli at gmail.com (Lukas Renggli) Date: Sun, 10 Jan 2010 20:13:03 +0100 Subject: 3.0 merge status (observations and a code variant) In-Reply-To: <608580.61107.qm@web51602.mail.re2.yahoo.com> References: <67628d691001091726k58d65689ja7a9819d59c8bff0@mail.gmail.com> <608580.61107.qm@web51602.mail.re2.yahoo.com> Message-ID: <67628d691001101113s688939f9qbcd7f7a0efebd069@mail.gmail.com> > 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 From renggli at gmail.com Sun Jan 10 20:25:46 2010 From: renggli at gmail.com (Lukas Renggli) Date: Sun, 10 Jan 2010 20:25:46 +0100 Subject: 3.0 merge status (observations and a code variant) In-Reply-To: <538724.73386.qm@web51602.mail.re2.yahoo.com> References: <67628d691001091726k58d65689ja7a9819d59c8bff0@mail.gmail.com> <538724.73386.qm@web51602.mail.re2.yahoo.com> Message-ID: <67628d691001101125w5922eec1lda89f6b18787a024@mail.gmail.com> > 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 ? ? ? ? ?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 ? ? ? ? ?the token that contains the literal value as well as its source positions > > ! > > --- On Sat, 1/9/10, Lukas Renggli wrote: > >> From: Lukas Renggli >> Subject: Re: 3.0 merge status (observations and a code variant) >> To: "Magritte, Pier and Related Tools ..." >> 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 From nick.ager at gmail.com Sun Jan 10 21:25:49 2010 From: nick.ager at gmail.com (Nick Ager) Date: Sun, 10 Jan 2010 20:25:49 +0000 Subject: seaside 3.0 pier image loading problem Message-ID: <3a06f76f1001101225t6ba87d4dtc6f6539119e2f574@mail.gmail.com> When I merged the latest Pier code with the Pier for Seaside 3.0 branch I noticed that the Pier logo wasn't appearing on the initial screen, although it appeared on the 3.0 branch prior to the merge. I traced the difference in behaviour down to a code change in PRViewCommand>>initialRequest the pre-merge version: initialRequest: aRequest | viewClass | super initialRequest: aRequest. viewClass := PRPierFrame classFromRequest: aRequest name: 'view' base: PRViewComponent. (viewClass isNil and: [ self structure isFile ]) ifTrue: [ viewClass := PRDownloadView ]. (viewClass notNil and: [ viewClass isValidIn: self context ]) ifTrue: [ self viewComponentClass: viewClass ]. self viewComponent visiblePresentersDo: [ :each | each initialRequest: aRequest ]. (self viewComponent isFullResponse) ifTrue: [ self viewComponent handle: WACurrentRequestContext value ] post-merge version: initialRequest: aRequest | viewClass | super initialRequest: aRequest. viewClass := PRPierFrame classFromRequest: aRequest name: 'view' base: PRViewComponent. (viewClass notNil and: [ viewClass isValidIn: self context ]) ifTrue: [ self viewComponentClass: viewClass ]. self viewComponent visiblePresentersDo: [ :each | each initialRequest: aRequest ]. (self viewComponent isFullResponse) ifTrue: [ self viewComponent handle: WACurrentRequestContext value ] the pre-merge version has the addition of the code: (viewClass isNil and: [ self structure isFile ]) ifTrue: [ viewClass := PRDownloadView ]. However this code isn't present in the main 2.8 code-base. The problem is more subtle. The pier environment stylesheet requests an image from: '/seaside/pier/environment/pier.png?view=PRDownloadView' this is trapped by the code in WAOldPathComptibilityRequestHandler which issues a 301 moved permanently redirect to '/pier/environment/pier.png'. The problem is that during the redirection the url parameters have been lost. I've fixed the problem locally by changing WAOldPathComptibilityRequestHandler>>handleFiltered: from: handleFiltered: aRequestContext | url | url := aRequestContext request url copy. url path removeFirst. aRequestContext response movedPermanently; location: url. aRequestContext respond to: handleFiltered: aRequestContext | url | url := aRequestContext request url copy. url path removeFirst. url parameters: aRequestContext request fields. aRequestContext response movedPermanently; location: url. aRequestContext respond I copy the parameters from the request to the url. Should I save this change into seaside 3.0 repositories? Or is there something else that needs fixing higher up the call stack to account for why the parameters haven't been added to the WAUrl object? Hope this all makes sense Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From grshiplett2 at yahoo.com Sun Jan 10 23:04:41 2010 From: grshiplett2 at yahoo.com (Robert Shiplett) Date: Sun, 10 Jan 2010 14:04:41 -0800 (PST) Subject: 3.0 merge status (observations and a code variant) In-Reply-To: <67628d691001101125w5922eec1lda89f6b18787a024@mail.gmail.com> Message-ID: <389267.50381.qm@web51603.mail.re2.yahoo.com> 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 wrote: > From: Lukas Renggli > Subject: Re: 3.0 merge status (observations and a code variant) > To: "Magritte, Pier and Related Tools ..." > 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 ? ? ? ? > ?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 ? ? ? ? > ?the token that contains the literal value as well as its > source positions > > > > ! > > > > --- On Sat, 1/9/10, Lukas Renggli > wrote: > > > >> From: Lukas Renggli > >> Subject: Re: 3.0 merge status (observations and a > code variant) > >> To: "Magritte, Pier and Related Tools ..." > >> 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 > From grshiplett2 at yahoo.com Sun Jan 10 23:17:11 2010 From: grshiplett2 at yahoo.com (Robert Shiplett) Date: Sun, 10 Jan 2010 14:17:11 -0800 (PST) Subject: 3.0 merge status (observations and a code variant) In-Reply-To: <67628d691001101125w5922eec1lda89f6b18787a024@mail.gmail.com> Message-ID: <875862.86892.qm@web51601.mail.re2.yahoo.com> 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 wrote: > From: Lukas Renggli > Subject: Re: 3.0 merge status (observations and a code variant) > To: "Magritte, Pier and Related Tools ..." > 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 ? ? ? ? > ?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 ? ? ? ? > ?the token that contains the literal value as well as its > source positions > > > > ! > > > > --- On Sat, 1/9/10, Lukas Renggli > wrote: > > > >> From: Lukas Renggli > >> Subject: Re: 3.0 merge status (observations and a > code variant) > >> To: "Magritte, Pier and Related Tools ..." > >> 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 > From jfitzell at gmail.com Sun Jan 10 23:37:23 2010 From: jfitzell at gmail.com (Julian Fitzell) Date: Sun, 10 Jan 2010 14:37:23 -0800 Subject: seaside 3.0 pier image loading problem In-Reply-To: <3a06f76f1001101225t6ba87d4dtc6f6539119e2f574@mail.gmail.com> References: <3a06f76f1001101225t6ba87d4dtc6f6539119e2f574@mail.gmail.com> Message-ID: <4a5dbd431001101437x7fcf2724w53db287aeadccecb@mail.gmail.com> Sigh... Can you just fix the stylesheet to drop the /seaside for now? I'm generally unhappy with how WARequest/WAUrl are working in this regard at the moment... I'll bring it up with the Seaside team and see what we can do about it. Julian On Sun, Jan 10, 2010 at 12:25 PM, Nick Ager wrote: > When I merged the latest Pier code with the Pier for Seaside 3.0 branch I > noticed that the Pier logo wasn't appearing on the initial screen, although > it appeared on the 3.0 branch prior to the merge. > I traced the difference in behaviour down to a code change in > PRViewCommand>>initialRequest > the pre-merge version: > initialRequest: aRequest > | viewClass | > super initialRequest: aRequest. > viewClass := PRPierFrame > classFromRequest: aRequest > name: 'view' > base: PRViewComponent. > (viewClass isNil and: [ self structure isFile ]) > ifTrue: [ viewClass := PRDownloadView ]. > (viewClass notNil and: [ viewClass isValidIn: self context ]) > ifTrue: [ self viewComponentClass: viewClass ]. > self viewComponent visiblePresentersDo: [ :each | each initialRequest: > aRequest ]. > (self viewComponent isFullResponse) > ifTrue: [ self viewComponent handle: WACurrentRequestContext value ] > post-merge version: > initialRequest: aRequest > | viewClass | > super initialRequest: aRequest. > viewClass := PRPierFrame > classFromRequest: aRequest > name: 'view' > base: PRViewComponent. > (viewClass notNil and: [ viewClass isValidIn: self context ]) > ifTrue: [ self viewComponentClass: viewClass ]. > self viewComponent visiblePresentersDo: [ :each | each initialRequest: > aRequest ]. > (self viewComponent isFullResponse) > ifTrue: [ self viewComponent handle: WACurrentRequestContext value ] > the pre-merge version has the addition of the code:?(viewClass isNil and: [ > self structure isFile ])?ifTrue: [ viewClass := PRDownloadView ]. > However this code isn't present in the main 2.8 code-base. The problem is > more subtle. The pier environment stylesheet requests an image from: > '/seaside/pier/environment/pier.png?view=PRDownloadView' this is trapped by > the code in?WAOldPathComptibilityRequestHandler which issues a 301 moved > permanently redirect to?'/pier/environment/pier.png'. The problem is that > during the redirection the url parameters have been lost. I've fixed the > problem locally by changing > WAOldPathComptibilityRequestHandler>>handleFiltered: from: > handleFiltered: aRequestContext > | url | > url := aRequestContext request url copy. > url path removeFirst. > aRequestContext response > movedPermanently; > location: url. > aRequestContext respond > to: > handleFiltered: aRequestContext > | url | > url := aRequestContext request url copy. > url path removeFirst. > url parameters: aRequestContext request fields. > aRequestContext response > movedPermanently; > location: url. > aRequestContext respond > I copy the parameters from the request to the url. Should I save this change > into seaside 3.0 repositories? Or is there something else that needs fixing > higher up the call stack to account for why the parameters haven't been > added to the WAUrl object? > Hope this all makes sense > Nick > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > From grshiplett2 at yahoo.com Sun Jan 10 23:39:20 2010 From: grshiplett2 at yahoo.com (Robert Shiplett) Date: Sun, 10 Jan 2010 14:39:20 -0800 (PST) Subject: 3.0 merge status (observations and a code variant) In-Reply-To: <67628d691001101125w5922eec1lda89f6b18787a024@mail.gmail.com> Message-ID: <191831.32170.qm@web51608.mail.re2.yahoo.com> "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 wrote: > From: Lukas Renggli > Subject: Re: 3.0 merge status (observations and a code variant) > To: "Magritte, Pier and Related Tools ..." > 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 ? ? ? ? > ?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 ? ? ? ? > ?the token that contains the literal value as well as its > source positions > > > > ! > > > > --- On Sat, 1/9/10, Lukas Renggli > wrote: > > > >> From: Lukas Renggli > >> Subject: Re: 3.0 merge status (observations and a > code variant) > >> To: "Magritte, Pier and Related Tools ..." > >> 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 > From renggli at gmail.com Sun Jan 10 23:48:01 2010 From: renggli at gmail.com (Lukas Renggli) Date: Sun, 10 Jan 2010 23:48:01 +0100 Subject: 3.0 merge status (observations and a code variant) In-Reply-To: <191831.32170.qm@web51608.mail.re2.yahoo.com> References: <67628d691001101125w5922eec1lda89f6b18787a024@mail.gmail.com> <191831.32170.qm@web51608.mail.re2.yahoo.com> Message-ID: <67628d691001101448ua3456eai23bb003f86b872b1@mail.gmail.com> 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 : > "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 wrote: > >> From: Lukas Renggli >> Subject: Re: 3.0 merge status (observations and a code variant) >> To: "Magritte, Pier and Related Tools ..." >> 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 ? >> ?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 ? >> ?the token that contains the literal value as well as its >> source positions >> > >> > ! >> > >> > --- On Sat, 1/9/10, Lukas Renggli >> wrote: >> > >> >> From: Lukas Renggli >> >> Subject: Re: 3.0 merge status (observations and a >> code variant) >> >> To: "Magritte, Pier and Related Tools ..." >> >> 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 From jfitzell at gmail.com Mon Jan 11 00:03:29 2010 From: jfitzell at gmail.com (Julian Fitzell) Date: Sun, 10 Jan 2010 15:03:29 -0800 Subject: 3.0 merge status (observations and a code variant) In-Reply-To: <191831.32170.qm@web51608.mail.re2.yahoo.com> References: <67628d691001101125w5922eec1lda89f6b18787a024@mail.gmail.com> <191831.32170.qm@web51608.mail.re2.yahoo.com> Message-ID: <4a5dbd431001101503j21d88adci328ca8d9847ee177@mail.gmail.com> 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 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 wrote: > >> From: Lukas Renggli >> Subject: Re: 3.0 merge status (observations and a code variant) >> To: "Magritte, Pier and Related Tools ..." >> 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 ? >> ?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 ? >> ?the token that contains the literal value as well as its >> source positions >> > >> > ! >> > >> > --- On Sat, 1/9/10, Lukas Renggli >> wrote: >> > >> >> From: Lukas Renggli >> >> Subject: Re: 3.0 merge status (observations and a >> code variant) >> >> To: "Magritte, Pier and Related Tools ..." >> >> 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 > From grshiplett2 at yahoo.com Mon Jan 11 00:43:27 2010 From: grshiplett2 at yahoo.com (Robert Shiplett) Date: Sun, 10 Jan 2010 15:43:27 -0800 (PST) Subject: 3.0 merge status (observations and a code variant) In-Reply-To: <4a5dbd431001101503j21d88adci328ca8d9847ee177@mail.gmail.com> Message-ID: <613693.14013.qm@web51602.mail.re2.yahoo.com> 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 wrote: > From: Julian Fitzell > Subject: Re: 3.0 merge status (observations and a code variant) > To: "Seaside - general discussion" > Cc: "Magritte, Pier and Related Tools ..." > 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 > 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 > wrote: > > > >> From: Lukas Renggli > >> Subject: Re: 3.0 merge status (observations and a > code variant) > >> To: "Magritte, Pier and Related Tools ..." > >> 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 ? > >> ?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 ? > >> ?the token that contains the literal value as > well as its > >> source positions > >> > > >> > ! > >> > > >> > --- On Sat, 1/9/10, Lukas Renggli > >> wrote: > >> > > >> >> From: Lukas Renggli > >> >> Subject: Re: 3.0 merge status > (observations and a > >> code variant) > >> >> To: "Magritte, Pier and Related Tools > ..." > >> >> 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 > From grshiplett2 at yahoo.com Mon Jan 11 01:15:30 2010 From: grshiplett2 at yahoo.com (Robert Shiplett) Date: Sun, 10 Jan 2010 16:15:30 -0800 (PST) Subject: 3.0 merge status (observations and a code variant) In-Reply-To: <4a5dbd431001101503j21d88adci328ca8d9847ee177@mail.gmail.com> Message-ID: <476738.11618.qm@web51603.mail.re2.yahoo.com> 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 wrote: > From: Julian Fitzell > Subject: Re: 3.0 merge status (observations and a code variant) > To: "Seaside - general discussion" > Cc: "Magritte, Pier and Related Tools ..." > 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 > 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 > wrote: > > > >> From: Lukas Renggli > >> Subject: Re: 3.0 merge status (observations and a > code variant) > >> To: "Magritte, Pier and Related Tools ..." > >> 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 ? > >> ?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 ? > >> ?the token that contains the literal value as > well as its > >> source positions > >> > > >> > ! > >> > > >> > --- On Sat, 1/9/10, Lukas Renggli > >> wrote: > >> > > >> >> From: Lukas Renggli > >> >> Subject: Re: 3.0 merge status > (observations and a > >> code variant) > >> >> To: "Magritte, Pier and Related Tools > ..." > >> >> 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 > From grshiplett2 at yahoo.com Mon Jan 11 02:38:27 2010 From: grshiplett2 at yahoo.com (Robert Shiplett) Date: Sun, 10 Jan 2010 17:38:27 -0800 (PST) Subject: 3.0 merge status (observations and a code variant) In-Reply-To: <4a5dbd431001101503j21d88adci328ca8d9847ee177@mail.gmail.com> Message-ID: <198633.51485.qm@web51604.mail.re2.yahoo.com> "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 wrote: > From: Julian Fitzell > Subject: Re: 3.0 merge status (observations and a code variant) > To: "Seaside - general discussion" > Cc: "Magritte, Pier and Related Tools ..." > 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 > 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 > wrote: > > > >> From: Lukas Renggli > >> Subject: Re: 3.0 merge status (observations and a > code variant) > >> To: "Magritte, Pier and Related Tools ..." > >> 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 ? > >> ?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 ? > >> ?the token that contains the literal value as > well as its > >> source positions > >> > > >> > ! > >> > > >> > --- On Sat, 1/9/10, Lukas Renggli > >> wrote: > >> > > >> >> From: Lukas Renggli > >> >> Subject: Re: 3.0 merge status > (observations and a > >> code variant) > >> >> To: "Magritte, Pier and Related Tools > ..." > >> >> 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 > From nick.ager at gmail.com Mon Jan 11 12:54:22 2010 From: nick.ager at gmail.com (Nick Ager) Date: Mon, 11 Jan 2010 11:54:22 +0000 Subject: 3.0 merge status In-Reply-To: <67628d691001090732l327443d6nb503b0e6ddc5322b@mail.gmail.com> References: <3a06f76f1001081202h59d99fe8na9b249c3f75ee555@mail.gmail.com> <67628d691001090732l327443d6nb503b0e6ddc5322b@mail.gmail.com> Message-ID: <3a06f76f1001110354r6356ccfesa3597f41074658c0@mail.gmail.com> 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 > Thank you for these scripts. I use them to load the new code into > Seaside 3.0 images, see > . > > 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 : > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Mon Jan 11 13:37:32 2010 From: nick.ager at gmail.com (Nick Ager) Date: Mon, 11 Jan 2010 12:37:32 +0000 Subject: seaside 3.0 pier image loading problem In-Reply-To: <4a5dbd431001101437x7fcf2724w53db287aeadccecb@mail.gmail.com> References: <3a06f76f1001101225t6ba87d4dtc6f6539119e2f574@mail.gmail.com> <4a5dbd431001101437x7fcf2724w53db287aeadccecb@mail.gmail.com> Message-ID: <3a06f76f1001110437r46713651n5c0bdcd248304ba6@mail.gmail.com> OK style sheet path changed, image now appears. Changes in: Pier-Seaside-NickAger.466 Should I add an issue to the bug tracker about loosing url parameters during redirection? BTW I've noticed that WAOldPathComptibilityRequestHandler has been renamed WALegacyRedirectionHandler in the latest code. 2010/1/10 Julian Fitzell > Sigh... > > Can you just fix the stylesheet to drop the /seaside for now? > > I'm generally unhappy with how WARequest/WAUrl are working in this > regard at the moment... I'll bring it up with the Seaside team and see > what we can do about it. > > Julian > > On Sun, Jan 10, 2010 at 12:25 PM, Nick Ager wrote: > > When I merged the latest Pier code with the Pier for Seaside 3.0 branch I > > noticed that the Pier logo wasn't appearing on the initial screen, > although > > it appeared on the 3.0 branch prior to the merge. > > I traced the difference in behaviour down to a code change in > > PRViewCommand>>initialRequest > > the pre-merge version: > > initialRequest: aRequest > > | viewClass | > > super initialRequest: aRequest. > > viewClass := PRPierFrame > > classFromRequest: aRequest > > name: 'view' > > base: PRViewComponent. > > (viewClass isNil and: [ self structure isFile ]) > > ifTrue: [ viewClass := PRDownloadView ]. > > (viewClass notNil and: [ viewClass isValidIn: self context ]) > > ifTrue: [ self viewComponentClass: viewClass ]. > > self viewComponent visiblePresentersDo: [ :each | each initialRequest: > > aRequest ]. > > (self viewComponent isFullResponse) > > ifTrue: [ self viewComponent handle: WACurrentRequestContext value ] > > post-merge version: > > initialRequest: aRequest > > | viewClass | > > super initialRequest: aRequest. > > viewClass := PRPierFrame > > classFromRequest: aRequest > > name: 'view' > > base: PRViewComponent. > > (viewClass notNil and: [ viewClass isValidIn: self context ]) > > ifTrue: [ self viewComponentClass: viewClass ]. > > self viewComponent visiblePresentersDo: [ :each | each initialRequest: > > aRequest ]. > > (self viewComponent isFullResponse) > > ifTrue: [ self viewComponent handle: WACurrentRequestContext value ] > > the pre-merge version has the addition of the code: (viewClass isNil and: > [ > > self structure isFile ]) ifTrue: [ viewClass := PRDownloadView ]. > > However this code isn't present in the main 2.8 code-base. The problem is > > more subtle. The pier environment stylesheet requests an image from: > > '/seaside/pier/environment/pier.png?view=PRDownloadView' this is trapped > by > > the code in WAOldPathComptibilityRequestHandler which issues a 301 moved > > permanently redirect to '/pier/environment/pier.png'. The problem is that > > during the redirection the url parameters have been lost. I've fixed the > > problem locally by changing > > WAOldPathComptibilityRequestHandler>>handleFiltered: from: > > handleFiltered: aRequestContext > > | url | > > url := aRequestContext request url copy. > > url path removeFirst. > > aRequestContext response > > movedPermanently; > > location: url. > > aRequestContext respond > > to: > > handleFiltered: aRequestContext > > | url | > > url := aRequestContext request url copy. > > url path removeFirst. > > url parameters: aRequestContext request fields. > > aRequestContext response > > movedPermanently; > > location: url. > > aRequestContext respond > > I copy the parameters from the request to the url. Should I save this > change > > into seaside 3.0 repositories? Or is there something else that needs > fixing > > higher up the call stack to account for why the parameters haven't been > > added to the WAUrl object? > > Hope this all makes sense > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Mon Jan 11 13:40:45 2010 From: nick.ager at gmail.com (Nick Ager) Date: Mon, 11 Jan 2010 12:40:45 +0000 Subject: stylesheet rendering problem on seaside 3.0 Message-ID: <3a06f76f1001110440g7a5b8845v473617f24044d41b@mail.gmail.com> On the pier seaside 3.0 code-branch, browsing to: http://localhost:8080/pier/environment/style.css, results in: #[47 42 32 98 108 117 101 112 114 105 110 ... rather than: /* blueprint patches */ h1, h2, h3, h4, h5, h6 { margin: 0; fo.... This issue is caused by a change in how ByteArray is rendered in Seaside 3.0 (the problem was also present prior to merging the latest Pier code): seaside 2.8 Object>>encodeOn: aDocument aDocument print: self displayStriong seaside 3.0 Object>>encodeOn: aDocument aDocument print: self greaseString ByteArray>>greaseString "ByteArrays should not automatically be converted to Strings. You should use a GRCodec for this." ^ self printString changing ByteArray>>greaseString to return self displayString fixes the problem. However I can see there are a number of ways to fix this, and as it's such a low level change I'm sure there was a good reason for displayString to be changed to printString. Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Mon Jan 11 18:41:33 2010 From: nick.ager at gmail.com (Nick Ager) Date: Mon, 11 Jan 2010 17:41:33 +0000 Subject: seaside 3.0, blog, book, link-checker and persistence Message-ID: <3a06f76f1001110941w73bd8dd0iff1b2fea27326d63@mail.gmail.com> Hi, I've turned my attention to merging the latest code in the add-ons, which resulted in some questions: * Pier-Blog - easy merge, no conflicts * Pier-Book - 9 conflicts - the merge didn't look straight-forward so I thought I'd leave it to someone with more intimate knowledge of the code and changes... * Pier-LinkChecker - I couldn't find the trunk version of this package - I didn't spot it in pier or pieraddons repositories * Pier-Pharo-Persistency - I couldn't find the trunk version. Is it a rename from Pier-Seaside-Persistency? * Pier-Seaside-Persistency - I'm running under Pharo so I'll leave this to someone else. In summary I only merged Pier-Blog -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfitzell at gmail.com Mon Jan 11 19:32:14 2010 From: jfitzell at gmail.com (Julian Fitzell) Date: Mon, 11 Jan 2010 10:32:14 -0800 Subject: seaside 3.0 pier image loading problem In-Reply-To: <3a06f76f1001110437r46713651n5c0bdcd248304ba6@mail.gmail.com> References: <3a06f76f1001101225t6ba87d4dtc6f6539119e2f574@mail.gmail.com> <4a5dbd431001101437x7fcf2724w53db287aeadccecb@mail.gmail.com> <3a06f76f1001110437r46713651n5c0bdcd248304ba6@mail.gmail.com> Message-ID: <4a5dbd431001111032g3de5d30gaac62558e6865b92@mail.gmail.com> Sure, file and issue for Seaside, if you don't mind. Julian On Mon, Jan 11, 2010 at 4:37 AM, Nick Ager wrote: > OK style sheet path changed, image now appears. Changes in: > Pier-Seaside-NickAger.466 > Should I add an issue to the bug tracker about loosing url parameters > during?redirection? > BTW I've noticed that?WAOldPathComptibilityRequestHandler has been > renamed?WALegacyRedirectionHandler in the latest code. > > 2010/1/10 Julian Fitzell >> >> Sigh... >> >> Can you just fix the stylesheet to drop the /seaside for now? >> >> I'm generally unhappy with how WARequest/WAUrl are working in this >> regard at the moment... I'll bring it up with the Seaside team and see >> what we can do about it. >> >> Julian >> >> On Sun, Jan 10, 2010 at 12:25 PM, Nick Ager wrote: >> > When I merged the latest Pier code with the Pier for Seaside 3.0 branch >> > I >> > noticed that the Pier logo wasn't appearing on the initial screen, >> > although >> > it appeared on the 3.0 branch prior to the merge. >> > I traced the difference in behaviour down to a code change in >> > PRViewCommand>>initialRequest >> > the pre-merge version: >> > initialRequest: aRequest >> > | viewClass | >> > super initialRequest: aRequest. >> > viewClass := PRPierFrame >> > classFromRequest: aRequest >> > name: 'view' >> > base: PRViewComponent. >> > (viewClass isNil and: [ self structure isFile ]) >> > ifTrue: [ viewClass := PRDownloadView ]. >> > (viewClass notNil and: [ viewClass isValidIn: self context ]) >> > ifTrue: [ self viewComponentClass: viewClass ]. >> > self viewComponent visiblePresentersDo: [ :each | each initialRequest: >> > aRequest ]. >> > (self viewComponent isFullResponse) >> > ifTrue: [ self viewComponent handle: WACurrentRequestContext value ] >> > post-merge version: >> > initialRequest: aRequest >> > | viewClass | >> > super initialRequest: aRequest. >> > viewClass := PRPierFrame >> > classFromRequest: aRequest >> > name: 'view' >> > base: PRViewComponent. >> > (viewClass notNil and: [ viewClass isValidIn: self context ]) >> > ifTrue: [ self viewComponentClass: viewClass ]. >> > self viewComponent visiblePresentersDo: [ :each | each initialRequest: >> > aRequest ]. >> > (self viewComponent isFullResponse) >> > ifTrue: [ self viewComponent handle: WACurrentRequestContext value ] >> > the pre-merge version has the addition of the code:?(viewClass isNil >> > and: [ >> > self structure isFile ])?ifTrue: [ viewClass := PRDownloadView ]. >> > However this code isn't present in the main 2.8 code-base. The problem >> > is >> > more subtle. The pier environment stylesheet requests an image from: >> > '/seaside/pier/environment/pier.png?view=PRDownloadView' this is trapped >> > by >> > the code in?WAOldPathComptibilityRequestHandler which issues a 301 moved >> > permanently redirect to?'/pier/environment/pier.png'. The problem is >> > that >> > during the redirection the url parameters have been lost. I've fixed the >> > problem locally by changing >> > WAOldPathComptibilityRequestHandler>>handleFiltered: from: >> > handleFiltered: aRequestContext >> > | url | >> > url := aRequestContext request url copy. >> > url path removeFirst. >> > aRequestContext response >> > movedPermanently; >> > location: url. >> > aRequestContext respond >> > to: >> > handleFiltered: aRequestContext >> > | url | >> > url := aRequestContext request url copy. >> > url path removeFirst. >> > url parameters: aRequestContext request fields. >> > aRequestContext response >> > movedPermanently; >> > location: url. >> > aRequestContext respond >> > I copy the parameters from the request to the url. Should I save this >> > change >> > into seaside 3.0 repositories? Or is there something else that needs >> > fixing >> > higher up the call stack to account for why the parameters haven't been >> > added to the WAUrl object? >> > Hope this all makes sense >> > 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 > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > From jfitzell at gmail.com Mon Jan 11 19:33:47 2010 From: jfitzell at gmail.com (Julian Fitzell) Date: Mon, 11 Jan 2010 10:33:47 -0800 Subject: stylesheet rendering problem on seaside 3.0 In-Reply-To: <3a06f76f1001110440g7a5b8845v473617f24044d41b@mail.gmail.com> References: <3a06f76f1001110440g7a5b8845v473617f24044d41b@mail.gmail.com> Message-ID: <4a5dbd431001111033n618fdcc1lca9543b51b6cf63a@mail.gmail.com> Maybe we need to implement #encodeOn: on ByteArray? Lukas? Julian On Mon, Jan 11, 2010 at 4:40 AM, Nick Ager wrote: > On the pier seaside 3.0 code-branch, browsing > to:?http://localhost:8080/pier/environment/style.css,?results in: > #[47 42 32 98 108 117 101 112 114 105 110 ... > rather than: > /* blueprint patches */ > h1, h2, h3, h4, h5, h6 { margin: 0; fo.... > This issue is caused by a change in how ByteArray is rendered in Seaside 3.0 > (the problem was also present prior to merging the latest Pier code): > seaside 2.8 > Object>>encodeOn: aDocument > ?? ?aDocument print: self displayStriong > seaside 3.0 > Object>>encodeOn: aDocument > ?? ?aDocument print: self greaseString > ByteArray>>greaseString > "ByteArrays should not automatically be converted to Strings. You should use > a GRCodec for this." > ^ self printString > changing ByteArray>>greaseString to return self displayString fixes the > problem. However I can see there are a number of ways to fix this, and as > it's such a low level change I'm sure there was a good reason for > displayString to be changed to printString. Thoughts? > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > From jfitzell at gmail.com Mon Jan 11 19:41:06 2010 From: jfitzell at gmail.com (Julian Fitzell) Date: Mon, 11 Jan 2010 10:41:06 -0800 Subject: seaside 3.0, blog, book, link-checker and persistence In-Reply-To: <3a06f76f1001110941w73bd8dd0iff1b2fea27326d63@mail.gmail.com> References: <3a06f76f1001110941w73bd8dd0iff1b2fea27326d63@mail.gmail.com> Message-ID: <4a5dbd431001111041l6cfd964egc90519f2b23f8cb@mail.gmail.com> On Mon, Jan 11, 2010 at 9:41 AM, Nick Ager wrote: > Hi, > I've turned my attention to merging the latest code in the add-ons, which > resulted in some questions: > * Pier-Blog - easy merge, no conflicts > * Pier-Book - 9 conflicts - the merge didn't look straight-forward so I > thought I'd leave it to someone with more intimate knowledge of the code and > changes... > * Pier-LinkChecker - I couldn't find the trunk version of this package - I > didn't spot it in pier or pieraddons repositories Hi Nick, I think I pulled that code out of some other package (security?). > * Pier-Pharo-Persistency - I couldn't find the trunk version. Is it a rename > from Pier-Seaside-Persistency? I assume you mean Pier-Squeak-Persistency? > * Pier-Seaside-Persistency - I'm running under Pharo so I'll leave this to > someone else. As above - it was renamed. If you look at the history for Pier-Pharo-Persistency, you'll see the first version says: -------------- Name: Pier-Pharo-Persistency-jf.1 Author: jf Time: 3 November 2009, 11:22:49 am UUID: f8aaec5e-e993-433c-9599-caf72beb50df Ancestors: Rename Pier-Squeak-Persistency to Pier-Pharo-Persistency -------------- The last version of Pier-Squeak-Persistency should say the same thing and should also be empty (since all the code was moved out of it). Julian From nick.ager at gmail.com Mon Jan 11 20:10:18 2010 From: nick.ager at gmail.com (Nick Ager) Date: Mon, 11 Jan 2010 19:10:18 +0000 Subject: seaside 3.0 pier image loading problem In-Reply-To: <4a5dbd431001111032g3de5d30gaac62558e6865b92@mail.gmail.com> References: <3a06f76f1001101225t6ba87d4dtc6f6539119e2f574@mail.gmail.com> <4a5dbd431001101437x7fcf2724w53db287aeadccecb@mail.gmail.com> <3a06f76f1001110437r46713651n5c0bdcd248304ba6@mail.gmail.com> <4a5dbd431001111032g3de5d30gaac62558e6865b92@mail.gmail.com> Message-ID: <3a06f76f1001111110w70bc0bd4r1b3999f67cfe3997@mail.gmail.com> filed: http://code.google.com/p/seaside/issues/detail?id=525 2010/1/11 Julian Fitzell > Sure, file and issue for Seaside, if you don't mind. > > Julian > > On Mon, Jan 11, 2010 at 4:37 AM, Nick Ager wrote: > > OK style sheet path changed, image now appears. Changes in: > > Pier-Seaside-NickAger.466 > > Should I add an issue to the bug tracker about loosing url parameters > > during redirection? > > BTW I've noticed that WAOldPathComptibilityRequestHandler has been > > renamed WALegacyRedirectionHandler in the latest code. > > > > 2010/1/10 Julian Fitzell > >> > >> Sigh... > >> > >> Can you just fix the stylesheet to drop the /seaside for now? > >> > >> I'm generally unhappy with how WARequest/WAUrl are working in this > >> regard at the moment... I'll bring it up with the Seaside team and see > >> what we can do about it. > >> > >> Julian > >> > >> On Sun, Jan 10, 2010 at 12:25 PM, Nick Ager > wrote: > >> > When I merged the latest Pier code with the Pier for Seaside 3.0 > branch > >> > I > >> > noticed that the Pier logo wasn't appearing on the initial screen, > >> > although > >> > it appeared on the 3.0 branch prior to the merge. > >> > I traced the difference in behaviour down to a code change in > >> > PRViewCommand>>initialRequest > >> > the pre-merge version: > >> > initialRequest: aRequest > >> > | viewClass | > >> > super initialRequest: aRequest. > >> > viewClass := PRPierFrame > >> > classFromRequest: aRequest > >> > name: 'view' > >> > base: PRViewComponent. > >> > (viewClass isNil and: [ self structure isFile ]) > >> > ifTrue: [ viewClass := PRDownloadView ]. > >> > (viewClass notNil and: [ viewClass isValidIn: self context ]) > >> > ifTrue: [ self viewComponentClass: viewClass ]. > >> > self viewComponent visiblePresentersDo: [ :each | each initialRequest: > >> > aRequest ]. > >> > (self viewComponent isFullResponse) > >> > ifTrue: [ self viewComponent handle: WACurrentRequestContext value ] > >> > post-merge version: > >> > initialRequest: aRequest > >> > | viewClass | > >> > super initialRequest: aRequest. > >> > viewClass := PRPierFrame > >> > classFromRequest: aRequest > >> > name: 'view' > >> > base: PRViewComponent. > >> > (viewClass notNil and: [ viewClass isValidIn: self context ]) > >> > ifTrue: [ self viewComponentClass: viewClass ]. > >> > self viewComponent visiblePresentersDo: [ :each | each initialRequest: > >> > aRequest ]. > >> > (self viewComponent isFullResponse) > >> > ifTrue: [ self viewComponent handle: WACurrentRequestContext value ] > >> > the pre-merge version has the addition of the code: (viewClass isNil > >> > and: [ > >> > self structure isFile ]) ifTrue: [ viewClass := PRDownloadView ]. > >> > However this code isn't present in the main 2.8 code-base. The problem > >> > is > >> > more subtle. The pier environment stylesheet requests an image from: > >> > '/seaside/pier/environment/pier.png?view=PRDownloadView' this is > trapped > >> > by > >> > the code in WAOldPathComptibilityRequestHandler which issues a 301 > moved > >> > permanently redirect to '/pier/environment/pier.png'. The problem is > >> > that > >> > during the redirection the url parameters have been lost. I've fixed > the > >> > problem locally by changing > >> > WAOldPathComptibilityRequestHandler>>handleFiltered: from: > >> > handleFiltered: aRequestContext > >> > | url | > >> > url := aRequestContext request url copy. > >> > url path removeFirst. > >> > aRequestContext response > >> > movedPermanently; > >> > location: url. > >> > aRequestContext respond > >> > to: > >> > handleFiltered: aRequestContext > >> > | url | > >> > url := aRequestContext request url copy. > >> > url path removeFirst. > >> > url parameters: aRequestContext request fields. > >> > aRequestContext response > >> > movedPermanently; > >> > location: url. > >> > aRequestContext respond > >> > I copy the parameters from the request to the url. Should I save this > >> > change > >> > into seaside 3.0 repositories? Or is there something else that needs > >> > fixing > >> > higher up the call stack to account for why the parameters haven't > been > >> > added to the WAUrl object? > >> > Hope this all makes sense > >> > 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 > > > > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Mon Jan 11 23:37:55 2010 From: renggli at gmail.com (Lukas Renggli) Date: Mon, 11 Jan 2010 23:37:55 +0100 Subject: stylesheet rendering problem on seaside 3.0 In-Reply-To: <4a5dbd431001111033n618fdcc1lca9543b51b6cf63a@mail.gmail.com> References: <3a06f76f1001110440g7a5b8845v473617f24044d41b@mail.gmail.com> <4a5dbd431001111033n618fdcc1lca9543b51b6cf63a@mail.gmail.com> Message-ID: <67628d691001111437u7be814ccj908e96adade36ba1@mail.gmail.com> Has this been fixed, because it works here? Lukas 2010/1/11 Julian Fitzell : > Maybe we need to implement #encodeOn: on ByteArray? Lukas? > > Julian > > On Mon, Jan 11, 2010 at 4:40 AM, Nick Ager wrote: >> On the pier seaside 3.0 code-branch, browsing >> to:?http://localhost:8080/pier/environment/style.css,?results in: >> #[47 42 32 98 108 117 101 112 114 105 110 ... >> rather than: >> /* blueprint patches */ >> h1, h2, h3, h4, h5, h6 { margin: 0; fo.... >> This issue is caused by a change in how ByteArray is rendered in Seaside 3.0 >> (the problem was also present prior to merging the latest Pier code): >> seaside 2.8 >> Object>>encodeOn: aDocument >> ?? ?aDocument print: self displayStriong >> seaside 3.0 >> Object>>encodeOn: aDocument >> ?? ?aDocument print: self greaseString >> ByteArray>>greaseString >> "ByteArrays should not automatically be converted to Strings. You should use >> a GRCodec for this." >> ^ self printString >> changing ByteArray>>greaseString to return self displayString fixes the >> problem. However I can see there are a number of ways to fix this, and as >> it's such a low level change I'm sure there was a good reason for >> displayString to be changed to printString. Thoughts? >> >> _______________________________________________ >> 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 From nick.ager at gmail.com Tue Jan 12 01:52:45 2010 From: nick.ager at gmail.com (Nick Ager) Date: Tue, 12 Jan 2010 00:52:45 +0000 Subject: stylesheet rendering problem on seaside 3.0 In-Reply-To: <67628d691001111437u7be814ccj908e96adade36ba1@mail.gmail.com> References: <3a06f76f1001110440g7a5b8845v473617f24044d41b@mail.gmail.com> <4a5dbd431001111033n618fdcc1lca9543b51b6cf63a@mail.gmail.com> <67628d691001111437u7be814ccj908e96adade36ba1@mail.gmail.com> Message-ID: <3a06f76f1001111652t5fe4a11ambfbcb7a2e2ba0da3@mail.gmail.com> Still not working in my image - I thought I'd downloaded the latest seaside3.0 source today, so that's a little odd. ... unless something has changed in Pharo. I'm using Pharo09.12. Does your the implementation of ByteArray>>greaseString match this: ByteArray>>greaseString "ByteArrays should not automatically be converted to Strings. You should use a GRCodec for this." ^ self printString or does your image have an implementation of ByteArray>>encodeOn? 2010/1/11 Lukas Renggli > Has this been fixed, because it works here? > > Lukas > > 2010/1/11 Julian Fitzell : > > Maybe we need to implement #encodeOn: on ByteArray? Lukas? > > > > Julian > > > > On Mon, Jan 11, 2010 at 4:40 AM, Nick Ager wrote: > >> On the pier seaside 3.0 code-branch, browsing > >> to: http://localhost:8080/pier/environment/style.css, results in: > >> #[47 42 32 98 108 117 101 112 114 105 110 ... > >> rather than: > >> /* blueprint patches */ > >> h1, h2, h3, h4, h5, h6 { margin: 0; fo.... > >> This issue is caused by a change in how ByteArray is rendered in Seaside > 3.0 > >> (the problem was also present prior to merging the latest Pier code): > >> seaside 2.8 > >> Object>>encodeOn: aDocument > >> aDocument print: self displayStriong > >> seaside 3.0 > >> Object>>encodeOn: aDocument > >> aDocument print: self greaseString > >> ByteArray>>greaseString > >> "ByteArrays should not automatically be converted to Strings. You should > use > >> a GRCodec for this." > >> ^ self printString > >> changing ByteArray>>greaseString to return self displayString fixes the > >> problem. However I can see there are a number of ways to fix this, and > as > >> it's such a low level change I'm sure there was a good reason for > >> displayString to be changed to printString. Thoughts? > >> > >> _______________________________________________ > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Tue Jan 12 08:35:17 2010 From: renggli at gmail.com (Lukas Renggli) Date: Tue, 12 Jan 2010 08:35:17 +0100 Subject: stylesheet rendering problem on seaside 3.0 In-Reply-To: <3a06f76f1001111652t5fe4a11ambfbcb7a2e2ba0da3@mail.gmail.com> References: <3a06f76f1001110440g7a5b8845v473617f24044d41b@mail.gmail.com> <4a5dbd431001111033n618fdcc1lca9543b51b6cf63a@mail.gmail.com> <67628d691001111437u7be814ccj908e96adade36ba1@mail.gmail.com> <3a06f76f1001111652t5fe4a11ambfbcb7a2e2ba0da3@mail.gmail.com> Message-ID: <67628d691001112335q17b26871l612a839ed68d3bc0@mail.gmail.com> > Does your the implementation of > ByteArray>>greaseString match this: > ByteArray>>greaseString > "ByteArrays should not automatically be converted to Strings. You should use > a GRCodec for this." > ^ self printString Yes. > or does your image have an implementation of?ByteArray>>encodeOn? No. Maybe you should clear your browser caches? Lukas > 2010/1/11 Lukas Renggli >> >> Has this been fixed, because it works here? >> >> Lukas >> >> 2010/1/11 Julian Fitzell : >> > Maybe we need to implement #encodeOn: on ByteArray? Lukas? >> > >> > Julian >> > >> > On Mon, Jan 11, 2010 at 4:40 AM, Nick Ager wrote: >> >> On the pier seaside 3.0 code-branch, browsing >> >> to:?http://localhost:8080/pier/environment/style.css,?results in: >> >> #[47 42 32 98 108 117 101 112 114 105 110 ... >> >> rather than: >> >> /* blueprint patches */ >> >> h1, h2, h3, h4, h5, h6 { margin: 0; fo.... >> >> This issue is caused by a change in how ByteArray is rendered in >> >> Seaside 3.0 >> >> (the problem was also present prior to merging the latest Pier code): >> >> seaside 2.8 >> >> Object>>encodeOn: aDocument >> >> ?? ?aDocument print: self displayStriong >> >> seaside 3.0 >> >> Object>>encodeOn: aDocument >> >> ?? ?aDocument print: self greaseString >> >> ByteArray>>greaseString >> >> "ByteArrays should not automatically be converted to Strings. You >> >> should use >> >> a GRCodec for this." >> >> ^ self printString >> >> changing ByteArray>>greaseString to return self displayString fixes the >> >> problem. However I can see there are a number of ways to fix this, and >> >> as >> >> it's such a low level change I'm sure there was a good reason for >> >> displayString to be changed to printString. Thoughts? >> >> >> >> _______________________________________________ >> >> 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 From nick.ager at gmail.com Tue Jan 12 11:24:12 2010 From: nick.ager at gmail.com (Nick Ager) Date: Tue, 12 Jan 2010 10:24:12 +0000 Subject: stylesheet rendering problem on seaside 3.0 In-Reply-To: <67628d691001112335q17b26871l612a839ed68d3bc0@mail.gmail.com> References: <3a06f76f1001110440g7a5b8845v473617f24044d41b@mail.gmail.com> <4a5dbd431001111033n618fdcc1lca9543b51b6cf63a@mail.gmail.com> <67628d691001111437u7be814ccj908e96adade36ba1@mail.gmail.com> <3a06f76f1001111652t5fe4a11ambfbcb7a2e2ba0da3@mail.gmail.com> <67628d691001112335q17b26871l612a839ed68d3bc0@mail.gmail.com> Message-ID: <3a06f76f1001120224l6ce1c25ap6fab0c6fa37eb152@mail.gmail.com> Hi Lukas, Don't think the browse cache is the problem. What do you get with: #[100 101 98 117 103 103 105 110 103] greaseString on my image the result: '#[100 101 98 117 103 103 105 110 103]' 2010/1/12 Lukas Renggli > > Does your the implementation of > > ByteArray>>greaseString match this: > > ByteArray>>greaseString > > "ByteArrays should not automatically be converted to Strings. You should > use > > a GRCodec for this." > > ^ self printString > > Yes. > > > or does your image have an implementation of ByteArray>>encodeOn? > > No. > > Maybe you should clear your browser caches? > > Lukas > > > 2010/1/11 Lukas Renggli > >> > >> Has this been fixed, because it works here? > >> > >> Lukas > >> > >> 2010/1/11 Julian Fitzell : > >> > Maybe we need to implement #encodeOn: on ByteArray? Lukas? > >> > > >> > Julian > >> > > >> > On Mon, Jan 11, 2010 at 4:40 AM, Nick Ager > wrote: > >> >> On the pier seaside 3.0 code-branch, browsing > >> >> to: http://localhost:8080/pier/environment/style.css, results in: > >> >> #[47 42 32 98 108 117 101 112 114 105 110 ... > >> >> rather than: > >> >> /* blueprint patches */ > >> >> h1, h2, h3, h4, h5, h6 { margin: 0; fo.... > >> >> This issue is caused by a change in how ByteArray is rendered in > >> >> Seaside 3.0 > >> >> (the problem was also present prior to merging the latest Pier code): > >> >> seaside 2.8 > >> >> Object>>encodeOn: aDocument > >> >> aDocument print: self displayStriong > >> >> seaside 3.0 > >> >> Object>>encodeOn: aDocument > >> >> aDocument print: self greaseString > >> >> ByteArray>>greaseString > >> >> "ByteArrays should not automatically be converted to Strings. You > >> >> should use > >> >> a GRCodec for this." > >> >> ^ self printString > >> >> changing ByteArray>>greaseString to return self displayString fixes > the > >> >> problem. However I can see there are a number of ways to fix this, > and > >> >> as > >> >> it's such a low level change I'm sure there was a good reason for > >> >> displayString to be changed to printString. Thoughts? > >> >> > >> >> _______________________________________________ > >> >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Tue Jan 12 11:59:14 2010 From: renggli at gmail.com (Lukas Renggli) Date: Tue, 12 Jan 2010 11:59:14 +0100 Subject: stylesheet rendering problem on seaside 3.0 In-Reply-To: <3a06f76f1001120224l6ce1c25ap6fab0c6fa37eb152@mail.gmail.com> References: <3a06f76f1001110440g7a5b8845v473617f24044d41b@mail.gmail.com> <4a5dbd431001111033n618fdcc1lca9543b51b6cf63a@mail.gmail.com> <67628d691001111437u7be814ccj908e96adade36ba1@mail.gmail.com> <3a06f76f1001111652t5fe4a11ambfbcb7a2e2ba0da3@mail.gmail.com> <67628d691001112335q17b26871l612a839ed68d3bc0@mail.gmail.com> <3a06f76f1001120224l6ce1c25ap6fab0c6fa37eb152@mail.gmail.com> Message-ID: <67628d691001120259l2c62c89fs59efbbb3fd373532@mail.gmail.com> #[100 101 98 117 103 103 105 110 103], but this method is never called when I browse Pier. Lukas 2010/1/12 Nick Ager : > Hi Lukas, > Don't think the browse cache is the problem. What do you get with: > #[100 101 98 117 103 103 105 110 103] greaseString > on my image the result: > ?'#[100 101 98 117 103 103 105 110 103]' > > 2010/1/12 Lukas Renggli >> >> > Does your the implementation of >> > ByteArray>>greaseString match this: >> > ByteArray>>greaseString >> > "ByteArrays should not automatically be converted to Strings. You should >> > use >> > a GRCodec for this." >> > ^ self printString >> >> Yes. >> >> > or does your image have an implementation of?ByteArray>>encodeOn? >> >> No. >> >> Maybe you should clear your browser caches? >> >> Lukas >> >> > 2010/1/11 Lukas Renggli >> >> >> >> Has this been fixed, because it works here? >> >> >> >> Lukas >> >> >> >> 2010/1/11 Julian Fitzell : >> >> > Maybe we need to implement #encodeOn: on ByteArray? Lukas? >> >> > >> >> > Julian >> >> > >> >> > On Mon, Jan 11, 2010 at 4:40 AM, Nick Ager >> >> > wrote: >> >> >> On the pier seaside 3.0 code-branch, browsing >> >> >> to:?http://localhost:8080/pier/environment/style.css,?results in: >> >> >> #[47 42 32 98 108 117 101 112 114 105 110 ... >> >> >> rather than: >> >> >> /* blueprint patches */ >> >> >> h1, h2, h3, h4, h5, h6 { margin: 0; fo.... >> >> >> This issue is caused by a change in how ByteArray is rendered in >> >> >> Seaside 3.0 >> >> >> (the problem was also present prior to merging the latest Pier >> >> >> code): >> >> >> seaside 2.8 >> >> >> Object>>encodeOn: aDocument >> >> >> ?? ?aDocument print: self displayStriong >> >> >> seaside 3.0 >> >> >> Object>>encodeOn: aDocument >> >> >> ?? ?aDocument print: self greaseString >> >> >> ByteArray>>greaseString >> >> >> "ByteArrays should not automatically be converted to Strings. You >> >> >> should use >> >> >> a GRCodec for this." >> >> >> ^ self printString >> >> >> changing ByteArray>>greaseString to return self displayString fixes >> >> >> the >> >> >> problem. However I can see there are a number of ways to fix this, >> >> >> and >> >> >> as >> >> >> it's such a low level change I'm sure there was a good reason for >> >> >> displayString to be changed to printString. Thoughts? >> >> >> >> >> >> _______________________________________________ >> >> >> 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 > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli http://www.lukas-renggli.ch From razavi at acm.org Tue Jan 12 13:00:06 2010 From: razavi at acm.org (Reza RAZAVI) Date: Tue, 12 Jan 2010 13:00:06 +0100 Subject: Porting Pier-Setup In-Reply-To: <67628d691001120259l2c62c89fs59efbbb3fd373532@mail.gmail.co m> References: <3a06f76f1001110440g7a5b8845v473617f24044d41b@mail.gmail.com> <4a5dbd431001111033n618fdcc1lca9543b51b6cf63a@mail.gmail.com> <67628d691001111437u7be814ccj908e96adade36ba1@mail.gmail.com> <3a06f76f1001111652t5fe4a11ambfbcb7a2e2ba0da3@mail.gmail.com> <67628d691001112335q17b26871l612a839ed68d3bc0@mail.gmail.com> <3a06f76f1001120224l6ce1c25ap6fab0c6fa37eb152@mail.gmail.com> <67628d691001120259l2c62c89fs59efbbb3fd373532@mail.gmail.com> Message-ID: <89dhun$hvkhj@smtp.pt.lu> Hello and Happy New Year to the list. Thank you Julian, Nick, and Lukas for the port to Seaside 3.0. I'd like to give a hand to finalize this port, and started by "Pier-Setup" as follows: - Dependencies (in addition to the core Pier packages): Pier-Blog, Pier-Documents, Pier-Google, and Pier-Book. - Starting point: http://hudson.lukas-renggli.ch/job/Seaside%203.0/. - Loaded from http://source.lukas-renggli.ch/pier2: Pier-Blog-NickAger.135 and Pier-Documents-NickAger.17. - Loaded from http://source.lukas-renggli.ch/pieraddons: Pier-Google-lr.16, Pier-Book-lr.112, Pier-Setup-lr.71. Had just to edit one method (please see the attached file). - Executed "PRLoader setupPier" - Pointed to http://localhost:8080/pier. As far as I could test, it just works fine, including Gadgets. - Loaded Pier-Design-lr.8 to have the "Edit Design" command. It works, except for the stylesheet rendering issue already reported by Nick. Questions: 1) Would it make sense to isolate PRBookDistribution in a separate package, to avoid the current dependency between Pier-Setup & Pier-Book? 2) Would it make sense to have a PierBasicDistribution, without dependencies to Pier-Blog, Pier-Documents, Pier-Google? (PierDistribution could obviously then be a subclass of PierBasicDistribution). 3) Should I upload the above packages? 3.b) If yes, in which repository: http://source.lukas-renggli.ch/pier2 or http://source.lukas-renggli.ch/pier2-addon? For the moment all core and addon packages are in the same repository, which is somehow more practical compared to Pier 1. Remaining issues: A) Load scripts in PRLoader need to by adapted to the new repositories. B) Testing PREventDistribution and PRBookDistribution. I'm going to take care of (B). Cheers, Reza -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rra_2010_01_12.a.st Type: application/octet-stream Size: 927 bytes Desc: not available URL: From renggli at gmail.com Tue Jan 12 13:25:01 2010 From: renggli at gmail.com (Lukas Renggli) Date: Tue, 12 Jan 2010 13:25:01 +0100 Subject: Porting Pier-Setup In-Reply-To: <89dhun$hvkhj@smtp.pt.lu> References: <3a06f76f1001110440g7a5b8845v473617f24044d41b@mail.gmail.com> <4a5dbd431001111033n618fdcc1lca9543b51b6cf63a@mail.gmail.com> <67628d691001111437u7be814ccj908e96adade36ba1@mail.gmail.com> <3a06f76f1001111652t5fe4a11ambfbcb7a2e2ba0da3@mail.gmail.com> <67628d691001112335q17b26871l612a839ed68d3bc0@mail.gmail.com> <3a06f76f1001120224l6ce1c25ap6fab0c6fa37eb152@mail.gmail.com> <67628d691001120259l2c62c89fs59efbbb3fd373532@mail.gmail.com> <89dhun$hvkhj@smtp.pt.lu> Message-ID: <67628d691001120425x48f46e54md5eae522e3a94ec9@mail.gmail.com> > I'd like to give a hand to finalize this port, and started by "Pier-Setup" > as follows: As the commit comment says "Pier-Setup" is broken. I do not suggest to use it at the moment. Doru said that he is going to look at it. > 1) Would it make sense to isolate PRBookDistribution in a separate package, > to avoid the current dependency between Pier-Setup & Pier-Book? Pier-Setup is used to build the one-click images. It is not really ment to be used as an end-user tool. > 2) Would it make sense to have a PierBasicDistribution, without dependencies > to Pier-Blog, Pier-Documents, Pier-Google? (PierDistribution could obviously > then be a subclass of PierBasicDistribution). I would prefer to avoid too many extra packages. > A) Load scripts in PRLoader need to by adapted to the new repositories. > B) Testing PREventDistribution and PRBookDistribution. These two are broken in Pier 1. If you have a look at that could you first fix them for Pier 1? Lukas -- Lukas Renggli http://www.lukas-renggli.ch From razavi at acm.org Tue Jan 12 15:13:37 2010 From: razavi at acm.org (Reza RAZAVI) Date: Tue, 12 Jan 2010 15:13:37 +0100 Subject: Porting Pier-Setup In-Reply-To: <67628d691001120425x48f46e54md5eae522e3a94ec9@mail.gmail.co m> References: <3a06f76f1001110440g7a5b8845v473617f24044d41b@mail.gmail.com> <4a5dbd431001111033n618fdcc1lca9543b51b6cf63a@mail.gmail.com> <67628d691001111437u7be814ccj908e96adade36ba1@mail.gmail.com> <3a06f76f1001111652t5fe4a11ambfbcb7a2e2ba0da3@mail.gmail.com> <67628d691001112335q17b26871l612a839ed68d3bc0@mail.gmail.com> <3a06f76f1001120224l6ce1c25ap6fab0c6fa37eb152@mail.gmail.com> <67628d691001120259l2c62c89fs59efbbb3fd373532@mail.gmail.com> <89dhun$hvkhj@smtp.pt.lu> <67628d691001120425x48f46e54md5eae522e3a94ec9@mail.gmail.com> Message-ID: <89dhun$i16f0@smtp.pt.lu> At 13:25 12/01/2010, Lukas Renggli wrote: >Pier-Setup is used to build the one-click images. It is not really >ment to be used as an end-user tool. I understand, but I find it particularly useful also for setting rapidly an environment for testing ideas in the context, etc. >These two are broken in Pier 1. If you have a look at that could you >first fix them for Pier 1? Sure. I'm going to look at that. Later, Reza From razavi at acm.org Tue Jan 12 17:19:02 2010 From: razavi at acm.org (Reza RAZAVI) Date: Tue, 12 Jan 2010 17:19:02 +0100 Subject: Pier-Setup change report (Pier 1 & 2) In-Reply-To: <67628d691001120425x48f46e54md5eae522e3a94ec9@mail.gmail.co m> References: <3a06f76f1001110440g7a5b8845v473617f24044d41b@mail.gmail.com> <4a5dbd431001111033n618fdcc1lca9543b51b6cf63a@mail.gmail.com> <67628d691001111437u7be814ccj908e96adade36ba1@mail.gmail.com> <3a06f76f1001111652t5fe4a11ambfbcb7a2e2ba0da3@mail.gmail.com> <67628d691001112335q17b26871l612a839ed68d3bc0@mail.gmail.com> <3a06f76f1001120224l6ce1c25ap6fab0c6fa37eb152@mail.gmail.com> <67628d691001120259l2c62c89fs59efbbb3fd373532@mail.gmail.com> <89dhun$hvkhj@smtp.pt.lu> <67628d691001120425x48f46e54md5eae522e3a94ec9@mail.gmail.com> Message-ID: <89dhun$i2o76@smtp.pt.lu> Pier 1: ---------- I uploaded a new package "Pier-Setup-razavi_acm_org.72" to: http://source.lukas-renggli.ch/pieraddons. For modification details, please see the package comments. Pier 2: --------- I loaded the same package into the Pier 2 image that I mentioned in a previous email this morning. All of the three distributions seem working fine. However, I had to hack the code in one method as follows (added calls to #asString and #asByteString]): GRPharoUtf8CodecStream >> nextPutAll: aString binary ifTrue: [ stream nextPutAll: aString asString ] ifFalse: [ aString asString isByteString ifTrue: [ self encodeFast: aString asString asByteString] ifFalse: [ self encodeDefault: aString asString] ]. An open (Seaside 3.0 ??) issue: ---------------------------------------------- When hot switching distributions via the Design Chooser interface in the Home page, the following call sequences raises an exception: WAApplication (WARegistry) >> urlFor:ifAbsent: WAApplication (WARequestHandler) >> url WADispatcher >> urlFor: WADispatcher >> nameOfHandler: However, by forcing the navigator to point to http://localhost:8080/pier, the new distribution is launched and seems fully operational. Cheers, Reza -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfitzell at gmail.com Tue Jan 12 22:50:01 2010 From: jfitzell at gmail.com (Julian Fitzell) Date: Tue, 12 Jan 2010 13:50:01 -0800 Subject: stylesheet rendering problem on seaside 3.0 In-Reply-To: <67628d691001120259l2c62c89fs59efbbb3fd373532@mail.gmail.com> References: <3a06f76f1001110440g7a5b8845v473617f24044d41b@mail.gmail.com> <4a5dbd431001111033n618fdcc1lca9543b51b6cf63a@mail.gmail.com> <67628d691001111437u7be814ccj908e96adade36ba1@mail.gmail.com> <3a06f76f1001111652t5fe4a11ambfbcb7a2e2ba0da3@mail.gmail.com> <67628d691001112335q17b26871l612a839ed68d3bc0@mail.gmail.com> <3a06f76f1001120224l6ce1c25ap6fab0c6fa37eb152@mail.gmail.com> <67628d691001120259l2c62c89fs59efbbb3fd373532@mail.gmail.com> Message-ID: <4a5dbd431001121350n70a1590fu135d84d18edf2cf0@mail.gmail.com> I'm seeing the same as Nick, fwiw. Same if I try to edit the stylesheet. Julian On Tue, Jan 12, 2010 at 2:59 AM, Lukas Renggli wrote: > #[100 101 98 117 103 103 105 110 103], but this method is never called > when I browse Pier. > > Lukas > > > 2010/1/12 Nick Ager : >> Hi Lukas, >> Don't think the browse cache is the problem. What do you get with: >> #[100 101 98 117 103 103 105 110 103] greaseString >> on my image the result: >> ?'#[100 101 98 117 103 103 105 110 103]' >> >> 2010/1/12 Lukas Renggli >>> >>> > Does your the implementation of >>> > ByteArray>>greaseString match this: >>> > ByteArray>>greaseString >>> > "ByteArrays should not automatically be converted to Strings. You should >>> > use >>> > a GRCodec for this." >>> > ^ self printString >>> >>> Yes. >>> >>> > or does your image have an implementation of?ByteArray>>encodeOn? >>> >>> No. >>> >>> Maybe you should clear your browser caches? >>> >>> Lukas >>> >>> > 2010/1/11 Lukas Renggli >>> >> >>> >> Has this been fixed, because it works here? >>> >> >>> >> Lukas >>> >> >>> >> 2010/1/11 Julian Fitzell : >>> >> > Maybe we need to implement #encodeOn: on ByteArray? Lukas? >>> >> > >>> >> > Julian >>> >> > >>> >> > On Mon, Jan 11, 2010 at 4:40 AM, Nick Ager >>> >> > wrote: >>> >> >> On the pier seaside 3.0 code-branch, browsing >>> >> >> to:?http://localhost:8080/pier/environment/style.css,?results in: >>> >> >> #[47 42 32 98 108 117 101 112 114 105 110 ... >>> >> >> rather than: >>> >> >> /* blueprint patches */ >>> >> >> h1, h2, h3, h4, h5, h6 { margin: 0; fo.... >>> >> >> This issue is caused by a change in how ByteArray is rendered in >>> >> >> Seaside 3.0 >>> >> >> (the problem was also present prior to merging the latest Pier >>> >> >> code): >>> >> >> seaside 2.8 >>> >> >> Object>>encodeOn: aDocument >>> >> >> ?? ?aDocument print: self displayStriong >>> >> >> seaside 3.0 >>> >> >> Object>>encodeOn: aDocument >>> >> >> ?? ?aDocument print: self greaseString >>> >> >> ByteArray>>greaseString >>> >> >> "ByteArrays should not automatically be converted to Strings. You >>> >> >> should use >>> >> >> a GRCodec for this." >>> >> >> ^ self printString >>> >> >> changing ByteArray>>greaseString to return self displayString fixes >>> >> >> the >>> >> >> problem. However I can see there are a number of ways to fix this, >>> >> >> and >>> >> >> as >>> >> >> it's such a low level change I'm sure there was a good reason for >>> >> >> displayString to be changed to printString. Thoughts? >>> >> >> >>> >> >> _______________________________________________ >>> >> >> 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 >> >> >> _______________________________________________ >> 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 > From nick.ager at gmail.com Tue Jan 12 23:59:54 2010 From: nick.ager at gmail.com (Nick Ager) Date: Tue, 12 Jan 2010 22:59:54 +0000 Subject: stylesheet rendering problem on seaside 3.0 In-Reply-To: <4a5dbd431001121350n70a1590fu135d84d18edf2cf0@mail.gmail.com> References: <3a06f76f1001110440g7a5b8845v473617f24044d41b@mail.gmail.com> <4a5dbd431001111033n618fdcc1lca9543b51b6cf63a@mail.gmail.com> <67628d691001111437u7be814ccj908e96adade36ba1@mail.gmail.com> <3a06f76f1001111652t5fe4a11ambfbcb7a2e2ba0da3@mail.gmail.com> <67628d691001112335q17b26871l612a839ed68d3bc0@mail.gmail.com> <3a06f76f1001120224l6ce1c25ap6fab0c6fa37eb152@mail.gmail.com> <67628d691001120259l2c62c89fs59efbbb3fd373532@mail.gmail.com> <4a5dbd431001121350n70a1590fu135d84d18edf2cf0@mail.gmail.com> Message-ID: <3a06f76f1001121459w188860c6j34be75257ff38e53@mail.gmail.com> I've tried to encapsulate the problem in a test: | stylesheetFile stylesheetContents rendererResult | stylesheetContents := '/* a style sheet */'. stylesheetFile := (PRFile named: 'defaultCss') filename: 'style.css'; mimetype: 'text/css'; contents: stylesheetContents. rendererResult := WARenderCanvas builder render: [ :html | html render: stylesheetFile file contents]. self assert: rendererResult = stylesheetContents In my image the assertion fails. If I change ByteArray>>greaseString to return self displayString the assertion succeeds. Does that help? 2010/1/12 Julian Fitzell > I'm seeing the same as Nick, fwiw. Same if I try to edit the stylesheet. > > Julian > > On Tue, Jan 12, 2010 at 2:59 AM, Lukas Renggli wrote: > > #[100 101 98 117 103 103 105 110 103], but this method is never called > > when I browse Pier. > > > > Lukas > > > > > > 2010/1/12 Nick Ager : > >> Hi Lukas, > >> Don't think the browse cache is the problem. What do you get with: > >> #[100 101 98 117 103 103 105 110 103] greaseString > >> on my image the result: > >> '#[100 101 98 117 103 103 105 110 103]' > >> > >> 2010/1/12 Lukas Renggli > >>> > >>> > Does your the implementation of > >>> > ByteArray>>greaseString match this: > >>> > ByteArray>>greaseString > >>> > "ByteArrays should not automatically be converted to Strings. You > should > >>> > use > >>> > a GRCodec for this." > >>> > ^ self printString > >>> > >>> Yes. > >>> > >>> > or does your image have an implementation of ByteArray>>encodeOn? > >>> > >>> No. > >>> > >>> Maybe you should clear your browser caches? > >>> > >>> Lukas > >>> > >>> > 2010/1/11 Lukas Renggli > >>> >> > >>> >> Has this been fixed, because it works here? > >>> >> > >>> >> Lukas > >>> >> > >>> >> 2010/1/11 Julian Fitzell : > >>> >> > Maybe we need to implement #encodeOn: on ByteArray? Lukas? > >>> >> > > >>> >> > Julian > >>> >> > > >>> >> > On Mon, Jan 11, 2010 at 4:40 AM, Nick Ager > >>> >> > wrote: > >>> >> >> On the pier seaside 3.0 code-branch, browsing > >>> >> >> to: http://localhost:8080/pier/environment/style.css, results > in: > >>> >> >> #[47 42 32 98 108 117 101 112 114 105 110 ... > >>> >> >> rather than: > >>> >> >> /* blueprint patches */ > >>> >> >> h1, h2, h3, h4, h5, h6 { margin: 0; fo.... > >>> >> >> This issue is caused by a change in how ByteArray is rendered in > >>> >> >> Seaside 3.0 > >>> >> >> (the problem was also present prior to merging the latest Pier > >>> >> >> code): > >>> >> >> seaside 2.8 > >>> >> >> Object>>encodeOn: aDocument > >>> >> >> aDocument print: self displayStriong > >>> >> >> seaside 3.0 > >>> >> >> Object>>encodeOn: aDocument > >>> >> >> aDocument print: self greaseString > >>> >> >> ByteArray>>greaseString > >>> >> >> "ByteArrays should not automatically be converted to Strings. You > >>> >> >> should use > >>> >> >> a GRCodec for this." > >>> >> >> ^ self printString > >>> >> >> changing ByteArray>>greaseString to return self displayString > fixes > >>> >> >> the > >>> >> >> problem. However I can see there are a number of ways to fix > this, > >>> >> >> and > >>> >> >> as > >>> >> >> it's such a low level change I'm sure there was a good reason for > >>> >> >> displayString to be changed to printString. Thoughts? > >>> >> >> > >>> >> >> _______________________________________________ > >>> >> >> 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 > >> > >> > >> _______________________________________________ > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Wed Jan 13 00:05:32 2010 From: nick.ager at gmail.com (Nick Ager) Date: Tue, 12 Jan 2010 23:05:32 +0000 Subject: stylesheet rendering problem on seaside 3.0 In-Reply-To: <3a06f76f1001121459w188860c6j34be75257ff38e53@mail.gmail.com> References: <3a06f76f1001110440g7a5b8845v473617f24044d41b@mail.gmail.com> <4a5dbd431001111033n618fdcc1lca9543b51b6cf63a@mail.gmail.com> <67628d691001111437u7be814ccj908e96adade36ba1@mail.gmail.com> <3a06f76f1001111652t5fe4a11ambfbcb7a2e2ba0da3@mail.gmail.com> <67628d691001112335q17b26871l612a839ed68d3bc0@mail.gmail.com> <3a06f76f1001120224l6ce1c25ap6fab0c6fa37eb152@mail.gmail.com> <67628d691001120259l2c62c89fs59efbbb3fd373532@mail.gmail.com> <4a5dbd431001121350n70a1590fu135d84d18edf2cf0@mail.gmail.com> <3a06f76f1001121459w188860c6j34be75257ff38e53@mail.gmail.com> Message-ID: <3a06f76f1001121505s5a126c80p804a8cad8aca5b4b@mail.gmail.com> I wonder if we've made it clear that stylesheet renders fine as a style sheet, it's only when you use Pier to view the stylesheet 'file' is the result is something like '[47 42 32 98 108 117 101 112 114 105 110 ..' Anyway hopefully the test above encapsulates the problem. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Wed Jan 13 01:00:04 2010 From: nick.ager at gmail.com (Nick Ager) Date: Wed, 13 Jan 2010 00:00:04 +0000 Subject: seaside 3.0, blog, book, link-checker and persistence In-Reply-To: <4a5dbd431001111041l6cfd964egc90519f2b23f8cb@mail.gmail.com> References: <3a06f76f1001110941w73bd8dd0iff1b2fea27326d63@mail.gmail.com> <4a5dbd431001111041l6cfd964egc90519f2b23f8cb@mail.gmail.com> Message-ID: <3a06f76f1001121600s764ae6fbu47ad6de222576197@mail.gmail.com> Hi Julian, I'm probably missing something, but with Pier-Squeak-Persistency being renamed to Pier-Pharo-Persistency in the pier2 repository, I don't seem to be able to get Monticello to provide me with useful merge information. Presumably Monticello can't work out a common ancestor. Am I missing something? It's a little academic as I've worked out what's changed by comparing differences in versions in the 2.8 Pier trunk - there's a new method PRKernel>>exportOn which has been extracted from the body of PRExportImportWidget>>export. resulting in a trivial merge in PRExportImportWidget>>export. I'm holding off in case I've missed something enabling a link to be made between the repositories again so that future merges won't be confused by my impending changes, though I'm probably being too pedantic and should just make the changes.... Nick 2010/1/11 Julian Fitzell > On Mon, Jan 11, 2010 at 9:41 AM, Nick Ager wrote: > > Hi, > > I've turned my attention to merging the latest code in the add-ons, which > > resulted in some questions: > > * Pier-Blog - easy merge, no conflicts > > * Pier-Book - 9 conflicts - the merge didn't look straight-forward so I > > thought I'd leave it to someone with more intimate knowledge of the code > and > > changes... > > * Pier-LinkChecker - I couldn't find the trunk version of this package - > I > > didn't spot it in pier or pieraddons repositories > > Hi Nick, > > I think I pulled that code out of some other package (security?). > > > * Pier-Pharo-Persistency - I couldn't find the trunk version. Is it a > rename > > from Pier-Seaside-Persistency? > > I assume you mean Pier-Squeak-Persistency? > > > * Pier-Seaside-Persistency - I'm running under Pharo so I'll leave this > to > > someone else. > > As above - it was renamed. If you look at the history for > Pier-Pharo-Persistency, you'll see the first version says: > > -------------- > Name: Pier-Pharo-Persistency-jf.1 > Author: jf > Time: 3 November 2009, 11:22:49 am > UUID: f8aaec5e-e993-433c-9599-caf72beb50df > Ancestors: > > Rename Pier-Squeak-Persistency to Pier-Pharo-Persistency > -------------- > > The last version of Pier-Squeak-Persistency should say the same thing > and should also be empty (since all the code was moved out of it). > > Julian > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfitzell at gmail.com Wed Jan 13 02:22:39 2010 From: jfitzell at gmail.com (Julian Fitzell) Date: Tue, 12 Jan 2010 17:22:39 -0800 Subject: seaside 3.0, blog, book, link-checker and persistence In-Reply-To: <3a06f76f1001121600s764ae6fbu47ad6de222576197@mail.gmail.com> References: <3a06f76f1001110941w73bd8dd0iff1b2fea27326d63@mail.gmail.com> <4a5dbd431001111041l6cfd964egc90519f2b23f8cb@mail.gmail.com> <3a06f76f1001121600s764ae6fbu47ad6de222576197@mail.gmail.com> Message-ID: <4a5dbd431001121722h60ccaeecjd05388fb9d9f3a5f@mail.gmail.com> No, you're not being pedantic... we really would like to maintain that history. But... we can't. :) MC's not quite up to the task unfortunately. In theory you could rename the class categories back, do the merge of the old-named package, then rename them back *again* and commit the new-named package. But I don't think it's worth the effort in this case. The other thing you could do is do the update in another image, making sure the changes all go into a single ChangeSet. Then you could file out the ChangeSet and apply it to your main image. That would at least ensure that the methods had the same timestamps and author initials... probably not a bad idea if it works easily enough. Julian On Tue, Jan 12, 2010 at 4:00 PM, Nick Ager wrote: > Hi Julian, > I'm probably missing something, but with Pier-Squeak-Persistency being > renamed to Pier-Pharo-Persistency in the pier2 repository, I don't seem to > be able to get Monticello to provide me with useful merge information. > Presumably Monticello can't work out a common ancestor. Am I missing > something? > > It's a little academic as I've worked out what's changed by comparing > differences in versions in the 2.8 Pier trunk - there's a new > method?PRKernel>>exportOn which has been extracted from the body > of?PRExportImportWidget>>export. resulting in a trivial?merge > in?PRExportImportWidget>>export. > I'm holding off in case I've missed something enabling a link to be made > between the repositories again so that future merges won't be confused by my > impending changes, though I'm probably being too pedantic and should just > make the changes.... > Nick > > 2010/1/11 Julian Fitzell >> >> On Mon, Jan 11, 2010 at 9:41 AM, Nick Ager wrote: >> > Hi, >> > I've turned my attention to merging the latest code in the add-ons, >> > which >> > resulted in some questions: >> > * Pier-Blog - easy merge, no conflicts >> > * Pier-Book - 9 conflicts - the merge didn't look straight-forward so I >> > thought I'd leave it to someone with more intimate knowledge of the code >> > and >> > changes... >> > * Pier-LinkChecker - I couldn't find the trunk version of this package - >> > I >> > didn't spot it in pier or pieraddons repositories >> >> Hi Nick, >> >> I think I pulled that code out of some other package (security?). >> >> > * Pier-Pharo-Persistency - I couldn't find the trunk version. Is it a >> > rename >> > from Pier-Seaside-Persistency? >> >> I assume you mean Pier-Squeak-Persistency? >> >> > * Pier-Seaside-Persistency - I'm running under Pharo so I'll leave this >> > to >> > someone else. >> >> As above - it was renamed. If you look at the history for >> Pier-Pharo-Persistency, you'll see the first version says: >> >> -------------- >> Name: Pier-Pharo-Persistency-jf.1 >> Author: jf >> Time: 3 November 2009, 11:22:49 am >> UUID: f8aaec5e-e993-433c-9599-caf72beb50df >> Ancestors: >> >> Rename Pier-Squeak-Persistency to Pier-Pharo-Persistency >> -------------- >> >> The last version of Pier-Squeak-Persistency should say the same thing >> and should also be empty (since all the code was moved out of it). >> >> Julian >> _______________________________________________ >> 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 > From nick.ager at gmail.com Wed Jan 13 10:12:33 2010 From: nick.ager at gmail.com (Nick Ager) Date: Wed, 13 Jan 2010 09:12:33 +0000 Subject: seaside 3.0, blog, book, link-checker and persistence In-Reply-To: <4a5dbd431001121722h60ccaeecjd05388fb9d9f3a5f@mail.gmail.com> References: <3a06f76f1001110941w73bd8dd0iff1b2fea27326d63@mail.gmail.com> <4a5dbd431001111041l6cfd964egc90519f2b23f8cb@mail.gmail.com> <3a06f76f1001121600s764ae6fbu47ad6de222576197@mail.gmail.com> <4a5dbd431001121722h60ccaeecjd05388fb9d9f3a5f@mail.gmail.com> Message-ID: <3a06f76f1001130112m32695497pf69b5860862a2b85@mail.gmail.com> > > The other thing you could do is do the update in another image, making > sure the changes all go into a single ChangeSet. Then you could file > out the ChangeSet and apply it to your main image. That would at least > ensure that the methods had the same timestamps and author initials... > probably not a bad idea if it works easily enough. > > OK merged with ChangeSet and committed to the repository. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Wed Jan 13 10:33:50 2010 From: nick.ager at gmail.com (Nick Ager) Date: Wed, 13 Jan 2010 09:33:50 +0000 Subject: Pier-Documents and Pier-EditorEnh Message-ID: <3a06f76f1001130133x7ccaf70bncb647749ffb2db45@mail.gmail.com> I've saved an initial port of Pier-Documents and Pier-EditorEnh for Seaside 3.0 to the pier2 repository. I've focused on making essential changes to ensure that the packages work on Seaside 3.0, rather than all the changes necessary for the packages to work in other dialects. One of the changes I made was to remove the image caching as: | cache | cache := #(nil) beMutable. (cache at: 1) isNil ifTrue: [ cache at: 1 put: #(137 80 78 ... ^ cache at: 1 becomes: ^ #(137 80 78 ... rational: beMutable is no longer defined and the change appeared to be inline with changes made to images elsewhere. Be careful if you're trying to diff in MC, I found that MC disappeared into a processing back-hole when I tried to diff PRHaloScripts>>haloPng BTW I don't understand the original caching code, but am intrigued by it. Is it explained anywhere? Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Wed Jan 13 14:12:44 2010 From: nick.ager at gmail.com (Nick Ager) Date: Wed, 13 Jan 2010 13:12:44 +0000 Subject: Pier-Setup change report (Pier 1 & 2) In-Reply-To: <89dhun$i2o76@smtp.pt.lu> References: <3a06f76f1001110440g7a5b8845v473617f24044d41b@mail.gmail.com> <4a5dbd431001111033n618fdcc1lca9543b51b6cf63a@mail.gmail.com> <67628d691001111437u7be814ccj908e96adade36ba1@mail.gmail.com> <3a06f76f1001111652t5fe4a11ambfbcb7a2e2ba0da3@mail.gmail.com> <67628d691001112335q17b26871l612a839ed68d3bc0@mail.gmail.com> <3a06f76f1001120224l6ce1c25ap6fab0c6fa37eb152@mail.gmail.com> <67628d691001120259l2c62c89fs59efbbb3fd373532@mail.gmail.com> <89dhun$hvkhj@smtp.pt.lu> <67628d691001120425x48f46e54md5eae522e3a94ec9@mail.gmail.com> <89dhun$i2o76@smtp.pt.lu> Message-ID: <3a06f76f1001130512j74e24b94q7a9882eeb5964009@mail.gmail.com> I've added Pier-Setup to the pier2 repository, allowing me to commit a change to the package which fixes the bug Reza reported below: > An open (Seaside 3.0 ??) issue: > ---------------------------------------------- > When hot switching distributions via the Design Chooser interface in the > Home page, the following call sequences raises an exception: > > WAApplication (WARegistry) >> urlFor:ifAbsent: > WAApplication (WARequestHandler) >> url > WADispatcher >> urlFor: > WADispatcher >> nameOfHandler: > > However, by forcing the navigator to point to http://localhost:8080/pier, > the new distribution is launched and seems fully operational. > > Cheers, > Reza > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfitzell at gmail.com Wed Jan 13 18:29:21 2010 From: jfitzell at gmail.com (Julian Fitzell) Date: Wed, 13 Jan 2010 09:29:21 -0800 Subject: Pier-Documents and Pier-EditorEnh In-Reply-To: <3a06f76f1001130133x7ccaf70bncb647749ffb2db45@mail.gmail.com> References: <3a06f76f1001130133x7ccaf70bncb647749ffb2db45@mail.gmail.com> Message-ID: <4a5dbd431001130929p428ce205rf93364f13b2d5f7f@mail.gmail.com> It's just creating a one element literal array, which gets a slot in the CompiledMethod. Then it says, actually I want that literal to be mutable, and sets the value of the first element to what it wants to cache. Bit ugly, what? :) Julian On Wed, Jan 13, 2010 at 1:33 AM, Nick Ager wrote: > I've saved an initial port of Pier-Documents and Pier-EditorEnh for Seaside > 3.0 to the pier2 repository. I've focused on making essential changes to > ensure that the packages work on Seaside 3.0, rather than all the changes > necessary for the packages to work in other dialects. > One of the changes I made was to remove the image caching as: > | cache | > cache := #(nil) beMutable. > (cache at: 1) isNil ifTrue: [ > cache at:??1 put: #(137 80 78 ... > ?? ? ? ?^ cache at: 1 > becomes: > ?^ #(137 80 78 ... > rational: beMutable is no longer defined and the change appeared to be > inline with changes made to images elsewhere. > Be careful if you're trying to diff in MC, I found that MC disappeared into > a processing back-hole when I tried to diff PRHaloScripts>>haloPng > BTW I don't understand the original caching code, but am intrigued by it. Is > it explained anywhere? > Nick > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > From nick.ager at gmail.com Fri Jan 15 13:24:19 2010 From: nick.ager at gmail.com (Nick Ager) Date: Fri, 15 Jan 2010 12:24:19 +0000 Subject: printString => greaseString => asJavascript Message-ID: <3a06f76f1001150424r1e3223eauf2f3c0879c6d8aec@mail.gmail.com> I've changed code in a couple of methods, where the code within a method generating javascript output has changed from: id printString to: id greaseString The problem arises as the string is no longer surrounded by single quote marks, resulting incorrect javascript. The methods effected are: Pier-EditorEnh PRChangeCommand>>updateRoot Pier-Documents PRDocumentWidget>>renderEditOn: My initial fix was to simply add the single double quote as: PRDocumentWidget >>renderEditOn: html "Pier on Seaside 2.8" | id | self halt. html textArea value: self text; class: 'wiki-inline'; id: (id := html nextId); callback: [ :value | self text: value ]; onKeyUp: 'pier_document_widget_update(' , id printString , ')'. self session addLoadScript: 'pier_document_widget_register(' , id printString , ')' becomes: renderEditOn: html "Pier on Seaside 3.0" | id | self halt. html textArea value: self text; class: 'wiki-inline'; id: (id := html nextId); callback: [ :value | self text: value ]; onKeyUp: 'pier_document_widget_update(''' , id greaseString , ''')'. html document addLoadScript: 'pier_document_widget_register(''' , id greaseString , ''')' However examining the code which executes when printString is called I noticed that it also escapes any quote marks in the string passed. On reflection I found the method asJavascript which appears to do the right thing. I've removed my extra speech marks, changed greaseString to asJavascript, and tested and all appears functional again. Have I found the right method? -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Fri Jan 15 13:29:58 2010 From: renggli at gmail.com (Lukas Renggli) Date: Fri, 15 Jan 2010 13:29:58 +0100 Subject: printString => greaseString => asJavascript In-Reply-To: <3a06f76f1001150424r1e3223eauf2f3c0879c6d8aec@mail.gmail.com> References: <3a06f76f1001150424r1e3223eauf2f3c0879c6d8aec@mail.gmail.com> Message-ID: <67628d691001150429t7e4cee59h13305a2aa66e01b@mail.gmail.com> > However examining the code which executes when printString is called I > noticed that it also escapes any quote marks in the string passed. On > reflection I found the method asJavascript which appears to do the right > thing. I've removed my extra speech marks, changed greaseString to > asJavascript, and tested and all appears functional again. Have I found the > right method? Yes, #asJavascript is the right method. Lukas -- Lukas Renggli http://www.lukas-renggli.ch From nick.ager at gmail.com Fri Jan 15 15:09:32 2010 From: nick.ager at gmail.com (Nick Ager) Date: Fri, 15 Jan 2010 14:09:32 +0000 Subject: stylesheet edit rendering problem on pier port to seaside 3.0 Message-ID: <3a06f76f1001150609n1d1016f7ub79219c74fd321b1@mail.gmail.com> Hi Lukas, Apologies for repeating myself, but I'm still not sure how to solve this problem, or why you don't see it... Reiterating; does this test assert on your machine?: | stylesheetFile stylesheetContents rendererResult | stylesheetContents := '/* a style sheet */'. stylesheetFile := (PRFile named: 'defaultCss') filename: 'style.css'; mimetype: 'text/css'; contents: stylesheetContents. rendererResult := WARenderCanvas builder render: [ :html | html render: stylesheetFile file contents]. self assert: rendererResult = stylesheetContents To reproduce the problem with Pier, register a Pier instance with: PRPierFrame registerAsApplication: 'pier' kernel: (PRKernel new root: (PRPage new title: 'test title'; contents: 'Pier on Seaside 3.0'; name: 'testPage'); name: 'testKernel'). browse to: http://localhost:8080/pier/environment/style.css, results in: #[47 42 32 98 108 117 101 112 114 105 110 ... Any more thoughts? Nick 2010/1/12 Nick Ager > I've tried to encapsulate the problem in a test: > > | stylesheetFile stylesheetContents rendererResult | > stylesheetContents := '/* a style sheet */'. > stylesheetFile := (PRFile named: 'defaultCss') filename: 'style.css'; > mimetype: 'text/css'; contents: stylesheetContents. > rendererResult := WARenderCanvas builder render: [ :html | > html render: stylesheetFile file contents]. > self assert: rendererResult = stylesheetContents > > In my image the assertion fails. If I change ByteArray>>greaseString to > return self displayString the assertion succeeds. > > Does that help? > > > 2010/1/12 Julian Fitzell > > I'm seeing the same as Nick, fwiw. Same if I try to edit the stylesheet. >> >> Julian >> >> On Tue, Jan 12, 2010 at 2:59 AM, Lukas Renggli wrote: >> > #[100 101 98 117 103 103 105 110 103], but this method is never called >> > when I browse Pier. >> > >> > Lukas >> > >> > >> > 2010/1/12 Nick Ager : >> >> Hi Lukas, >> >> Don't think the browse cache is the problem. What do you get with: >> >> #[100 101 98 117 103 103 105 110 103] greaseString >> >> on my image the result: >> >> '#[100 101 98 117 103 103 105 110 103]' >> >> >> >> 2010/1/12 Lukas Renggli >> >>> >> >>> > Does your the implementation of >> >>> > ByteArray>>greaseString match this: >> >>> > ByteArray>>greaseString >> >>> > "ByteArrays should not automatically be converted to Strings. You >> should >> >>> > use >> >>> > a GRCodec for this." >> >>> > ^ self printString >> >>> >> >>> Yes. >> >>> >> >>> > or does your image have an implementation of ByteArray>>encodeOn? >> >>> >> >>> No. >> >>> >> >>> Maybe you should clear your browser caches? >> >>> >> >>> Lukas >> >>> >> >>> > 2010/1/11 Lukas Renggli >> >>> >> >> >>> >> Has this been fixed, because it works here? >> >>> >> >> >>> >> Lukas >> >>> >> >> >>> >> 2010/1/11 Julian Fitzell : >> >>> >> > Maybe we need to implement #encodeOn: on ByteArray? Lukas? >> >>> >> > >> >>> >> > Julian >> >>> >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Fri Jan 15 15:55:46 2010 From: renggli at gmail.com (Lukas Renggli) Date: Fri, 15 Jan 2010 15:55:46 +0100 Subject: stylesheet edit rendering problem on pier port to seaside 3.0 In-Reply-To: <3a06f76f1001150609n1d1016f7ub79219c74fd321b1@mail.gmail.com> References: <3a06f76f1001150609n1d1016f7ub79219c74fd321b1@mail.gmail.com> Message-ID: <67628d691001150655h41d6ee77u70ce20a46cb2f664@mail.gmail.com> > Apologies for repeating myself, but I'm still not sure how to solve this > problem, or why you don't see it... No problem. > Reiterating; does this test assert on your machine?: > | stylesheetFile stylesheetContents rendererResult | > stylesheetContents := '/* a style sheet */'. > stylesheetFile := (PRFile named: 'defaultCss') filename: 'style.css'; > mimetype: 'text/css'; contents: stylesheetContents. > rendererResult := WARenderCanvas builder render: [ :html | > html ?render: stylesheetFile file contents]. > self assert: rendererResult = stylesheetContents This test does not pass in my image either. I don't see where such code would be used though? File (and thus CSS files) are certainly not fed through a HTML canvas. If you download a Pier 2 image from my build server you see that the stylesheets are properly served, I don't see any problems there. > To reproduce the problem with Pier, register a Pier instance with: > PRPierFrame registerAsApplication: 'pier' kernel: (PRKernel new root: > (PRPage new title: 'test title'; contents: 'Pier on Seaside 3.0'; name: > 'testPage'); name: 'testKernel'). > browse to:?http://localhost:8080/pier/environment/style.css,?results in: > #[47 42 32 98 108 117 101 112 114 105 110 ... > Any more thoughts? Aha, that I can reproduce. I fixed it in the latest commit. Note that #greaseString should probably not be used everywhere. #asString is in the ANSI standard defined on Character, String, ByteArray, and other sequenceable collections; so in some cases that might be the appropriate choice. Lukas -- Lukas Renggli http://www.lukas-renggli.ch From nick.ager at gmail.com Fri Jan 15 16:33:03 2010 From: nick.ager at gmail.com (Nick Ager) Date: Fri, 15 Jan 2010 15:33:03 +0000 Subject: stylesheet edit rendering problem on pier port to seaside 3.0 In-Reply-To: <67628d691001150655h41d6ee77u70ce20a46cb2f664@mail.gmail.com> References: <3a06f76f1001150609n1d1016f7ub79219c74fd321b1@mail.gmail.com> <67628d691001150655h41d6ee77u70ce20a46cb2f664@mail.gmail.com> Message-ID: <3a06f76f1001150733o6f4d9461yf45b2d916a66e233@mail.gmail.com> Fantastic that we've finally got to the bottom of this one, also my test code no longer asserts when the code is changed to match your changes. So the rendering code becomes: html render: stylesheetFile contents > This test does not pass in my image either. I don't see where such > code would be used though? File (and thus CSS files) are certainly not > fed through a HTML canvas. The test was my attempt at condensing the pertinent code relating to the problem. I'm fairly sure the code has a good correspondence with the code path used when you browse to: http://localhost:8080/pier/environment/style.css, but as ever I might have missed something -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Fri Jan 15 17:39:54 2010 From: renggli at gmail.com (Lukas Renggli) Date: Fri, 15 Jan 2010 17:39:54 +0100 Subject: stylesheet edit rendering problem on pier port to seaside 3.0 In-Reply-To: <3a06f76f1001150733o6f4d9461yf45b2d916a66e233@mail.gmail.com> References: <3a06f76f1001150609n1d1016f7ub79219c74fd321b1@mail.gmail.com> <67628d691001150655h41d6ee77u70ce20a46cb2f664@mail.gmail.com> <3a06f76f1001150733o6f4d9461yf45b2d916a66e233@mail.gmail.com> Message-ID: <67628d691001150839x5136f198s73eaa98b58a2b8bf@mail.gmail.com> >> This test does not pass in my image either. I don't see where such >> code would be used though? File (and thus CSS files) are certainly not >> fed through a HTML canvas. > > The test was my attempt at condensing the pertinent code relating to the > problem. I'm fairly sure the code has a good correspondence with the code > path used when you browse to: > ?http://localhost:8080/pier/environment/style.css, but as ever I might have > missed something It was a misunderstanding from my side. I was only checking how Seaside served the file, not how the file is displayed in Pier in case the structure is browsed or edited. Lukas -- Lukas Renggli http://www.lukas-renggli.ch From jfitzell at gmail.com Sat Jan 16 08:40:54 2010 From: jfitzell at gmail.com (Julian Fitzell) Date: Fri, 15 Jan 2010 23:40:54 -0800 Subject: stylesheet edit rendering problem on pier port to seaside 3.0 In-Reply-To: <67628d691001150655h41d6ee77u70ce20a46cb2f664@mail.gmail.com> References: <3a06f76f1001150609n1d1016f7ub79219c74fd321b1@mail.gmail.com> <67628d691001150655h41d6ee77u70ce20a46cb2f664@mail.gmail.com> Message-ID: <4a5dbd431001152340t3fa4acd8saa28cc02bf577931@mail.gmail.com> On Fri, Jan 15, 2010 at 6:55 AM, Lukas Renggli wrote: > Note that #greaseString should probably not be used everywhere. > #asString is in the ANSI standard defined on Character, String, > ByteArray, and other sequenceable collections; so in some cases that > might be the appropriate choice. Sure, though shouldn't we make sure that #greaseString calles #asString for those classes? Seems more straightforward... Julian From nick.ager at gmail.com Mon Jan 18 12:43:36 2010 From: nick.ager at gmail.com (Nick Ager) Date: Mon, 18 Jan 2010 11:43:36 +0000 Subject: project based pier Message-ID: <3a06f76f1001180343s1128e273xb18c7f1abe279d51@mail.gmail.com> Hi, I'm investigating using Pier to develop a site where registered users can have one or more associated projects. These projects should be bookmarkable. A good analogy would be the projects in squeaksource. Using that analogy how would one go about developing something like squeaksource in pier? Would the page structure expand as users registered new projects? For example: root |--- home |--- users |--- projects | |--- Announcements |--- Gofer |--- Helvetica . . |--- Pier | --- Wiki | --- Blog | --- News | --- Versions | --- Latest where each of the projects includes it's own sub-pages; wiki/blog/news/versions/latest etc. As the number of projects grew, would using Pier like this cause any memory/performance issues? Any other thoughts for how to structure a site of this type. Thanks Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.berth at googlemail.com Mon Jan 18 16:32:44 2010 From: matthias.berth at googlemail.com (Matthias Berth) Date: Mon, 18 Jan 2010 16:32:44 +0100 Subject: project based pier In-Reply-To: <3a06f76f1001180343s1128e273xb18c7f1abe279d51@mail.gmail.com> References: <3a06f76f1001180343s1128e273xb18c7f1abe279d51@mail.gmail.com> Message-ID: <9aa6ae271001180732q4ad53562ma1660f242dcbb44d@mail.gmail.com> Hi, lets try to keep it as simple as possible, maybe you can just ask more questions if things are too simplistic. Doing SqueakSource in Pier, the simple way: - Each project would be a PRPage, with Wiki, Blog, News etc as children - For Blog you would use PierBlog - You implement a command (say, CreateProject, subclass of PRCommand) that adds a preconfigured set of pages (Wiki, Blog, News) to a project. - You restrict / modify the set of available commands inside a project page - You use PierUnixSecurity for users, access rights etc. - More specialized pages like Versions would perhaps be a custom subclass of PRStructure that displays itself in a special way (overriding renderContentOn:) Regarding memory / performance: I don't have real experience with this, but as long as everything fits in main memory you should be fine. Regarding persistence: you can use the Pier image-based persistency (some package in Lukas' monticello repository). That saves the whole image after executing commands (using a condition on the frequency of the saving, e.g,. at most every hour). If you are thinking about combining Pier with some other persistency mechanism (we've done Sandstone recently) things get more involved. In any case, I'd make a list of what going with Pier buys me in terms of saved development effort -- in comparison to doing it using basic seaside only. I guess that's what you're doing at the moment anyway ;-) HTH Matthias On Mon, Jan 18, 2010 at 12:43 PM, Nick Ager wrote: > Hi, > I'm investigating using Pier to develop a site where registered users can > have one or more associated projects. These projects should be bookmarkable. > A good analogy would be the projects in squeaksource. Using that analogy how > would one go about developing something like squeaksource in pier? Would the > page structure expand as users registered new projects? For example: > root > ?|--- home > ?|--- users > ?|--- projects > ?? ? ? | > ?? ? ? |--- Announcements > ?? ? ? |--- Gofer > ?? ? ? |--- Helvetica > ?? ? ? . > ?? ? ? . > ?? ? ? |--- Pier > ?? ? ? ? ? ? | --- Wiki > ?? ? ? ? ? ? | --- Blog > ?? ? ? ? ? ? | --- News > ?? ? ? ? ? ? | --- Versions > ?? ? ? ? ? ? | --- Latest > where each of the projects includes it's own sub-pages; > wiki/blog/news/versions/latest etc. > As the number of projects grew, would using Pier like this cause any > memory/performance issues? Any other thoughts for how to structure a site of > this type. > Thanks > Nick > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > From renggli at gmail.com Mon Jan 18 18:07:35 2010 From: renggli at gmail.com (Lukas Renggli) Date: Mon, 18 Jan 2010 18:07:35 +0100 Subject: project based pier In-Reply-To: <3a06f76f1001180343s1128e273xb18c7f1abe279d51@mail.gmail.com> References: <3a06f76f1001180343s1128e273xb18c7f1abe279d51@mail.gmail.com> Message-ID: <67628d691001180907j641c5cd4h6bc2490dbd857b24@mail.gmail.com> > I'm investigating using Pier to develop a site where registered users can > have one or more associated projects. These projects should be bookmarkable. > A good analogy would be the projects in squeaksource. Using that analogy how > would one go about developing something like squeaksource in pier? Would the > page structure expand as users registered new projects? As I probably reported several times in the past, I've used Pier quite extensively for a software engineering course here at the university. At the beginning of the course the students register online at http://ese.unibe.ch (registration is now closed). They get subscribed to a mailing list and a page where they are the one one with access is created. They can use it as their "home-page". Later on in the course the students are put into groups and every group gets a sub-tree to manage their project. Some pages are public to everybody, some pages are visible or editable to certain student groups only, some pages are visible or editable by staff only, etc. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From nick.ager at gmail.com Mon Jan 18 20:14:28 2010 From: nick.ager at gmail.com (Nick Ager) Date: Mon, 18 Jan 2010 19:14:28 +0000 Subject: project based pier In-Reply-To: <67628d691001180907j641c5cd4h6bc2490dbd857b24@mail.gmail.com> References: <3a06f76f1001180343s1128e273xb18c7f1abe279d51@mail.gmail.com> <67628d691001180907j641c5cd4h6bc2490dbd857b24@mail.gmail.com> Message-ID: <3a06f76f1001181114kefd0652o3cebe266e158af48@mail.gmail.com> Thanks for the replies, they've clarified my thinking and helped me formulate my real question :-) Continuing with squeaksource as an example, in a hypothetical simplified implementation it might use a model consisting of a collection of projects & users. Each project would contain a list of packages with each package having a list of package versions. With my limited knowledge of Pier a couple of implementations seem possible: 1) Create a Pier hierarchy of pages which mirror the model and potentially duplicate the data within it 2) Use the Pier page hierarchy as the model 3) Use the model to dynamically create Pier pages during a request. As I see it there are problems with all three approaches: Solution (1) duplications data, with all the inherent issues around synchronising the two object hierarchies Solution (2) mixes model and view. Solution (3) also mixes the model and view and would seem to subvert the intention and elegancy of Pier. Perhaps the solution is to mix Pier and a more 'traditional' seaside approach, where the view would reflect off the model when the data is well structured, and Pier components would be used in places where the content is more free-form. However this implementation would seem complex as the URL handling will be shared between Pier and 'traditional' seaside components. For example /projects/gofer/wiki/anotherpage would split the URL handling between the model handling the '/projects/gofer/wiki and Pier handling wiki/anotherpage. Also the data would potential reside in two places - the Pier kernel and the model - though my understanding of how pier persists it's data is still at the very early stages. Hope this makes sense. Any thoughts? Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Mon Jan 18 20:42:23 2010 From: renggli at gmail.com (Lukas Renggli) Date: Mon, 18 Jan 2010 20:42:23 +0100 Subject: project based pier In-Reply-To: <3a06f76f1001181114kefd0652o3cebe266e158af48@mail.gmail.com> References: <3a06f76f1001180343s1128e273xb18c7f1abe279d51@mail.gmail.com> <67628d691001180907j641c5cd4h6bc2490dbd857b24@mail.gmail.com> <3a06f76f1001181114kefd0652o3cebe266e158af48@mail.gmail.com> Message-ID: <67628d691001181142i584f30bek4d7dd860eee022f1@mail.gmail.com> > 1) Create a Pier hierarchy of pages which mirror the model and potentially > duplicate the data within it That's a limitation of the Pier structure hierarchy, it is a tree. Btw, the structure is the name for different kinds of pages, such as blogs, files, pages, components, etc. > 2) Use the Pier page hierarchy as the model You can do that. Pier internally models most of its things like that because they naturally fit into a tree. This is not a requirement though, you can easily have an independent model and reference it from your structures. > 3) Use the model to dynamically create Pier pages during a request. That could probably be done, but Pier is not really designed to support that. It would require some significant work on the Pier side I assume. > Solution (2) mixes model and view. I don't see why this mixes model and view? - Model: PRStructure and subclasses + some external code - Controller: PRCommand and subclasses + some external code - View: PRViewComponent and subclasses + some external code (Seaside mostly) In you case you would just add your own model classes to your own PRStructure subclasses that somehow interoperate with your model. Lukas -- Lukas Renggli http://www.lukas-renggli.ch From nick.ager at gmail.com Mon Jan 18 22:34:08 2010 From: nick.ager at gmail.com (Nick Ager) Date: Mon, 18 Jan 2010 21:34:08 +0000 Subject: project based pier In-Reply-To: <67628d691001181142i584f30bek4d7dd860eee022f1@mail.gmail.com> References: <3a06f76f1001180343s1128e273xb18c7f1abe279d51@mail.gmail.com> <67628d691001180907j641c5cd4h6bc2490dbd857b24@mail.gmail.com> <3a06f76f1001181114kefd0652o3cebe266e158af48@mail.gmail.com> <67628d691001181142i584f30bek4d7dd860eee022f1@mail.gmail.com> Message-ID: <3a06f76f1001181334s9e21379xb92c15a3baf1e458@mail.gmail.com> > > > Solution (2) mixes model and view. > > I don't see why this mixes model and view? > > - Model: PRStructure and subclasses + some external code > - Controller: PRCommand and subclasses + some external code > - View: PRViewComponent and subclasses + some external code (Seaside > mostly) > > In you case you would just add your own model classes to your own > PRStructure subclasses that somehow interoperate with your model. Thanks for the clarification. If I've understood correctly, the best way to go is to subclass PRStructure for my model classes so that the model objects can be used directly by Pier, otherwise I'd end up having a duplicate Pier structure mirroring my model objects. The disadvantage of this is that the framework infects my classes; using Java terminology they are no longer POJOs [1], or have I missed something? Would the combined approach, I attempted to outline in the previous message be overly complex to implement? I can image that splitting the url handling, and model between two structures could require lots of patching before they interoperate successfully. [1] http://en.wikipedia.org/wiki/Plain_Old_Java_Object -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Mon Jan 18 22:54:03 2010 From: renggli at gmail.com (Lukas Renggli) Date: Mon, 18 Jan 2010 22:54:03 +0100 Subject: project based pier In-Reply-To: <3a06f76f1001181334s9e21379xb92c15a3baf1e458@mail.gmail.com> References: <3a06f76f1001180343s1128e273xb18c7f1abe279d51@mail.gmail.com> <67628d691001180907j641c5cd4h6bc2490dbd857b24@mail.gmail.com> <3a06f76f1001181114kefd0652o3cebe266e158af48@mail.gmail.com> <67628d691001181142i584f30bek4d7dd860eee022f1@mail.gmail.com> <3a06f76f1001181334s9e21379xb92c15a3baf1e458@mail.gmail.com> Message-ID: <67628d691001181354m3f57cb33g294617c411128d21@mail.gmail.com> > Thanks for the clarification. If I've understood correctly, the best way to > go is to subclass PRStructure for my model classes so that the model objects > can be used directly by Pier, otherwise I'd end up having a duplicate Pier > structure mirroring my model objects. The disadvantage of this is that the > framework infects my classes; using Java terminology they are no longer > POJOs [1], or have I missed something? PRStructure and subclasses is the model for the hierarchical structure of Pier. If your model is anything beyond the simple hierarchal folder and file structure of Pier, I wouldn't implement it as a subclass of PRStructure. For example, when you have the typical and highly interconnected University, Student, Professor, Course, Exam kind of model; I would implement all these classes separately from Pier. And then you have different structure subclasses that delegate to your complex domain model. So you'd probably had a - a university structure that would delegate to one University - a person structure, that would delegate to one Student or Professor - a course structure, that would delegate to one Course and the exams in that course Does that make sense? Another alternative is that you do not work with PRStructures at all, for example if you don't need the URLs. Then you can simply create your own model and your own plain Seaside app and embed it into Pier at some place (or use it independently from Pier). Lukas -- Lukas Renggli http://www.lukas-renggli.ch From razavi at acm.org Mon Jan 18 23:46:45 2010 From: razavi at acm.org (Reza RAZAVI) Date: Mon, 18 Jan 2010 23:46:45 +0100 Subject: project based pier In-Reply-To: <3a06f76f1001181114kefd0652o3cebe266e158af48@mail.gmail.com > References: <3a06f76f1001180343s1128e273xb18c7f1abe279d51@mail.gmail.com> <67628d691001180907j641c5cd4h6bc2490dbd857b24@mail.gmail.com> <3a06f76f1001181114kefd0652o3cebe266e158af48@mail.gmail.com> Message-ID: <8bbtuf$mpi4m@smtp.pt.lu> At 20:14 18/01/2010, Nick Ager wrote: >1) Create a Pier hierarchy of pages which mirror the model and >potentially duplicate the data within it >2) Use the Pier page hierarchy as the model >3) Use the model to dynamically create Pier pages during a request. Hi Nick, I'm developing a system where Pier is successfully used following an approach which is close to (1), but there is no duplicated code/data, etc. ) To keep the analogy with MVC, I use Pier as View & Controller, but not as Model. The PRStructure hierarchy is used as an "organization" medium for parts of my business model that need visualization and user interaction. The latter are implemented by PRViewComponens (WAComponents). With your approach (2) there is indeed a risque of mixing model and view, but all depends on your application domain. As already stated by Lukas, if your business model elements "naturally fit into a tree", then it would probably be "natural" to adopt this approach. I won't recommend the 3rd approach since inconsistent with the design of Pier, and unnecessarily complicated. Hoping this helps, Regards, Reza From nick.ager at gmail.com Mon Jan 18 23:52:08 2010 From: nick.ager at gmail.com (Nick Ager) Date: Mon, 18 Jan 2010 22:52:08 +0000 Subject: project based pier In-Reply-To: <67628d691001181354m3f57cb33g294617c411128d21@mail.gmail.com> References: <3a06f76f1001180343s1128e273xb18c7f1abe279d51@mail.gmail.com> <67628d691001180907j641c5cd4h6bc2490dbd857b24@mail.gmail.com> <3a06f76f1001181114kefd0652o3cebe266e158af48@mail.gmail.com> <67628d691001181142i584f30bek4d7dd860eee022f1@mail.gmail.com> <3a06f76f1001181334s9e21379xb92c15a3baf1e458@mail.gmail.com> <67628d691001181354m3f57cb33g294617c411128d21@mail.gmail.com> Message-ID: <3a06f76f1001181452q37632ea1la9384662de7c5e84@mail.gmail.com> > > For example, when you have the typical and highly interconnected > University, Student, Professor, Course, Exam kind of model; I would > implement all these classes separately from Pier. And then you have > different structure subclasses that delegate to your complex domain > model. So you'd probably had a > > - a university structure that would delegate to one University > - a person structure, that would delegate to one Student or Professor > - a course structure, that would delegate to one Course and the > exams in that course > Thanks again for the help. I understand the delegate model, but I'm still concerned about the inherent duplication of the delegates mirroring the model objects. In your example wouldn't there be collections of custom Pier structures so that there would be at least one Pier structure for each University, Student, course and exam, assuming that it was possible to use Pier to navigate to each of the model objects. Perhaps this is a non-issue, but I'd be concerned about keeping the delegates and delegees in sync. Would combining the approaches work? The opening pages would use Pier to allow easy updating, however links to courses, students, exams etc would use procedural navigation code feeding off the model, and finally Pier could be used within the leaf nodes to allow courses, students etc to have wiki structured content. Ideally all bookmarkable, and the model would capture the wiki content created at the leaf nodes. Perhaps I'm making it more complicated then it needs to be? -------------- next part -------------- An HTML attachment was scrubbed... URL: From keith_hodges at yahoo.co.uk Wed Jan 20 02:05:36 2010 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Wed, 20 Jan 2010 01:05:36 +0000 Subject: Any Progress on the multi-lingual Pier Message-ID: <4B5656E0.4040902@yahoo.co.uk> Hi folks, Was any progress made on this? Keith From nick.ager at gmail.com Thu Jan 21 16:10:49 2010 From: nick.ager at gmail.com (Nick Ager) Date: Thu, 21 Jan 2010 15:10:49 +0000 Subject: PRSearchView Message-ID: <3a06f76f1001210710l2d45e84ah46277735d2b2484f@mail.gmail.com> Hi, PRSearchView raises an exception once the form is submitted. The problem is that in the #refresh method the call to "self context" returns nil, so the following fails: searcher := self context root fullTextSearch. Investigating the problem I noticed that it's immediate super class PRViewComponent implements #setContext: and context and the more distant superclass WAPresenter implements #context: context. I fixed the problem locally by adding "self setContext: PRCurrentContext value.", before the call to "self context" and I see search results, but it feels more like a hack than a fix. Some thoughts: * Does PRViewComponent store context for performance, if I removed these methods (setContext: & #context) the search would function without my change. * There seems to be a naming inconsistency with #setContext: & #context: Any thoughts? Nick PS Thanks again for the all the help - I *really* appreciate it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Thu Jan 21 18:08:55 2010 From: renggli at gmail.com (Lukas Renggli) Date: Thu, 21 Jan 2010 18:08:55 +0100 Subject: PRSearchView In-Reply-To: <3a06f76f1001210710l2d45e84ah46277735d2b2484f@mail.gmail.com> References: <3a06f76f1001210710l2d45e84ah46277735d2b2484f@mail.gmail.com> Message-ID: <67628d691001210908p4348f28dte31459759d38cf1b@mail.gmail.com> > PRSearchView raises an exception once the form is submitted. The problem is > that in the #refresh method the call to "self context" returns nil, so the > following fails: > searcher := self context root fullTextSearch. > Investigating the problem I noticed that it's immediate super class > PRViewComponent implements ?#setContext: and context and the more distant > superclass WAPresenter implements #context: context. > I fixed the problem locally by adding "self setContext: PRCurrentContext > value.", before the call to "self context" and I see search results, but it > feels more like a hack than a fix. Some thoughts: > * Does PRViewComponent store context for performance, if I removed these > methods (setContext: & #context)?the search would function without my > change. > * There seems to be a naming?inconsistency with?#setContext: & #context: > Any thoughts? Strange. I cannot reproduce that problem in the latest builds of the Seaside 3.0/Pier image. Lukas -- Lukas Renggli http://www.lukas-renggli.ch From nick.ager at gmail.com Thu Jan 21 23:46:31 2010 From: nick.ager at gmail.com (Nick Ager) Date: Thu, 21 Jan 2010 22:46:31 +0000 Subject: PRSearchView In-Reply-To: <67628d691001210908p4348f28dte31459759d38cf1b@mail.gmail.com> References: <3a06f76f1001210710l2d45e84ah46277735d2b2484f@mail.gmail.com> <67628d691001210908p4348f28dte31459759d38cf1b@mail.gmail.com> Message-ID: <3a06f76f1001211446t19809733mfd8fbfc1f7f77229@mail.gmail.com> > > Strange. I cannot reproduce that problem in the latest builds of the > Seaside 3.0/Pier image. > Sorry I should have included this the first mail. My steps to reproduce: * Download latest build from Hudson server, I used 21st Jan build at: http://hudson.lukas-renggli.ch/job/Seaside%203.0/lastSuccessfulBuild/artifact/pier2/pier2.image+ changes * Copy PharoV10.sources into download directory, start image and web server * Register a new Pier app as: PRPierFrame registerAsApplication: 'piersearch' kernel: (PRKernel new root: ((PRComponent named: 'search') componentClass: PRSearchView); name: 'testKernel'). * browse to localhost:8080/piersearch * type anything into the search box and press "search" * MessageNotUnderstood: receiver of "root" is nil Hope this makes sense Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From razavi at acm.org Fri Jan 22 02:33:41 2010 From: razavi at acm.org (Reza RAZAVI) Date: Fri, 22 Jan 2010 02:33:41 +0100 Subject: PRSearchView In-Reply-To: <3a06f76f1001211446t19809733mfd8fbfc1f7f77229@mail.gmail.co m> References: <3a06f76f1001210710l2d45e84ah46277735d2b2484f@mail.gmail.com> <67628d691001210908p4348f28dte31459759d38cf1b@mail.gmail.com> <3a06f76f1001211446t19809733mfd8fbfc1f7f77229@mail.gmail.com> Message-ID: <8bbtuf$ntllr@smtp.pt.lu> At 23:46 21/01/2010, Nick Ager wrote: >* Register a new Pier app as: >PRPierFrame registerAsApplication: 'piersearch' kernel: (PRKernel >new root: ((PRComponent named: 'search') componentClass: >PRSearchView); name: 'testKernel'). Nick, PRSearchView is a subclass of PRViewComponent, which expects to be instantiated with #on:, instead of #new. The argument to #on: is supposed to be aContext, which is then cached for later use by methods like #refresh. There is an example of such call in PRViewCommand >> viewComponent. The issue is related to the fact that in your case, PRSearchView is instantiated by #new. Here is the call sequence: PRPierFrame >> children PRPierFrame >> buildChildren PRPierFrame >> componentsOf: (PRComponent) PRStructure >> componentsIn: PRContext >> componentFor: PRContext >> buildComponent:for: PRComponent >> componentFor: PRSearchView class (WAComponent)>> owner:link: #owner:link: calls #new, instead of #on: Now, there are PRWidgets that don't cash the context, and can be instantiated by #new. Consequently, the above call sequence works just fine in their case. And, Pier standard distributions use PRAjaxSearchWidget instead of PRSearchView,, which is a kind of PRWidget. So, the following app should work: PRPierFrame registerAsApplication: 'piersearch' kernel: (PRKernel new root: ((PRComponent named: 'search') componentClass: PRAjaxSearchWidget); name: 'testKernel'). Hoping this helps, Regards, Reza From renggli at gmail.com Fri Jan 22 16:10:19 2010 From: renggli at gmail.com (Lukas Renggli) Date: Fri, 22 Jan 2010 16:10:19 +0100 Subject: PRSearchView In-Reply-To: <3a06f76f1001211446t19809733mfd8fbfc1f7f77229@mail.gmail.com> References: <3a06f76f1001210710l2d45e84ah46277735d2b2484f@mail.gmail.com> <67628d691001210908p4348f28dte31459759d38cf1b@mail.gmail.com> <3a06f76f1001211446t19809733mfd8fbfc1f7f77229@mail.gmail.com> Message-ID: <67628d691001220710q50660f8fk9138699cf65f52bb@mail.gmail.com> Ok, but the views are not supposed to be instantiated like this. You can display the views anywhere in Pier by clicking onto the Search menu item or by typing an URL like this: http://localhost:8080/pier?view=Search The views need to cache the context because they can be instantiated and used in a different context than the currently active one. Lukas 2010/1/21 Nick Ager : >> Strange. I cannot reproduce that problem in the latest builds of the >> Seaside 3.0/Pier image. > > Sorry I should have included this the first mail. My steps to reproduce: > * Download latest build from Hudson server, I used 21st Jan build at: > ?http://hudson.lukas-renggli.ch/job/Seaside%203.0/lastSuccessfulBuild/artifact/pier2/pier2.image > + ?changes > * Copy PharoV10.sources into download directory, start image and web server > * Register a new Pier app as: > PRPierFrame registerAsApplication: 'piersearch' kernel: (PRKernel new root: > ((PRComponent named: 'search') componentClass: PRSearchView); name: > 'testKernel'). > * browse to localhost:8080/piersearch > * type anything into the search box and press "search" > *?MessageNotUnderstood: receiver of "root" is nil > Hope this makes sense > Nick > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli http://www.lukas-renggli.ch From renggli at gmail.com Fri Jan 22 16:12:28 2010 From: renggli at gmail.com (Lukas Renggli) Date: Fri, 22 Jan 2010 16:12:28 +0100 Subject: PRSearchView In-Reply-To: <67628d691001220710q50660f8fk9138699cf65f52bb@mail.gmail.com> References: <3a06f76f1001210710l2d45e84ah46277735d2b2484f@mail.gmail.com> <67628d691001210908p4348f28dte31459759d38cf1b@mail.gmail.com> <3a06f76f1001211446t19809733mfd8fbfc1f7f77229@mail.gmail.com> <67628d691001220710q50660f8fk9138699cf65f52bb@mail.gmail.com> Message-ID: <67628d691001220712h3072f4dv42d30447ae3949ae@mail.gmail.com> Also note that the views should not be displayed in the edit dialog of the component from the web, unless you script it by hand and thus avoid the validation of Magritte. Lukas 2010/1/22 Lukas Renggli : > Ok, but the views are not supposed to be instantiated like this. > > You can display the views anywhere in Pier by clicking onto the Search > menu item or by typing an URL like this: > > ? http://localhost:8080/pier?view=Search > > The views need to cache the context because they can be instantiated > and used in a different context than the currently active one. > > Lukas > > > > > 2010/1/21 Nick Ager : >>> Strange. I cannot reproduce that problem in the latest builds of the >>> Seaside 3.0/Pier image. >> >> Sorry I should have included this the first mail. My steps to reproduce: >> * Download latest build from Hudson server, I used 21st Jan build at: >> ?http://hudson.lukas-renggli.ch/job/Seaside%203.0/lastSuccessfulBuild/artifact/pier2/pier2.image >> + ?changes >> * Copy PharoV10.sources into download directory, start image and web server >> * Register a new Pier app as: >> PRPierFrame registerAsApplication: 'piersearch' kernel: (PRKernel new root: >> ((PRComponent named: 'search') componentClass: PRSearchView); name: >> 'testKernel'). >> * browse to localhost:8080/piersearch >> * type anything into the search box and press "search" >> *?MessageNotUnderstood: receiver of "root" is nil >> Hope this makes sense >> Nick >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > -- Lukas Renggli http://www.lukas-renggli.ch From nick.ager at gmail.com Fri Jan 22 16:55:40 2010 From: nick.ager at gmail.com (Nick Ager) Date: Fri, 22 Jan 2010 15:55:40 +0000 Subject: PRSearchView In-Reply-To: <67628d691001220712h3072f4dv42d30447ae3949ae@mail.gmail.com> References: <3a06f76f1001210710l2d45e84ah46277735d2b2484f@mail.gmail.com> <67628d691001210908p4348f28dte31459759d38cf1b@mail.gmail.com> <3a06f76f1001211446t19809733mfd8fbfc1f7f77229@mail.gmail.com> <67628d691001220710q50660f8fk9138699cf65f52bb@mail.gmail.com> <67628d691001220712h3072f4dv42d30447ae3949ae@mail.gmail.com> Message-ID: <3a06f76f1001220755y5d9be8e0l8a8eace9072011e9@mail.gmail.com> Hi Lukas and Reza, Thanks for the explanations, it helps a lot to understand the intent of the code. Cheers Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From dale.henrichs at gemstone.com Sat Jan 23 01:15:34 2010 From: dale.henrichs at gemstone.com (Dale Henrichs) Date: Fri, 22 Jan 2010 16:15:34 -0800 (PST) Subject: Pier-Pharo-Persistency dependency on Pier-Model-Tests Message-ID: <237653056.1123711264205734221.JavaMail.root@gir> I'm building Metacello configurations for Pier2 (and Magritte2) and I've run into the fact that the tests for Pier-Pharo-Persistency are included in the package and that those tests depend upon Pier-Model-Tests. Since things have been repackaged for Pier2, it might make sense to split out the Pharo-persistency tests so that things can be loaded without tests. Of course, if this is intentional..."Never mind":) Dale From dale.henrichs at gemstone.com Sat Jan 23 01:19:19 2010 From: dale.henrichs at gemstone.com (Dale Henrichs) Date: Fri, 22 Jan 2010 16:19:19 -0800 (PST) Subject: Pier2 addons... Message-ID: <1775832006.1123741264205959392.JavaMail.root@gir> I'm also building a configuration for Pier addons and I'm curious which of the addons have been successfully ported to Pier2 ... I've seen that Pier-Blog is apparently working. Are there others? I'm just trying to give an accurate picture of the current Pier2 universe... Dale From renggli at gmail.com Sat Jan 23 01:58:00 2010 From: renggli at gmail.com (Lukas Renggli) Date: Sat, 23 Jan 2010 01:58:00 +0100 Subject: Pier-Pharo-Persistency dependency on Pier-Model-Tests In-Reply-To: <237653056.1123711264205734221.JavaMail.root@gir> References: <237653056.1123711264205734221.JavaMail.root@gir> Message-ID: <67628d691001221658t7d314490nc2df2598bf5aa6e0@mail.gmail.com> No, that's not intentional and should be split. In Pier 1 I was too lazy to have the tests of the extra packages separate and that has not been fixed jet in Pier 2. Lukas On Saturday, January 23, 2010, Dale Henrichs wrote: > I'm building Metacello configurations for Pier2 (and Magritte2) and I've run into the fact that the tests for Pier-Pharo-Persistency are included in the package and that those tests depend upon Pier-Model-Tests. > > Since things have been repackaged for Pier2, it might make sense to split out the Pharo-persistency tests so that things can be loaded without tests. > > Of course, if this is intentional..."Never mind":) > > Dale > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli http://www.lukas-renggli.ch From jfitzell at gmail.com Sat Jan 23 02:09:22 2010 From: jfitzell at gmail.com (Julian Fitzell) Date: Fri, 22 Jan 2010 17:09:22 -0800 Subject: Pier-Pharo-Persistency dependency on Pier-Model-Tests In-Reply-To: <67628d691001221658t7d314490nc2df2598bf5aa6e0@mail.gmail.com> References: <237653056.1123711264205734221.JavaMail.root@gir> <67628d691001221658t7d314490nc2df2598bf5aa6e0@mail.gmail.com> Message-ID: <4a5dbd431001221709x79132288m8daa89a6da7a7835@mail.gmail.com> And I didn't do anything other than the bare minimum with that package because I was being paid to make the port work for VA, not Pharo. :) The tests should definitely be split out. Julian On Fri, Jan 22, 2010 at 4:58 PM, Lukas Renggli wrote: > No, that's not intentional and should be split. In Pier 1 I was too > lazy to have the tests of the extra packages separate and that has not > been fixed jet in Pier 2. > > Lukas > > On Saturday, January 23, 2010, Dale Henrichs wrote: >> I'm building Metacello configurations for Pier2 (and Magritte2) and I've run into the fact that the tests for Pier-Pharo-Persistency are included in the package and that those tests depend upon Pier-Model-Tests. >> >> Since things have been repackaged for Pier2, it might make sense to split out the Pharo-persistency tests so that things can be loaded without tests. >> >> Of course, if this is intentional..."Never mind":) >> >> Dale >> _______________________________________________ >> 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 > From nick.ager at gmail.com Sat Jan 23 11:10:47 2010 From: nick.ager at gmail.com (Nick Ager) Date: Sat, 23 Jan 2010 10:10:47 +0000 Subject: Pier2 addons... In-Reply-To: <1775832006.1123741264205959392.JavaMail.root@gir> References: <1775832006.1123741264205959392.JavaMail.root@gir> Message-ID: <3a06f76f1001230210l7b545fddj97b6b208fe021902@mail.gmail.com> Hi Dale, Whatever is in http://source.lukas-renggli.ch/pier2 repository has been ported and should include all recent changes from the 2.8 repository ( http://source.lukas-renggli.ch/pier) and selective packages from the addons repository (http://source.lukas-renggli.ch/pieradons) . The one exception being the Pier-Book package which hasn't been merged with the latest trunk changes and AFAIK is a port of the book repository from early September. Lukas is using a Gofer script and Hudson to check Pier and Magritte load cleanly and monitor the tests - http://www.iam.unibe.ch/pipermail/smallwiki/2010-January/005492.html In addition to the "base" Pier installation I've loaded the following packages into my image successfully though I haven't thoroughly exercised them all. Packages labelled from "pieraddons" appear to work on Seaside 3.0 Pier without porting, the others labelled from "pier2" repository have been ported Pier-Blog (pier2) Pier-Design (pieraddons) Pier-Documents(pier2) Pier-EditorEnh(pier2) Pier-Google(pieraddons) Pier-LightBox(pieraddons) Pier-Links(pieraddons) Pier-Randomizer(pieraddons) Pier-Scriptaculous(pieraddons) Pier-Setup(pier2) Pier-Titles(pieraddons) Pier-Twitter(pieraddons) Pier-TagCloud (pieraddons) More info: http://www.iam.unibe.ch/pipermail/smallwiki/2010-January/005513.html http://www.iam.unibe.ch/pipermail/smallwiki/2010-January/005533.html Nick 2010/1/23 Dale Henrichs > I'm also building a configuration for Pier addons and I'm curious which of > the addons have been successfully ported to Pier2 ... > > I've seen that Pier-Blog is apparently working. Are there others? > > I'm just trying to give an accurate picture of the current Pier2 > universe... > > Dale > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dale.henrichs at gemstone.com Sat Jan 23 19:46:42 2010 From: dale.henrichs at gemstone.com (Dale Henrichs) Date: Sat, 23 Jan 2010 10:46:42 -0800 (PST) Subject: Pier2 addons... In-Reply-To: <3a06f76f1001230210l7b545fddj97b6b208fe021902@mail.gmail.com> Message-ID: <111421227.1126621264272402879.JavaMail.root@gir> Nick, Excellent info...I'll include them in the configuration...thanks! Dale ----- "Nick Ager" wrote: | Hi Dale, | | Whatever is in http://source.lukas-renggli.ch/pier2 repository has | been | ported and should include all recent changes from the 2.8 repository | ( | http://source.lukas-renggli.ch/pier) and selective packages from the | addons | repository (http://source.lukas-renggli.ch/pieradons) . The one | exception | being the Pier-Book package which hasn't been merged with the latest | trunk | changes and AFAIK is a port of the book repository from early | September. | | Lukas is using a Gofer script and Hudson to check Pier and Magritte | load | cleanly and monitor the tests - | http://www.iam.unibe.ch/pipermail/smallwiki/2010-January/005492.html | | In addition to the "base" Pier installation I've loaded the following | packages into my image successfully though I haven't thoroughly | exercised | them all. Packages labelled from "pieraddons" appear to work on | Seaside 3.0 | Pier without porting, the others labelled from "pier2" repository have | been | ported | | Pier-Blog (pier2) | Pier-Design (pieraddons) | Pier-Documents(pier2) | Pier-EditorEnh(pier2) | Pier-Google(pieraddons) | Pier-LightBox(pieraddons) | Pier-Links(pieraddons) | Pier-Randomizer(pieraddons) | Pier-Scriptaculous(pieraddons) | Pier-Setup(pier2) | Pier-Titles(pieraddons) | Pier-Twitter(pieraddons) | Pier-TagCloud (pieraddons) | | More info: | http://www.iam.unibe.ch/pipermail/smallwiki/2010-January/005513.html | http://www.iam.unibe.ch/pipermail/smallwiki/2010-January/005533.html | | Nick | | 2010/1/23 Dale Henrichs | | > I'm also building a configuration for Pier addons and I'm curious | which of | > the addons have been successfully ported to Pier2 ... | > | > I've seen that Pier-Blog is apparently working. Are there others? | > | > I'm just trying to give an accurate picture of the current Pier2 | > universe... | > | > Dale | > _______________________________________________ | > Magritte, Pier and Related Tools ... | > https://www.iam.unibe.ch/mailman/listinfo/smallwiki | > From razavi at acm.org Sat Jan 23 20:36:57 2010 From: razavi at acm.org (Reza RAZAVI) Date: Sat, 23 Jan 2010 20:36:57 +0100 Subject: Pier2 addons... In-Reply-To: <3a06f76f1001230210l7b545fddj97b6b208fe021902@mail.gmail.co m> References: <1775832006.1123741264205959392.JavaMail.root@gir> <3a06f76f1001230210l7b545fddj97b6b208fe021902@mail.gmail.com> Message-ID: <8bbtuf$ocrhm@smtp.pt.lu> At 11:10 23/01/2010, Nick Ager wrote: >The one exception being the Pier-Book package which hasn't been >merged with the latest trunk changes and AFAIK is a port of the book >repository from early September. I'm using the Book package from Pier1 addons repository (http://source.lukas-renggli.ch/pieradons) with a Pier2 image. No specific issues to report till now. /Reza From merlyn at stonehenge.com Sun Jan 24 05:37:18 2010 From: merlyn at stonehenge.com (Randal L. Schwartz) Date: Sat, 23 Jan 2010 20:37:18 -0800 Subject: pier2? Message-ID: <867hr8azk1.fsf@blue.stonehenge.com> Did I miss an announcement? Does this mean we have a Pier that works (or nearly works) with Seaside 3? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion From renggli at gmail.com Sun Jan 24 09:41:33 2010 From: renggli at gmail.com (Lukas Renggli) Date: Sun, 24 Jan 2010 09:41:33 +0100 Subject: pier2? In-Reply-To: <867hr8azk1.fsf@blue.stonehenge.com> References: <867hr8azk1.fsf@blue.stonehenge.com> Message-ID: <67628d691001240041i48863ac2l890c63787006e698@mail.gmail.com> > Did I miss an announcement? ?Does this mean we have a Pier that works > (or nearly works) with Seaside 3? Yes, it works thanks to the hard work of Julian, Nick and various other people. As far as I know there are no bugs. There are daily builds at . And Dale made a Metacello definition at , I have not tested that one myself though. Actually there is a Seaside 3.0 one-click image with Pier 2 preloaded. I've put that one on the website because it is required for the book: http://www.seaside.st/distributions/Seaside-3.0a5.app.zip Lukas -- Lukas Renggli http://www.lukas-renggli.ch From dale.henrichs at gemstone.com Mon Jan 25 04:56:05 2010 From: dale.henrichs at gemstone.com (Dale Henrichs) Date: Sun, 24 Jan 2010 19:56:05 -0800 (PST) Subject: pier2? In-Reply-To: <67628d691001240041i48863ac2l890c63787006e698@mail.gmail.com> Message-ID: <1724558160.1136041264391765892.JavaMail.root@gir> I need to update the Pier2 addons configuration and then I'll push out Metacello configs for Magritte2, Pier2 and PierAddOns2 and a ConfigurationForSeaside that provides "one stop shopping" for Seaside2.8, Magritte, Pier, Seaside3.0, Magritte2, and Pier2 ... Dale ----- "Lukas Renggli" wrote: | > Did I miss an announcement? ?Does this mean we have a Pier that | works | > (or nearly works) with Seaside 3? | | Yes, it works thanks to the hard work of Julian, Nick and various | other people. | | As far as I know there are no bugs. There are daily builds at | . And Dale made a | Metacello definition at , I | have not tested that one myself though. | | Actually there is a Seaside 3.0 one-click image with Pier 2 | preloaded. | I've put that one on the website because it is required for the book: | | http://www.seaside.st/distributions/Seaside-3.0a5.app.zip | | Lukas | | -- | Lukas Renggli | http://www.lukas-renggli.ch | | _______________________________________________ | Magritte, Pier and Related Tools ... | https://www.iam.unibe.ch/mailman/listinfo/smallwiki From nick.ager at gmail.com Mon Jan 25 11:24:15 2010 From: nick.ager at gmail.com (Nick Ager) Date: Mon, 25 Jan 2010 10:24:15 +0000 Subject: uft-8 MAFileModelHandler Message-ID: <3a06f76f1001250224r534ace87xae50cdb8aeabf0a8@mail.gmail.com> In Pier on Seaside 3, if I use a utf-8 encoded Comanche Adapter, I receive a walkback "MNU: ByteArray>>isByteString" The error is generated from: GRPharoUtf8CodecStream>>nextPutAll nextPutAll: aString binary ifTrue: [ stream nextPutAll: aString asString ] ifFalse: [ aString isByteString ifTrue: [ self encodeFast: aString ] ifFalse: [ self encodeDefault: aString ] ] while trying to serve "style.css" which originates from: PRStructure>>defaultEnvironment ^ (PRPage named: 'environment') addChild: ((PRFile named: 'style.css') filename: 'style.css'; mimetype: 'text/css'; contents: '/* blueprint patches */........ To reproduce: 1 Download the one-click 3.0a5 release from seaside.st 2 Select utf-8 encoding on the WAComancheAdapter (right click within Seaside Control Panel -> Encoding...) 3 Browse to localhost:8080/pier There seem to be a number of places where a fix could be made, but I'm not sure which (if any) would be the most appropriate: * MAFileModelHandler>>handleFiltered - the GRPharoUtf8CodecStream response stream is created, without utf-8 encoding, a GRNullCodecStream is created instead. * PRFile>>contents: perhaps PRFile shouldn't always convert the contents to a ByteArray * Perhaps ByteArray should implement isByteString. Any thoughts? Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippe.marschall at gmail.com Mon Jan 25 14:14:10 2010 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Mon, 25 Jan 2010 14:14:10 +0100 Subject: uft-8 MAFileModelHandler In-Reply-To: <3a06f76f1001250224r534ace87xae50cdb8aeabf0a8@mail.gmail.com> References: <3a06f76f1001250224r534ace87xae50cdb8aeabf0a8@mail.gmail.com> Message-ID: <66666f211001250514l7d8a0c6che53cf6e916cc9e33@mail.gmail.com> 2010/1/25 Nick Ager : > In Pier on Seaside 3, if I use a utf-8 encoded Comanche Adapter, I receive a > walkback "MNU: ByteArray>>isByteString" Nice. IMO the way to go is that Pier puts the response stream into binary mode before pushing binary content. Cheers Philippe From lists at dcorking.com Mon Jan 25 18:13:57 2010 From: lists at dcorking.com (David Corking) Date: Mon, 25 Jan 2010 17:13:57 +0000 Subject: Pier user data stored in filesystem was Re: [squeak-dev] Cuis Message-ID: On Mon, Jan 25, 2010 at 4:25 PM, keith wrote (on the squeak-dev list) : > pier keeps its data in image. I know the following info is unlikely to help your current application, but, in the interest of completeness, I will observe that at least one Pier application stores its user data in the host filesystem, not the image. That application is WikiServer (John McIntosh's cross-platform personal wiki for the iPhone) I only have superficial familiarity with Pier and WikiServer: as far as I can tell, the persistency code uses MAExternalFileModel, but sadly I can't guess if the effect is available to all Pier developers, or proprietary to WikiServer. From nick.ager at gmail.com Mon Jan 25 18:18:38 2010 From: nick.ager at gmail.com (Nick Ager) Date: Mon, 25 Jan 2010 17:18:38 +0000 Subject: PRAjaxSearchWidget not working on Seaside3 Message-ID: <3a06f76f1001250918h45c9eb3cyd8ee8ac13694d73a@mail.gmail.com> Hi, PRAjaxSearchWidget does not return any results using the latest Seaside3/Pier2 packages Steps to reproduce * download latest build from: http://hudson.lukas-renggli.ch/job/Seaside%203.0/ * open and start web server * open a workspace and execute: PRPierFrame registerAsApplication: 'pier' kernel: (PRKernel named: 'defaultKernel'). * type something into the search box, observe the XHR request/responses; the text typed is being sent, however no results are returned. The problem seems to be that the textInput callback is not called, however I noticed that the callback in SUAutocompleterTest is also never called. By mimicking the code in SUAutocompleterTest I have a local working version of PRAjaxSearchWidget, with the following changes: Old version: PRAjaxSearchWidget>>renderContentOn: .... html scriptaculous autocompleter ... on: #renderItemsOn: of: self modified version: PRAjaxSearchWidget>>renderContentOn: .... html scriptaculous autocompleter ... on: #renderItemsOn:for: of: self Old version: PRAjaxSearchWidget>>renderItemsOn: html html unorderedList: [ self items do: [ :each | html listItem passenger: each; " the only difference to the original " with: [ self renderItem: each on: html ] ] ] Modified version: PRAjaxSearchWidget>>renderItemsOn: html for: aString self searchText: aString. html unorderedList: [ self items do: [ :each | html listItem passenger: each; " the only difference to the original " with: [ self renderItem: each on: html ] ] ] If the above changes make sense, I'll push them into the repository. Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Mon Jan 25 19:04:59 2010 From: renggli at gmail.com (Lukas Renggli) Date: Mon, 25 Jan 2010 19:04:59 +0100 Subject: Pier user data stored in filesystem was Re: [squeak-dev] Cuis In-Reply-To: References: Message-ID: <67628d691001251004k4c949f37md5cfcd119b127469@mail.gmail.com> > I only have superficial familiarity with Pier and WikiServer: ?as far > as I can tell, the persistency code uses MAExternalFileModel, but > sadly I can't guess if the effect is available to all Pier developers, > or proprietary to WikiServer. All uploaded files are handled externally to the image using MAExternalFileModel, unless you changed the default to use MAInternalFileModel. This is part of Magritte and has been in use for many years already. These file-models are only used by Pier for uploaded files though. MAExternalFileModel essentially models a ByteArray that is external to the image and that can be served through Apache. I don't think that MAExternalFileModel is useful to persist the rest of the Pier model, but there are always surprises :-) Lukas -- Lukas Renggli http://www.lukas-renggli.ch From johnmci at smalltalkconsulting.com Mon Jan 25 19:45:42 2010 From: johnmci at smalltalkconsulting.com (John M McIntosh) Date: Mon, 25 Jan 2010 10:45:42 -0800 Subject: Pier user data stored in filesystem was Re: [squeak-dev] Cuis In-Reply-To: References: Message-ID: Well I should read all the email first. the source code can be looked at by following the links from http://www.mobilewikiserver.com/1.4.html and getting the desktop version. No magic is involved, it's just an object fileout of the Pier root. There are some changes to the object file out logic to uses a buffered UTF8 stream and a few minor changes in the object to serialization logic for performance reasons. Thus the file out runs in 50% of the time that it normally would. No doubt using the Squeak buffered multi-byte stream change would achieve mostly the same thing. I'd like to convert this to image segments, as soon as someone figures out a rational subset of that missing all the etoy & project cruft. On 2010-01-25, at 9:13 AM, David Corking wrote: > I only have superficial familiarity with Pier and WikiServer: as far > as I can tell, the persistency code uses MAExternalFileModel, but > sadly I can't guess if the effect is available to all Pier developers, > or proprietary to WikiServer. > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- =========================================================================== John M. McIntosh Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== From merlyn at stonehenge.com Tue Jan 26 23:15:49 2010 From: merlyn at stonehenge.com (Randal L. Schwartz) Date: Tue, 26 Jan 2010 14:15:49 -0800 Subject: pier2? In-Reply-To: <67628d691001240041i48863ac2l890c63787006e698@mail.gmail.com> (Lukas Renggli's message of "Sun, 24 Jan 2010 09:41:33 +0100") References: <867hr8azk1.fsf@blue.stonehenge.com> <67628d691001240041i48863ac2l890c63787006e698@mail.gmail.com> Message-ID: <86vdeo342y.fsf@blue.stonehenge.com> >>>>> "Lukas" == Lukas Renggli writes: Lukas> As far as I know there are no bugs. There are daily builds at Lukas> . And Dale made a Lukas> Metacello definition at , I Lukas> have not tested that one myself though. So this is my first time using MetaCello, and it looks like to bootstrap it from Squeak Trunk, I have to go into the Monticello Browser GUI, and pick the latest package of ConfigurationOfMetacello manually. Is there any way to automate all of this in some sort of "doit"? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion From miguel.coba at gmail.com Tue Jan 26 23:27:53 2010 From: miguel.coba at gmail.com (Miguel Enrique =?ISO-8859-1?Q?Cob=E1?= Martinez) Date: Tue, 26 Jan 2010 16:27:53 -0600 Subject: pier2? In-Reply-To: <86vdeo342y.fsf@blue.stonehenge.com> References: <867hr8azk1.fsf@blue.stonehenge.com> <67628d691001240041i48863ac2l890c63787006e698@mail.gmail.com> <86vdeo342y.fsf@blue.stonehenge.com> Message-ID: <1264544873.2410.5.camel@laptop.localdomain> El mar, 26-01-2010 a las 14:15 -0800, Randal L. Schwartz escribi?: > >>>>> "Lukas" == Lukas Renggli writes: > > Lukas> As far as I know there are no bugs. There are daily builds at > Lukas> . And Dale made a > Lukas> Metacello definition at , I > Lukas> have not tested that one myself though. > > So this is my first time using MetaCello, and it looks like to > bootstrap it from Squeak Trunk, I have to go into the Monticello > Browser GUI, and pick the latest package of ConfigurationOfMetacello > manually. > > Is there any way to automate all of this in some sort of "doit"? No way unless squeak trunk includes Gofer as part of the image. Gofer is used to bootstrap metacello. With gofer installed in the image (or by monticello browser in source.lukas-renggli.ch/gofer) evaluate: Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfMetacello'; load. (Smalltalk at: #ConfigurationOfMetacello) perform: #loadLatestVersion Cheers > -- Miguel Cob? http://miguel.leugim.com.mx From merlyn at stonehenge.com Tue Jan 26 23:31:01 2010 From: merlyn at stonehenge.com (Randal L. Schwartz) Date: Tue, 26 Jan 2010 14:31:01 -0800 Subject: pier2? In-Reply-To: <1264544873.2410.5.camel@laptop.localdomain> (Miguel Enrique =?iso-8859-1?Q?Cob=E1?= Martinez's message of "Tue, 26 Jan 2010 16:27:53 -0600") References: <867hr8azk1.fsf@blue.stonehenge.com> <67628d691001240041i48863ac2l890c63787006e698@mail.gmail.com> <86vdeo342y.fsf@blue.stonehenge.com> <1264544873.2410.5.camel@laptop.localdomain> Message-ID: <86r5pc33dm.fsf@blue.stonehenge.com> >>>>> "Miguel" == Miguel Enrique Cob? Martinez writes: Miguel> No way unless squeak trunk includes Gofer as part of the image. If Gofer is ready for primetime, it should be in Squeak trunk by now. Is there any reason not to include it? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion From miguel.coba at gmail.com Tue Jan 26 23:45:14 2010 From: miguel.coba at gmail.com (Miguel Enrique =?ISO-8859-1?Q?Cob=E1?= Martinez) Date: Tue, 26 Jan 2010 16:45:14 -0600 Subject: pier2? In-Reply-To: <86r5pc33dm.fsf@blue.stonehenge.com> References: <867hr8azk1.fsf@blue.stonehenge.com> <67628d691001240041i48863ac2l890c63787006e698@mail.gmail.com> <86vdeo342y.fsf@blue.stonehenge.com> <1264544873.2410.5.camel@laptop.localdomain> <86r5pc33dm.fsf@blue.stonehenge.com> Message-ID: <1264545914.2410.7.camel@laptop.localdomain> El mar, 26-01-2010 a las 14:31 -0800, Randal L. Schwartz escribi?: > >>>>> "Miguel" == Miguel Enrique Cob? Martinez writes: > > Miguel> No way unless squeak trunk includes Gofer as part of the image. > > If Gofer is ready for primetime, it should be in Squeak trunk by now. > > Is there any reason not to include it? > Yes, the developers of Gofer work in Pharo and nobody has proposed gofer to the squeak inbox. Other than that, Gofer is fueling all the Pharo 1.0 and Metacello 1.0 release since a couple of months full time. -- Miguel Cob? http://miguel.leugim.com.mx From dale.henrichs at gemstone.com Wed Jan 27 00:15:43 2010 From: dale.henrichs at gemstone.com (Dale Henrichs) Date: Tue, 26 Jan 2010 15:15:43 -0800 (PST) Subject: pier2? In-Reply-To: <1264545914.2410.7.camel@laptop.localdomain> Message-ID: <1594048074.1171371264547743104.JavaMail.root@gir> Randal, I have been making sure that Gofer runs on the squeak trunk and GemStone (for use with Metacello)... recently I found two test failures for Gofer on the Squeak trunk, but since the failures didn't affect operation of Metacello I haven't tried to characterize the problems ... nothing obvious was wrong otherwise I would have fixed them... Dale ----- "Miguel Enrique Cob? Martinez" wrote | El mar, 26-01-2010 a las 14:31 -0800, Randal L. Schwartz escribi?: | > >>>>> "Miguel" == Miguel Enrique Cob? Martinez | writes: | > | > Miguel> No way unless squeak trunk includes Gofer as part of the | image. | > | > If Gofer is ready for primetime, it should be in Squeak trunk by | now. | > | > Is there any reason not to include it? | > | Yes, the developers of Gofer work in Pharo and nobody has proposed | gofer | to the squeak inbox. | | Other than that, Gofer is fueling all the Pharo 1.0 and Metacello 1.0 | release since a couple of months full time. | | | -- | Miguel Cob? | http://miguel.leugim.com.mx | | _______________________________________________ | Magritte, Pier and Related Tools ... | https://www.iam.unibe.ch/mailman/listinfo/smallwiki From merlyn at stonehenge.com Wed Jan 27 02:16:39 2010 From: merlyn at stonehenge.com (Randal L. Schwartz) Date: Tue, 26 Jan 2010 17:16:39 -0800 Subject: pier2? In-Reply-To: <1264544873.2410.5.camel@laptop.localdomain> (Miguel Enrique =?iso-8859-1?Q?Cob=E1?= Martinez's message of "Tue, 26 Jan 2010 16:27:53 -0600") References: <867hr8azk1.fsf@blue.stonehenge.com> <67628d691001240041i48863ac2l890c63787006e698@mail.gmail.com> <86vdeo342y.fsf@blue.stonehenge.com> <1264544873.2410.5.camel@laptop.localdomain> Message-ID: <867hr4z6rs.fsf@blue.stonehenge.com> >>>>> "Miguel" == Miguel Enrique Cob? Martinez writes: Miguel> No way unless squeak trunk includes Gofer as part of the image. So this is the shortest Squeak-Trunk way to load Pier2, as a .cs file: (Installer ss project: 'MetacelloRepository') install: 'ConfigurationOfMetacello'; install: 'ConfigurationOfPier2'! ConfigurationOfMetacello loadLatestVersion! ConfigurationOfMetacello project latestVersion load: #('UI')! ConfigurationOfPier2 load! There might be a way to combine the second and third step, but this works. And loading the UI is needed for Pier2, apparently (?) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion From dale.henrichs at gemstone.com Wed Jan 27 02:33:52 2010 From: dale.henrichs at gemstone.com (Dale Henrichs) Date: Tue, 26 Jan 2010 17:33:52 -0800 (PST) Subject: ConfigurationOfSeaside available In-Reply-To: <151480772.1174341264555101807.JavaMail.root@gir> Message-ID: <919278502.1174771264556032498.JavaMail.root@gir> First load the configuration. For Pharo: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfSeaside'; load. For Squeak: - load the latest version of ConfigurationOfSeaside from http://www.squeaksource.com/MetacelloRepository Then pick the Seaside variant you want to load: "Seaside 2.8" ConfigurationOfSeaside project latestVersion load: 'Seaside 2.8'. ConfigurationOfSeaside project latestVersion load: 'Seaside 2.8 Examples'. ConfigurationOfSeaside project latestVersion load: 'Magritte'. ConfigurationOfSeaside project latestVersion load: 'Magritte Tests'. ConfigurationOfSeaside project latestVersion load: 'Pier'. ConfigurationOfSeaside project latestVersion load: 'Pier Tests'. ConfigurationOfSeaside project latestVersion load: 'Pier AddOns'. "Seaside 3.0" ConfigurationOfSeaside project latestVersion load: 'Seaside 3.0'. ConfigurationOfSeaside project latestVersion load: 'Seaside 3.0 Tests'. ConfigurationOfSeaside project latestVersion load: 'Magritte2'. ConfigurationOfSeaside project latestVersion load: 'Magritte2 Tests'. ConfigurationOfSeaside project latestVersion load: 'Pier2'. ConfigurationOfSeaside project latestVersion load: 'Pier2 Tests'. ConfigurationOfSeaside project latestVersion load: 'Pier2 AddOns'. I've tested the various loads with PharoCore-1.0-10508rc2 and Squeak3.11-8931-alpha. The tests aren't 100% green on either platform... Dale From andreas.raab at gmx.de Wed Jan 27 03:25:06 2010 From: andreas.raab at gmx.de (Andreas Raab) Date: Tue, 26 Jan 2010 18:25:06 -0800 Subject: pier2? In-Reply-To: <1264544873.2410.5.camel@laptop.localdomain> References: <867hr8azk1.fsf@blue.stonehenge.com> <67628d691001240041i48863ac2l890c63787006e698@mail.gmail.com> <86vdeo342y.fsf@blue.stonehenge.com> <1264544873.2410.5.camel@laptop.localdomain> Message-ID: <4B5FA402.8030607@gmx.de> Miguel Enrique Cob? Martinez wrote: > El mar, 26-01-2010 a las 14:15 -0800, Randal L. Schwartz escribi?: >> >> Is there any way to automate all of this in some sort of "doit"? > > No way unless squeak trunk includes Gofer as part of the image. Strange you should say that. I find the following in http://www.squeaksource.com/MetacelloRepository/ConfigurationOfSeaside-DaleHenrichs.12.mcz ensureMetacello "Bootstrap Gofer (if necessary), bootstrap ConfigurationOfMetacello (using old Gofer API), then load the latest version of Metacello itself." Smalltalk at: #MetacelloProject ifAbsent: [ Smalltalk at: #Gofer ifAbsent: [ "Current version of Gofer from which to bootstrap - as of 1.0-beta.21" self bootstrapPackage: 'Gofer-Core-lr.115' from: 'http://seaside.gemstone.com/ss/metacello' ]. Smalltalk at: #Gofer ifPresent: [:goferClass | | gofer | gofer := goferClass new url: 'http://seaside.gemstone.com/ss/metacello'; yourself. [ gofer addPackage: 'ConfigurationOfMetacello' ] on: Warning do: [:ex | ex resume ]. gofer load ]. "load 'default' group of Metacello" (Smalltalk at: #ConfigurationOfMetacello) perform: #load ]. This looks like it's loading Gofer automatically if not present. Cheers, - Andreas From mj93401 at gmail.com Wed Jan 27 03:29:58 2010 From: mj93401 at gmail.com (Mark Johnson) Date: Tue, 26 Jan 2010 18:29:58 -0800 (PST) Subject: Pier as (primarily) a Wiki Message-ID: <1264559398125-1311180.post@n4.nabble.com> I am a long-time Swiki administrator and user, but I am looking for a new wiki. I have a fondness for Smalltalk, too... I am a total newbie to Pier. I realize that Pier is much more than a wiki. I am having a tough time getting a grip on the Pier documentation... I would like to tweak a standard Pier installation so that it is a wiki with user logon/authentication and attribution. I don't need a blog or any of the other Pier features just yet. I would like to turn off the blog capability so as not to distract users. Can I do this with Pier? If not, is there another Squeak- or Pharo-based wiki with user authentication and attribution? Pointers to a HOWTO or starting point in the Pier docs appreciated. Thanks, Mark -- View this message in context: http://n4.nabble.com/Pier-as-primarily-a-Wiki-tp1311180p1311180.html Sent from the Magritte, Pier and Related Tools mailing list archive at Nabble.com. From dale.henrichs at gemstone.com Wed Jan 27 03:56:55 2010 From: dale.henrichs at gemstone.com (Dale Henrichs) Date: Tue, 26 Jan 2010 18:56:55 -0800 (PST) Subject: pier2? In-Reply-To: <4B5FA402.8030607@gmx.de> Message-ID: <2092794198.1175401264561015237.JavaMail.root@gir> Andreas, Gofer is just missing for the initial load of the Configuration itself... Dale ----- "Andreas Raab" wrote: | Miguel Enrique Cob? Martinez wrote: | > El mar, 26-01-2010 a las 14:15 -0800, Randal L. Schwartz escribi?: | >> | >> Is there any way to automate all of this in some sort of "doit"? | > | > No way unless squeak trunk includes Gofer as part of the image. | | Strange you should say that. I find the following in | http://www.squeaksource.com/MetacelloRepository/ConfigurationOfSeaside-DaleHenrichs.12.mcz | | ensureMetacello | "Bootstrap Gofer (if necessary), bootstrap ConfigurationOfMetacello | (using old Gofer API), then load the latest | version of Metacello itself." | | Smalltalk at: #MetacelloProject ifAbsent: [ | Smalltalk at: #Gofer ifAbsent: [ | "Current version of Gofer from which to bootstrap - as of | 1.0-beta.21" | self bootstrapPackage: 'Gofer-Core-lr.115' from: | 'http://seaside.gemstone.com/ss/metacello' ]. | Smalltalk at: #Gofer ifPresent: [:goferClass | | gofer | | gofer := goferClass new | url: 'http://seaside.gemstone.com/ss/metacello'; | yourself. | [ gofer addPackage: 'ConfigurationOfMetacello' ] on: Warning do: | [:ex | | ex resume ]. | gofer load ]. | "load 'default' group of Metacello" | (Smalltalk at: #ConfigurationOfMetacello) perform: #load ]. | | This looks like it's loading Gofer automatically if not present. | | Cheers, | - Andreas | | _______________________________________________ | Magritte, Pier and Related Tools ... | https://www.iam.unibe.ch/mailman/listinfo/smallwiki From renggli at gmail.com Wed Jan 27 08:30:39 2010 From: renggli at gmail.com (Lukas Renggli) Date: Wed, 27 Jan 2010 08:30:39 +0100 Subject: Pier as (primarily) a Wiki In-Reply-To: <1264559398125-1311180.post@n4.nabble.com> References: <1264559398125-1311180.post@n4.nabble.com> Message-ID: <67628d691001262330k59c300aaj919d69ffb5018cfb@mail.gmail.com> > Can I do this with Pier? Definitely. > Pointers to a HOWTO or starting point in the Pier docs appreciated. The one-click image (http://www.piercms.com) is probably a good starting point. It already has the authentication setup for you. You just need to log-in, change the default username and password and add a few more users. If you don't want the blog, you just delete that page. If you have any more questions feel free to ask. Lukas -- Lukas Renggli http://www.lukas-renggli.ch From renggli at gmail.com Wed Jan 27 08:33:35 2010 From: renggli at gmail.com (Lukas Renggli) Date: Wed, 27 Jan 2010 08:33:35 +0100 Subject: pier2? In-Reply-To: <1594048074.1171371264547743104.JavaMail.root@gir> References: <1264545914.2410.7.camel@laptop.localdomain> <1594048074.1171371264547743104.JavaMail.root@gir> Message-ID: <67628d691001262333ve74d75dx1378c63707ed82ca@mail.gmail.com> > I have been making sure that Gofer runs on the squeak trunk and GemStone (for use with Metacello)... recently I found two test failures for Gofer on the Squeak trunk, but since the failures didn't affect operation of Metacello I haven't tried to characterize the problems ... nothing obvious was wrong otherwise I would have fixed them... What tests do fail? If this is the crap with the subdirectories repositories I am tempted to remove it altogether. I don't think anybody depends on that. Lukas -- Lukas Renggli http://www.lukas-renggli.ch From renggli at gmail.com Wed Jan 27 14:49:56 2010 From: renggli at gmail.com (Lukas Renggli) Date: Wed, 27 Jan 2010 14:49:56 +0100 Subject: [ANN] PDF of Dynamic Web Development with Seaside Message-ID: <67628d691001270549i5506c1d0yca2a5e6c32e38294@mail.gmail.com> The PDF version of the book "Dynamic Web Development with Seaside" is available for download now: http://book.seaside.st/book/introduction/pdf-book At the end of the payment process (PayPal) you will be redirected to the download area where you are able to get the latest builds of the PDF version of the book. If you bookmark the page you will be able to download fixes and extra chapters as we integrate them into the online version. By buying the PDF version you support our hard work on the book. We wish to thank the European Smalltalk User Group (ESUG), inceptive.be, Cincom Smalltalk and GemStone Smalltalk for generously sponsoring this book. We are looking for additional sponsors. If you are interested, please contact us. If you are a publisher and interested in publishing this material, please let us know. Please distribute this message widely. Cheers, Stef & Lukas -- Lukas Renggli http://www.lukas-renggli.ch From nick.ager at gmail.com Wed Jan 27 16:10:29 2010 From: nick.ager at gmail.com (Nick Ager) Date: Wed, 27 Jan 2010 15:10:29 +0000 Subject: new bug: unable to use Pier UI to add components -> bug in grouped select Message-ID: <3a06f76f1001270710y6473a86ey90d13a4fe4d71992@mail.gmail.com> Hi Yesterday I rebuilt my image using the latest Metacello ConfigurationOfSeaside30 (loadLatestVersion) and the latest code in Pier2 and Magritte2 repositories. I've noticed a new problem when I attempt to add a component using the Pier web ui which results in a form validation error: 'Component Class: Invalid input given' To reproduce: * download latest build from: http://hudson.lukas-renggli.ch/job/Seaside%203.0/ * open and start web server * open a workspace and execute: PRPierFrame registerAsApplication: 'pier' kernel: (PRKernel named: 'defaultKernel'). * browse to http://localhost:8080/pier and select the edit link * type: '+acomponent+' into the text in the box and press 'save' * click on the 'acomponent' link and in the type select list choose 'Component' and press 'Add' * select any class from the 'Component Class' select list and press 'save' * note the form validation error: "Component Class: Invalid input given" Investigation: * MAKindError is being generated as the component selected is always WAComponent regardless of the user selection. * WAComponent is the default value ; the selected value is not being set as the callback in MASelectListComponent>>renderOption:on: is never called. This appears to be a Seaside bug; it appears that the callbacks for a grouped select list are not called on form submission. Further investigation: * using the latest build browse to http://localhost:8080/magritte/editor * select a type other than 'Boolean' from the grouped select box eg choose 'File' and press Add * notice that whatever type you choose 'Boolean' is always selected. * place a 'self halt' in the callback in MASelectListComponent>>renderOption:on: and notice that it is never called. I noticed that there have been bug fixes on the select tag: http://lists.squeakfoundation.org/pipermail/seaside/2010-January/022358.html I made sure that the build I was using had the latest Seaside-Canvas (Seaside-Canvas-lr.88.mcz). My previous image with working grouped selection list was based on Seaside-Canvas-pmm.74.mcz Hope I'm not reporting something that has already been fixed or noticed elsewhere Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Wed Jan 27 18:28:57 2010 From: nick.ager at gmail.com (Nick Ager) Date: Wed, 27 Jan 2010 17:28:57 +0000 Subject: PRAjaxSearchWidget not working on Seaside3 In-Reply-To: <3a06f76f1001250918h45c9eb3cyd8ee8ac13694d73a@mail.gmail.com> References: <3a06f76f1001250918h45c9eb3cyd8ee8ac13694d73a@mail.gmail.com> Message-ID: <3a06f76f1001270928j23bd95afx6ea3f63e5dfb0bf7@mail.gmail.com> I've updated Pier-Seaside in Pier2 repository with these changes. Shout if that doesn't make sense. Nick 2010/1/25 Nick Ager > Hi, > PRAjaxSearchWidget does not return any results using the latest > Seaside3/Pier2 packages > > Steps to reproduce > * download latest build from: > http://hudson.lukas-renggli.ch/job/Seaside%203.0/ > * open and start web > server > * open a workspace and execute: > PRPierFrame registerAsApplication: 'pier' kernel: (PRKernel named: > 'defaultKernel'). > * type something into the search box, observe the XHR request/responses; > the text typed is being sent, however no results are returned. > > The problem seems to be that the textInput callback is not called, however > I noticed that the callback in SUAutocompleterTest is also never called. > By mimicking the code in SUAutocompleterTest I have a local working version > of PRAjaxSearchWidget, with the following changes: > > Old version: > PRAjaxSearchWidget>>renderContentOn: > .... html scriptaculous autocompleter ... on: #renderItemsOn: of: self > > modified version: > PRAjaxSearchWidget>>renderContentOn: > .... html scriptaculous autocompleter ... on: #renderItemsOn:for: of: > self > > Old version: > PRAjaxSearchWidget>>renderItemsOn: html > html unorderedList: [ > self items do: [ :each | > html listItem > passenger: each; " the only difference to the original " > with: [ self renderItem: each on: html ] ] ] > > Modified version: > PRAjaxSearchWidget>>renderItemsOn: html for: aString > self searchText: aString. > > html unorderedList: [ > self items do: [ :each | > html listItem > passenger: each; " the only difference to the original " > with: [ self renderItem: each on: html ] ] ] > > If the above changes make sense, I'll push them into the repository. > > Nick > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mj93401 at gmail.com Wed Jan 27 19:49:22 2010 From: mj93401 at gmail.com (Mark Johnson) Date: Wed, 27 Jan 2010 10:49:22 -0800 Subject: Pier as (primarily) a Wiki In-Reply-To: <67628d691001262330k59c300aaj919d69ffb5018cfb@mail.gmail.com> References: <1264559398125-1311180.post@n4.nabble.com> <67628d691001262330k59c300aaj919d69ffb5018cfb@mail.gmail.com> Message-ID: Thanks, Lukas! I already have the one-click up and running. After logging in as admin/pier, if I click "Wiki", I get a plain text page that reads: "This is the main page of the official Pier distribution. Before you can modify this site, you have to login using: admin/pier. If you are not satisfied with the current look, perhaps you want to choose another one: +/environment/designchooser+ Have fun,

The Pier Team" I *was* able to remove Blog from environment/menu. I am happy to "RTFM" about enabling a Wiki but I'm not sure where to begin reading. Thanks, Mark On Tue, Jan 26, 2010 at 11:30 PM, Lukas Renggli wrote: >> Can I do this with Pier? > > Definitely. > >> Pointers to a HOWTO or starting point in the Pier docs appreciated. > > The one-click image (http://www.piercms.com) is probably a good > starting point. It already has the authentication setup for you. You > just need to log-in, change the default username and password and add > a few more users. If you don't want the blog, you just delete that > page. > > If you have any more questions feel free to ask. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > From dale.henrichs at gemstone.com Wed Jan 27 19:55:18 2010 From: dale.henrichs at gemstone.com (Dale Henrichs) Date: Wed, 27 Jan 2010 10:55:18 -0800 (PST) Subject: pier2?...squeak errors for Gofer In-Reply-To: <726599248.1190211264618426844.JavaMail.root@gir> Message-ID: <1963878706.1190281264618518262.JavaMail.root@gir> Squeak3.10.2-Trunk-090912: GoferOperationTest>>testRevert: GoferBar class not restored during revert (goferFoo class restored correctly). From my initial look it may be a bug (or difference in behavior) in Monticello. GoferOperationTest>>testReinitialize: MethodReference>>selector not present in Squeak ... perhaps #methodSymbol should be used... Dale ----- "Lukas Renggli" wrote: | > I have been making sure that Gofer runs on the squeak trunk and | GemStone (for use with Metacello)... recently I found two test | failures for Gofer on the Squeak trunk, but since the failures didn't | affect operation of Metacello I haven't tried to characterize the | problems ... nothing obvious was wrong otherwise I would have fixed | them... | | What tests do fail? | | If this is the crap with the subdirectories repositories I am tempted | to remove it altogether. I don't think anybody depends on that. | | Lukas | | -- | Lukas Renggli | http://www.lukas-renggli.ch | | _______________________________________________ | Magritte, Pier and Related Tools ... | https://www.iam.unibe.ch/mailman/listinfo/smallwiki From renggli at gmail.com Wed Jan 27 20:29:44 2010 From: renggli at gmail.com (Lukas Renggli) Date: Wed, 27 Jan 2010 20:29:44 +0100 Subject: pier2?...squeak errors for Gofer In-Reply-To: <1963878706.1190281264618518262.JavaMail.root@gir> References: <726599248.1190211264618426844.JavaMail.root@gir> <1963878706.1190281264618518262.JavaMail.root@gir> Message-ID: <67628d691001271129hd15de2fi89cf15ea12afe34b@mail.gmail.com> > ?GoferOperationTest>>testReinitialize: > ?MethodReference>>selector not present in Squeak ... perhaps #methodSymbol should be used... Yeah, that makes sense. Lukas > > Dale > ----- "Lukas Renggli" wrote: > > | > I have been making sure that Gofer runs on the squeak trunk and > | GemStone (for use with Metacello)... recently I found two test > | failures for Gofer on the Squeak trunk, but since the failures didn't > | affect operation of Metacello I haven't tried to characterize the > | problems ... nothing obvious was wrong otherwise I would have fixed > | them... > | > | What tests do fail? > | > | If this is the crap with the subdirectories repositories I am tempted > | to remove it altogether. I don't think anybody depends on that. > | > | 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 From tudor.girba at gmail.com Thu Jan 28 01:18:20 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Thu, 28 Jan 2010 01:18:20 +0100 Subject: Pier as (primarily) a Wiki In-Reply-To: References: <1264559398125-1311180.post@n4.nabble.com> <67628d691001262330k59c300aaj919d69ffb5018cfb@mail.gmail.com> Message-ID: <7EDA1D43-3935-400A-AB95-F5CFB36FBFDB@gmail.com> Hi Mark, You already are in a wiki :). I believe what you want is to setup the "template" (called environment in Pier) to put the commands to edit or login more prominently. You can get some answers on the faq page. In particular: http://www.piercms.com/doc/faq#45138032 Cheers, Doru On 27 Jan 2010, at 19:49, Mark Johnson wrote: > Thanks, Lukas! > > I already have the one-click up and running. After logging in as > admin/pier, if I click "Wiki", I get a plain text page that reads: > > "This is the main page of the official Pier distribution. Before you > can modify this site, you have to login using: admin/pier. > > If you are not satisfied with the current look, perhaps you want to > choose another one: > > +/environment/designchooser+ > > Have fun,

> The Pier Team" > > I *was* able to remove Blog from environment/menu. > > I am happy to "RTFM" about enabling a Wiki but I'm not sure where to > begin reading. > > Thanks, > Mark > > On Tue, Jan 26, 2010 at 11:30 PM, Lukas Renggli > wrote: >>> Can I do this with Pier? >> >> Definitely. >> >>> Pointers to a HOWTO or starting point in the Pier docs appreciated. >> >> The one-click image (http://www.piercms.com) is probably a good >> starting point. It already has the authentication setup for you. You >> just need to log-in, change the default username and password and add >> a few more users. If you don't want the blog, you just delete that >> page. >> >> If you have any more questions feel free to ask. >> >> 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 -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter." From renggli at gmail.com Thu Jan 28 12:33:58 2010 From: renggli at gmail.com (Lukas Renggli) Date: Thu, 28 Jan 2010 12:33:58 +0100 Subject: new bug: unable to use Pier UI to add components -> bug in grouped select In-Reply-To: <3a06f76f1001270710y6473a86ey90d13a4fe4d71992@mail.gmail.com> References: <3a06f76f1001270710y6473a86ey90d13a4fe4d71992@mail.gmail.com> Message-ID: <67628d691001280333hf369a2gd7de0a68ee4eb9a0@mail.gmail.com> That's a Seaside bug. I thought I fixed the refactoring of the select and option boxes to be fully backward compatible. Are you sure you have absolutely the latest Seaside code? Lukas On 27 January 2010 16:10, Nick Ager wrote: > Hi > Yesterday I rebuilt my image using the latest > Metacello?ConfigurationOfSeaside30 (loadLatestVersion) and the latest code > in Pier2 and Magritte2 repositories. I've noticed a new problem when I > attempt to add a component using the Pier web ui which results in a form > validation error: 'Component Class: Invalid input given' > To reproduce: > *?download latest build > from:?http://hudson.lukas-renggli.ch/job/Seaside%203.0/ > * open and start web server > * open a workspace and execute: > PRPierFrame registerAsApplication: 'pier' kernel: (PRKernel named: > 'defaultKernel'). > * browse to http://localhost:8080/pier and select the edit link > * type: '+acomponent+' into the text in the box and press 'save' > * click on the 'acomponent' link and in the type select list choose > 'Component' and press 'Add' > * select any class from the 'Component Class' select list and press 'save' > * note the form validation error:?"Component Class: Invalid input given" > Investigation: > *?MAKindError is being generated as the component selected is always > WAComponent regardless of the user selection. > * WAComponent is the default value ; the selected value is not being set as > the callback in MASelectListComponent>>renderOption:on: is never called. > This appears to be a Seaside bug; it appears that the callbacks for a > grouped select list are not called on form submission. > Further investigation: > * using the latest build browse to http://localhost:8080/magritte/editor > * select a type other than 'Boolean' from the grouped select box eg choose > 'File' and press Add > * notice that whatever type you choose 'Boolean' is always selected. > * place a 'self halt' in the callback > in?MASelectListComponent>>renderOption:on: and notice that it is never > called. > I noticed that there have been bug fixes on the select > tag:?http://lists.squeakfoundation.org/pipermail/seaside/2010-January/022358.html > I made sure that the build I was using had the latest Seaside-Canvas > (Seaside-Canvas-lr.88.mcz). My previous image with working grouped selection > list was based on Seaside-Canvas-pmm.74.mcz > Hope I'm not reporting something that has already been fixed or noticed > elsewhere > Nick > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli http://www.lukas-renggli.ch From nick.ager at gmail.com Thu Jan 28 14:30:28 2010 From: nick.ager at gmail.com (Nick Ager) Date: Thu, 28 Jan 2010 13:30:28 +0000 Subject: new bug: unable to use Pier UI to add components -> bug in grouped select In-Reply-To: <67628d691001280333hf369a2gd7de0a68ee4eb9a0@mail.gmail.com> References: <3a06f76f1001270710y6473a86ey90d13a4fe4d71992@mail.gmail.com> <67628d691001280333hf369a2gd7de0a68ee4eb9a0@mail.gmail.com> Message-ID: <3a06f76f1001280530n464efa7ckfe76ae2f1fdc1df@mail.gmail.com> Hi Lukas, On 28 January 2010 11:33, Lukas Renggli wrote: > That's a Seaside bug. I thought I fixed the refactoring of the select > and option boxes to be fully backward compatible. Are you sure you > have absolutely the latest Seaside code? I just checked again with the latest Seaside code and saw the problem. Note it's only a problem with grouped selects and the only place I've seen them used within the framework is within Pier and Magritte. Hope this helps Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Thu Jan 28 15:47:43 2010 From: renggli at gmail.com (Lukas Renggli) Date: Thu, 28 Jan 2010 15:47:43 +0100 Subject: new bug: unable to use Pier UI to add components -> bug in grouped select In-Reply-To: <3a06f76f1001280530n464efa7ckfe76ae2f1fdc1df@mail.gmail.com> References: <3a06f76f1001270710y6473a86ey90d13a4fe4d71992@mail.gmail.com> <67628d691001280333hf369a2gd7de0a68ee4eb9a0@mail.gmail.com> <3a06f76f1001280530n464efa7ckfe76ae2f1fdc1df@mail.gmail.com> Message-ID: <67628d691001280647g68252329r9803cfefe2257ddf@mail.gmail.com> On 28 January 2010 14:30, Nick Ager wrote: > Hi Lukas, > > On 28 January 2010 11:33, Lukas Renggli wrote: >> >> That's a Seaside bug. I thought I fixed the refactoring of the select >> and option boxes to be fully backward compatible. Are you sure you >> have absolutely the latest Seaside code? > > I just checked again with the latest Seaside code and saw the problem. Note > it's only a problem with grouped selects and the only place I've seen them > used within the framework is within Pier ?and Magritte. Unfortunately all Seaside code got rewritten (and thus option groups and select lists) and now all old code is broken. I prefer to fix it in Seaside though. I'll have a look. Lukas > Hope this helps > Nick > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli http://www.lukas-renggli.ch From nickbrown at fastmail.fm Thu Jan 28 16:11:34 2010 From: nickbrown at fastmail.fm (Nick Brown) Date: Thu, 28 Jan 2010 15:11:34 +0000 Subject: Layout of list of commands, views, and sitemap. Message-ID: <1264691494.28465.1357049935@webmail.messagingengine.com> Hi. I'm working with the Pier 1.2 image from piercms.com, and I'm getting fed up with having to scroll down the web page every time I want to click on a command, a view, etc. So I've been trying to change the layout to be more like what I've seen on Pier sites in the past, where the commands, views, and sitemap were in a column down the left hand side. To this end, I've edited the environment to include:
+/environment/footer+
... and set the contents div to "span-18 last". While this does get things approximately where I want them on screen, the list of commands etc are still being rendered horizontally, and wrapping around inside the div, which is a kind of a mess. I can't figure out what I should do to make them display neatly, one item per line, down the column. Any pointers much appreciated. Cheers, Nick Brown From tudor.girba at gmail.com Thu Jan 28 16:16:10 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Thu, 28 Jan 2010 16:16:10 +0100 Subject: Layout of list of commands, views, and sitemap. In-Reply-To: <1264691494.28465.1357049935@webmail.messagingengine.com> References: <1264691494.28465.1357049935@webmail.messagingengine.com> Message-ID: <937376B8-D24E-40C2-B2FB-86CC2259A688@gmail.com> Hi, Look in the CSS. You probably have somewhere something like "ul li {display: inline}" that makes the list items to be shown one next to each other, instead of one below the other. Cheers, Doru On 28 Jan 2010, at 16:11, Nick Brown wrote: > Hi. I'm working with the Pier 1.2 image from piercms.com, and I'm > getting fed up with having to scroll down the web page every time I > want > to click on a command, a view, etc. So I've been trying to change the > layout to be more like what I've seen on Pier sites in the past, where > the commands, views, and sitemap were in a column down the left hand > side. > > To this end, I've edited the environment to include: >
+/environment/footer+
> > ... and set the contents div to "span-18 last". > > While this does get things approximately where I want them on screen, > the list of commands etc are still being rendered horizontally, and > wrapping around inside the div, which is a kind of a mess. I can't > figure out what I should do to make them display neatly, one item per > line, down the column. > > Any pointers much appreciated. > > Cheers, > Nick Brown > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut." From renggli at gmail.com Thu Jan 28 16:52:03 2010 From: renggli at gmail.com (Lukas Renggli) Date: Thu, 28 Jan 2010 16:52:03 +0100 Subject: Layout of list of commands, views, and sitemap. In-Reply-To: <1264691494.28465.1357049935@webmail.messagingengine.com> References: <1264691494.28465.1357049935@webmail.messagingengine.com> Message-ID: <67628d691001280752t4ba3d92dk16cfb5dd1142a0e3@mail.gmail.com> > Hi. I'm working with the Pier 1.2 image from piercms.com, and I'm > getting fed up with having to scroll down the web page every time I want > to click on a command, a view, etc. So I've been trying to change the > layout to be more like what I've seen on Pier sites in the past, where > the commands, views, and sitemap were in a column down the left hand > side. You might also want to use the keybindings: http://www.piercms.com/doc/shortcuts Lukas -- Lukas Renggli http://www.lukas-renggli.ch From nickbrown at fastmail.fm Thu Jan 28 19:19:15 2010 From: nickbrown at fastmail.fm (Nick Brown) Date: Thu, 28 Jan 2010 18:19:15 +0000 Subject: Layout of list of commands, views, and sitemap. In-Reply-To: <937376B8-D24E-40C2-B2FB-86CC2259A688@gmail.com> References: <1264691494.28465.1357049935@webmail.messagingengine.com> <937376B8-D24E-40C2-B2FB-86CC2259A688@gmail.com> Message-ID: <4B61D523.2060905@fastmail.fm> Thanks guys. That's exactly what I what I was looking for. Cheers, Nick Tudor Girba wrote: > Hi, > > Look in the CSS. You probably have somewhere something like "ul li > {display: inline}" that makes the list items to be shown one next to > each other, instead of one below the other. > > Cheers, > Doru > > > On 28 Jan 2010, at 16:11, Nick Brown wrote: > >> Hi. I'm working with the Pier 1.2 image from piercms.com, and I'm >> getting fed up with having to scroll down the web page every time I want >> to click on a command, a view, etc. So I've been trying to change the >> layout to be more like what I've seen on Pier sites in the past, where >> the commands, views, and sitemap were in a column down the left hand >> side. >> >> To this end, I've edited the environment to include: >>
+/environment/footer+
>> >> ... and set the contents div to "span-18 last". >> >> While this does get things approximately where I want them on screen, >> the list of commands etc are still being rendered horizontally, and >> wrapping around inside the div, which is a kind of a mess. I can't >> figure out what I should do to make them display neatly, one item per >> line, down the column. >> >> Any pointers much appreciated. >> >> Cheers, >> Nick Brown >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > -- > www.tudorgirba.com > > "If you interrupt the barber while he is cutting your hair, > you will end up with a messy haircut." > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki From keith_hodges at yahoo.co.uk Thu Jan 28 20:26:20 2010 From: keith_hodges at yahoo.co.uk (keith) Date: Thu, 28 Jan 2010 19:26:20 +0000 Subject: Layout of list of commands, views, and sitemap. In-Reply-To: <1264691494.28465.1357049935@webmail.messagingengine.com> References: <1264691494.28465.1357049935@webmail.messagingengine.com> Message-ID: <9791E0BA-4746-4B0A-B93A-3ABB3DB1D0E4@yahoo.co.uk> On 28 Jan 2010, at 15:11, Nick Brown wrote: > Hi. I'm working with the Pier 1.2 image from piercms.com, and I'm > getting fed up with having to scroll down the web page every time I > want > to click on a command, a view, etc. So I've been trying to change the > layout to be more like what I've seen on Pier sites in the past, where > the commands, views, and sitemap were in a column down the left hand > side. > > To this end, I've edited the environment to include: >
+/environment/footer+
> > ... and set the contents div to "span-18 last". > > While this does get things approximately where I want them on screen, > the list of commands etc are still being rendered horizontally, and > wrapping around inside the div, which is a kind of a mess. I can't > figure out what I should do to make them display neatly, one item per > line, down the column. > > Any pointers much appreciated. > > Cheers, > Nick Brown Hi Nick, this doesnt answer your question, but here are some other ideas. The absolute simplest way of putting the commands in an accessible place, is simply to put them in a horizontal list at the top. I do this in some cases for admin users, where they are normally hidden. I still use the old pier layout for admin purposes, only I use NiftyCorners javascript for the corners and tabs, and made it so that the colour and logo may be changed for different parts of the site. So for example, user admin can have an appropriate logo, rather than the pencil. What we do is we have all the configuration, layout and styling set globally by the Frame component. So you can have two different seaside applications with different frame components on the same pier data. So typically we have a main site and an admin view of the same site. We also have Frame Components which use the content-with-style framework, as well as the blueprint framework, this means we only need to have one layout for pretty much any standard design. We also have a Frame Component which allow different parts of the site to use different Frame Components, so we used to have an admin area which presented the old-style admin layout and style. The bulk of this code is available in the Pier-Jetsam-Environment package, though I am so far behind the current pier version, that I have no idea if it will work for you. regards Keith From renggli at gmail.com Fri Jan 29 08:56:27 2010 From: renggli at gmail.com (Lukas Renggli) Date: Fri, 29 Jan 2010 08:56:27 +0100 Subject: new bug: unable to use Pier UI to add components -> bug in grouped select In-Reply-To: <67628d691001280647g68252329r9803cfefe2257ddf@mail.gmail.com> References: <3a06f76f1001270710y6473a86ey90d13a4fe4d71992@mail.gmail.com> <67628d691001280333hf369a2gd7de0a68ee4eb9a0@mail.gmail.com> <3a06f76f1001280530n464efa7ckfe76ae2f1fdc1df@mail.gmail.com> <67628d691001280647g68252329r9803cfefe2257ddf@mail.gmail.com> Message-ID: <67628d691001282356v65931b9fh3dd6f102ddaa7d0@mail.gmail.com> Ok, this was mostly a Magritte problem; and a little bit a Seaside problem. For the Magritte part I've applied an ugly fix and created Issue 3 (groupBy is totally buggy): http://code.google.com/p/magritte-metamodel/issues/detail?id=3 For the Seaside part I think in this rare case it just requires some change in the code. Lukas On 28 January 2010 15:47, Lukas Renggli wrote: > On 28 January 2010 14:30, Nick Ager wrote: >> Hi Lukas, >> >> On 28 January 2010 11:33, Lukas Renggli wrote: >>> >>> That's a Seaside bug. I thought I fixed the refactoring of the select >>> and option boxes to be fully backward compatible. Are you sure you >>> have absolutely the latest Seaside code? >> >> I just checked again with the latest Seaside code and saw the problem. Note >> it's only a problem with grouped selects and the only place I've seen them >> used within the framework is within Pier ?and Magritte. > > Unfortunately all Seaside code got rewritten (and thus option groups > and select lists) and now all old code is broken. I prefer to fix it > in Seaside though. I'll have a look. > > Lukas > > > >> Hope this helps >> Nick >> >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > -- Lukas Renggli http://www.lukas-renggli.ch From renggli at gmail.com Fri Jan 29 08:56:43 2010 From: renggli at gmail.com (Lukas Renggli) Date: Fri, 29 Jan 2010 08:56:43 +0100 Subject: new bug: unable to use Pier UI to add components -> bug in grouped select In-Reply-To: <67628d691001282356v65931b9fh3dd6f102ddaa7d0@mail.gmail.com> References: <3a06f76f1001270710y6473a86ey90d13a4fe4d71992@mail.gmail.com> <67628d691001280333hf369a2gd7de0a68ee4eb9a0@mail.gmail.com> <3a06f76f1001280530n464efa7ckfe76ae2f1fdc1df@mail.gmail.com> <67628d691001280647g68252329r9803cfefe2257ddf@mail.gmail.com> <67628d691001282356v65931b9fh3dd6f102ddaa7d0@mail.gmail.com> Message-ID: <67628d691001282356m531b2ea0vecfee3c5207094e4@mail.gmail.com> Aha, and this is the fix: Name: Magritte-Seaside-lr.329 Author: lr Time: 29 January 2010, 8:55 am UUID: c7872691-db24-4a19-8387-480a5d467d0f Ancestors: Magritte-Seaside-NickAger.328 - fixed some bugs that were introduced with some recent seaside verisons On 29 January 2010 08:56, Lukas Renggli wrote: > Ok, this was mostly a Magritte problem; and a little bit a Seaside problem. > > For the Magritte part I've applied an ugly fix and created Issue 3 > (groupBy is totally buggy): > > ? ? http://code.google.com/p/magritte-metamodel/issues/detail?id=3 > > For the Seaside part I think in this rare case it just requires some > change in the code. > > Lukas > > On 28 January 2010 15:47, Lukas Renggli wrote: >> On 28 January 2010 14:30, Nick Ager wrote: >>> Hi Lukas, >>> >>> On 28 January 2010 11:33, Lukas Renggli wrote: >>>> >>>> That's a Seaside bug. I thought I fixed the refactoring of the select >>>> and option boxes to be fully backward compatible. Are you sure you >>>> have absolutely the latest Seaside code? >>> >>> I just checked again with the latest Seaside code and saw the problem. Note >>> it's only a problem with grouped selects and the only place I've seen them >>> used within the framework is within Pier ?and Magritte. >> >> Unfortunately all Seaside code got rewritten (and thus option groups >> and select lists) and now all old code is broken. I prefer to fix it >> in Seaside though. I'll have a look. >> >> Lukas >> >> >> >>> Hope this helps >>> Nick >>> >>> >>> _______________________________________________ >>> Magritte, Pier and Related Tools ... >>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>> >> >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > -- Lukas Renggli http://www.lukas-renggli.ch From nick.ager at gmail.com Fri Jan 29 11:49:58 2010 From: nick.ager at gmail.com (Nick Ager) Date: Fri, 29 Jan 2010 10:49:58 +0000 Subject: new bug: unable to use Pier UI to add components -> bug in grouped select In-Reply-To: <67628d691001282356m531b2ea0vecfee3c5207094e4@mail.gmail.com> References: <3a06f76f1001270710y6473a86ey90d13a4fe4d71992@mail.gmail.com> <67628d691001280333hf369a2gd7de0a68ee4eb9a0@mail.gmail.com> <3a06f76f1001280530n464efa7ckfe76ae2f1fdc1df@mail.gmail.com> <67628d691001280647g68252329r9803cfefe2257ddf@mail.gmail.com> <67628d691001282356v65931b9fh3dd6f102ddaa7d0@mail.gmail.com> <67628d691001282356m531b2ea0vecfee3c5207094e4@mail.gmail.com> Message-ID: <3a06f76f1001290249nd3a9c53y6e82f22131f70378@mail.gmail.com> On 29 January 2010 07:56, Lukas Renggli wrote: > Aha, and this is the fix: > > Name: Magritte-Seaside-lr.329 > Author: lr > Time: 29 January 2010, 8:55 am > UUID: c7872691-db24-4a19-8387-480a5d467d0f > Ancestors: Magritte-Seaside-NickAger.328 > > - fixed some bugs that were introduced with some recent seaside verisons > > Thanks problem solved - fantastic -------------- next part -------------- An HTML attachment was scrubbed... URL: From p3anoman at gmail.com Sat Jan 30 05:06:07 2010 From: p3anoman at gmail.com (John McKeon) Date: Fri, 29 Jan 2010 23:06:07 -0500 Subject: Gofer broke? Message-ID: <40f637ec1001292006k5001c7c1n1cdbecce5f7d7ad@mail.gmail.com> I'm sure it is probably not but I couldn't resist the pun... . I wrote a small Gofer script (attached) which does what I need except I was surprised that class initializations appear to occur in the reverse order in which the packages are loaded? The script loads PostgresV2, ROE, Magritte-Roe and, my favorite bit of contributed code, Moe. The problem is that Magritte-Roe attempts to connect to PostgreSQL before meaningful connection arguments can be entered, so it bombs out. This causes all of the remaining initializations not to execute, which leaves PostgresV2 unable to connect at all until PGPacket is manually initialized. So I added a bit of code to MAConnectionPool's initialization to prompt for the correct arguments to be entered before MAConnectionPool attempts to startup. It is a bit ugly, using a half a dozen FillInTheBlankMorphs to get the required info. Before doing it that way, I added Magritte descriptions to PGConnectionArgs so as to bring up a nice morphic dialog (see MAConnectionPool class>>initializeConnectionArgsMorphic), but two problems with that are: 1) Magritte-Morphic is not loaded in the standard Pharo 1.0 image? (I guess I could add that to the Gofer script) 2) I can't get an answer from the resulting dialog All of this is in the latest version of Magritte-Roe in the repository. If anyone cares to take a look at my morphic dialog code, I would welcome any advice. Thanks in advance John McKeon -- http://jmck.seasidehosting.st -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MoeInstall.st Type: application/octet-stream Size: 450 bytes Desc: not available URL: From renggli at gmail.com Sat Jan 30 11:56:19 2010 From: renggli at gmail.com (Lukas Renggli) Date: Sat, 30 Jan 2010 11:56:19 +0100 Subject: Gofer broke? In-Reply-To: <40f637ec1001292006k5001c7c1n1cdbecce5f7d7ad@mail.gmail.com> References: <40f637ec1001292006k5001c7c1n1cdbecce5f7d7ad@mail.gmail.com> Message-ID: <67628d691001300256r17315dd0u69f692045141e5a1@mail.gmail.com> > I wrote a small Gofer script (attached) which does what I need except I was > surprised that class initializations appear to occur in the reverse order in > which the packages are loaded? Yeah, that's annoying, but it is not the fault of Gofer. Monticello (and for that matter also change-sets or file-ins) always executed initializers in an arbitrary (alphabetical) order (or not at all, if the code didn't change). I could probably hack that the initializers of the packages would be evaluated in the right order, but inside the package that would be still random. So I don't know if this is worth the trouble? For know, the issue you report is a bug in your package. You have to write the initializers so that they work in any order. Lukas -- Lukas Renggli http://www.lukas-renggli.ch From garduino at gmail.com Sat Jan 30 13:44:26 2010 From: garduino at gmail.com (=?ISO-8859-1?Q?Germ=E1n_Arduino?=) Date: Sat, 30 Jan 2010 09:44:26 -0300 Subject: ConfigurationOfSeaside available In-Reply-To: <919278502.1174771264556032498.JavaMail.root@gir> References: <151480772.1174341264555101807.JavaMail.root@gir> <919278502.1174771264556032498.JavaMail.root@gir> Message-ID: I tried in a new pharo core image, using Seaside 3.0 and friends and worked ok. Thanks!! Germ?n. 2010/1/26 Dale Henrichs : > First load the configuration. > > For Pharo: > ?Gofer new > ? ? ? ?squeaksource: 'MetacelloRepository'; > ? ? ? ?package: 'ConfigurationOfSeaside'; > ? ? ? ?load. > For Squeak: > ?- load the latest version of ConfigurationOfSeaside from http://www.squeaksource.com/MetacelloRepository > > > Then pick the Seaside variant you want to load: > > ?"Seaside 2.8" > ?ConfigurationOfSeaside project latestVersion load: 'Seaside 2.8'. > ?ConfigurationOfSeaside project latestVersion load: 'Seaside 2.8 Examples'. > ?ConfigurationOfSeaside project latestVersion load: 'Magritte'. > ?ConfigurationOfSeaside project latestVersion load: 'Magritte Tests'. > ?ConfigurationOfSeaside project latestVersion load: 'Pier'. > ?ConfigurationOfSeaside project latestVersion load: 'Pier Tests'. > ?ConfigurationOfSeaside project latestVersion load: 'Pier AddOns'. > > ?"Seaside 3.0" > ?ConfigurationOfSeaside project latestVersion load: 'Seaside 3.0'. > ?ConfigurationOfSeaside project latestVersion load: 'Seaside 3.0 Tests'. > ?ConfigurationOfSeaside project latestVersion load: 'Magritte2'. > ?ConfigurationOfSeaside project latestVersion load: 'Magritte2 Tests'. > ?ConfigurationOfSeaside project latestVersion load: 'Pier2'. > ?ConfigurationOfSeaside project latestVersion load: 'Pier2 Tests'. > ?ConfigurationOfSeaside project latestVersion load: 'Pier2 AddOns'. > > I've tested the various loads with PharoCore-1.0-10508rc2 and Squeak3.11-8931-alpha. The tests aren't 100% green on either platform... > > Dale > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- ================================================= Germ?n S. Arduino Twitter: garduino Arduino Software & Web Hosting http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com ================================================= From marianopeck at gmail.com Sat Jan 30 14:12:28 2010 From: marianopeck at gmail.com (Mariano Martinez Peck) Date: Sat, 30 Jan 2010 14:12:28 +0100 Subject: Gofer broke? In-Reply-To: <40f637ec1001292006k5001c7c1n1cdbecce5f7d7ad@mail.gmail.com> References: <40f637ec1001292006k5001c7c1n1cdbecce5f7d7ad@mail.gmail.com> Message-ID: On Sat, Jan 30, 2010 at 5:06 AM, John McKeon wrote: > I'm sure it is probably not but I couldn't resist the pun... > . > I wrote a small Gofer script (attached) which does what I need except I was > surprised that class initializations appear to occur in the reverse order in > which the packages are loaded? The script loads PostgresV2, ROE, > Magritte-Roe and, my favorite bit of contributed code, Moe. > > The problem is that Magritte-Roe attempts to connect to PostgreSQL before > meaningful connection arguments can be entered, so it bombs out. This causes > all of the remaining initializations not to execute, which leaves PostgresV2 > unable to connect at all until PGPacket is manually initialized. > > So I added a bit of code to MAConnectionPool's initialization to prompt for > the correct arguments to be entered before MAConnectionPool attempts to > startup. It is a bit ugly, using a half a dozen FillInTheBlankMorphs to get > the required info. Before doing it that way, I added Magritte descriptions > to PGConnectionArgs so as to bring up a nice morphic dialog (see > MAConnectionPool class>>initializeConnectionArgsMorphic), but two problems > with that are: > 1) Magritte-Morphic is not loaded in the standard Pharo 1.0 image? (I guess > I could add that to the Gofer script) > No. > 2) I can't get an answer from the resulting dialog > > John: have you considered creating your own Metacello configuration for your project? I will enable you to load very easily all your stuff in a core/dev image without problems, using stable versions, automatically resolving dependencies, etc. I think that maybe, the Metacello pre and post doits may help you. You should not put your code in your class side initialize methods, but in those post do its. Then you can have pre and post do its at package and project level. There is also a parameter in the Metacello called #loadType: which default is linear. But maybe the #atomic may help you. I am not sure. Just in case you are interested in, I suggest you to read the metacello image based tutorial (no more than an hour) and if you have questions there is a mailing list where you can ask. Link: http://code.google.com/p/metacello/wiki/Tutorial Good luck. Mariano Cheers > All of this is in the latest version of Magritte-Roe in the repository. If > anyone cares to take a look at my morphic dialog code, I would welcome any > advice. > > Thanks in advance > John McKeon > > > > -- > http://jmck.seasidehosting.st > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marianopeck at gmail.com Sat Jan 30 21:32:11 2010 From: marianopeck at gmail.com (Mariano Martinez Peck) Date: Sat, 30 Jan 2010 21:32:11 +0100 Subject: ConfigurationOfSeaside available In-Reply-To: References: <151480772.1174341264555101807.JavaMail.root@gir> <919278502.1174771264556032498.JavaMail.root@gir> Message-ID: Thanks Dale. Next Pharo image will have this in the welcome workspace :) On Sat, Jan 30, 2010 at 1:44 PM, Germ?n Arduino wrote: > I tried in a new pharo core image, using Seaside 3.0 and friends and worked > ok. > > Thanks!! > > Germ?n. > > > 2010/1/26 Dale Henrichs : > > First load the configuration. > > > > For Pharo: > > Gofer new > > squeaksource: 'MetacelloRepository'; > > package: 'ConfigurationOfSeaside'; > > load. > > For Squeak: > > - load the latest version of ConfigurationOfSeaside from > http://www.squeaksource.com/MetacelloRepository > > > > > > Then pick the Seaside variant you want to load: > > > > "Seaside 2.8" > > ConfigurationOfSeaside project latestVersion load: 'Seaside 2.8'. > > ConfigurationOfSeaside project latestVersion load: 'Seaside 2.8 > Examples'. > > ConfigurationOfSeaside project latestVersion load: 'Magritte'. > > ConfigurationOfSeaside project latestVersion load: 'Magritte Tests'. > > ConfigurationOfSeaside project latestVersion load: 'Pier'. > > ConfigurationOfSeaside project latestVersion load: 'Pier Tests'. > > ConfigurationOfSeaside project latestVersion load: 'Pier AddOns'. > > > > "Seaside 3.0" > > ConfigurationOfSeaside project latestVersion load: 'Seaside 3.0'. > > ConfigurationOfSeaside project latestVersion load: 'Seaside 3.0 Tests'. > > ConfigurationOfSeaside project latestVersion load: 'Magritte2'. > > ConfigurationOfSeaside project latestVersion load: 'Magritte2 Tests'. > > ConfigurationOfSeaside project latestVersion load: 'Pier2'. > > ConfigurationOfSeaside project latestVersion load: 'Pier2 Tests'. > > ConfigurationOfSeaside project latestVersion load: 'Pier2 AddOns'. > > > > I've tested the various loads with PharoCore-1.0-10508rc2 and > Squeak3.11-8931-alpha. The tests aren't 100% green on either platform... > > > > Dale > > _______________________________________________ > > Magritte, Pier and Related Tools ... > > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > > > > -- > ================================================= > Germ?n S. Arduino Twitter: garduino > Arduino Software & Web Hosting http://www.arduinosoftware.com > PasswordsPro http://www.passwordspro.com > ================================================= > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -------------- next part -------------- An HTML attachment was scrubbed... URL: From p3anoman at gmail.com Sat Jan 30 21:35:43 2010 From: p3anoman at gmail.com (John McKeon) Date: Sat, 30 Jan 2010 15:35:43 -0500 Subject: Gofer broke? In-Reply-To: References: <40f637ec1001292006k5001c7c1n1cdbecce5f7d7ad@mail.gmail.com> Message-ID: <40f637ec1001301235xa7a8f18g699e8fac9944bafb@mail.gmail.com> Thank you both. The little tidbit about alphabetical order explains everything. I will check out Metacello as well Mariano. Thanks for the link. For now I just split the Gofer script into two loads so that PostgresV2 initializes first. I suppose it is not considered good form to run a GUI dialog during class initialization, but getting a debugger popping up because the database config is wrong is not pleasant either. The modifications I made will not add the connection pool to the Smalltalk start up list until a valid connection configuration is entered so as to avoid all of that. And its database stuff, so its not really all that pretty to begin with. John On Sat, Jan 30, 2010 at 8:12 AM, Mariano Martinez Peck < marianopeck at gmail.com> wrote: > > > On Sat, Jan 30, 2010 at 5:06 AM, John McKeon wrote: > >> I'm sure it is probably not but I couldn't resist the pun... >> Just in case you are interested in, I suggest you to read the metacello >> image based tutorial (no more than an hour) and if you have questions there >> is a mailing list where you can ask. >> > > Link: http://code.google.com/p/metacello/wiki/Tutorial > > Good luck. > > Mariano > > Cheers > > > >> All of this is in the latest version of Magritte-Roe in the repository. If >> anyone cares to take a look at my morphic dialog code, I would welcome any >> advice. >> >> Thanks in advance >> John McKeon >> >> >> >> -- >> http://jmck.seasidehosting.st >> >> _______________________________________________ >> 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 > -- http://jmck.seasidehosting.st -------------- next part -------------- An HTML attachment was scrubbed... URL: From norbert at hartl.name Sun Jan 31 14:25:11 2010 From: norbert at hartl.name (Norbert Hartl) Date: Sun, 31 Jan 2010 14:25:11 +0100 Subject: ConfigurationOfSeaside available In-Reply-To: <919278502.1174771264556032498.JavaMail.root@gir> References: <919278502.1174771264556032498.JavaMail.root@gir> Message-ID: Dale, that is just perfect. Thanks to all porting pier to seaside 3. I tried to google about the progress of pier on seaside 3. I didn't read this mailing list the last months. So I'm again right on time to save me some work. Thanks. We just moved to a new server using openvz so I have a second machine running gemstone just waiting to load pier2. Are there any problems known exporting a pier tree from pier1 and import it into pier2? thanks a lot, Norbert On 27.01.2010, at 02:33, Dale Henrichs wrote: > First load the configuration. > > For Pharo: > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfSeaside'; > load. > For Squeak: > - load the latest version of ConfigurationOfSeaside from http://www.squeaksource.com/MetacelloRepository > > > Then pick the Seaside variant you want to load: > > "Seaside 2.8" > ConfigurationOfSeaside project latestVersion load: 'Seaside 2.8'. > ConfigurationOfSeaside project latestVersion load: 'Seaside 2.8 Examples'. > ConfigurationOfSeaside project latestVersion load: 'Magritte'. > ConfigurationOfSeaside project latestVersion load: 'Magritte Tests'. > ConfigurationOfSeaside project latestVersion load: 'Pier'. > ConfigurationOfSeaside project latestVersion load: 'Pier Tests'. > ConfigurationOfSeaside project latestVersion load: 'Pier AddOns'. > > "Seaside 3.0" > ConfigurationOfSeaside project latestVersion load: 'Seaside 3.0'. > ConfigurationOfSeaside project latestVersion load: 'Seaside 3.0 Tests'. > ConfigurationOfSeaside project latestVersion load: 'Magritte2'. > ConfigurationOfSeaside project latestVersion load: 'Magritte2 Tests'. > ConfigurationOfSeaside project latestVersion load: 'Pier2'. > ConfigurationOfSeaside project latestVersion load: 'Pier2 Tests'. > ConfigurationOfSeaside project latestVersion load: 'Pier2 AddOns'. > > I've tested the various loads with PharoCore-1.0-10508rc2 and Squeak3.11-8931-alpha. The tests aren't 100% green on either platform... > > Dale > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki From garduino at gmail.com Sun Jan 31 14:42:40 2010 From: garduino at gmail.com (=?ISO-8859-1?Q?Germ=E1n_Arduino?=) Date: Sun, 31 Jan 2010 10:42:40 -0300 Subject: [Magritte] MAToOneRelationDescription explanation Message-ID: Hi: I'm a bit confused using relationships between objects in Magritte. Let's start with MAToOneRelationDescription. I've a Contracts system were each contract have 1:1 Relation with Suppliers (another collection of the system), then on the form to add contracts, on the place of Supplier I wants to show a combo with, for example, all the suppliers names loaded on the suppliers collection, to select one to use in the current contract. Very common need I think (Is the way I used to do with Mewa). But trying with different options (not found much doc about each possible method to use on MAToOneRelationDescription) I get a "create" button than, certainly, is not what I need and really not understand the fundamentals of this button on a single 1:1 relationship. Any clarification about this topic, examples, documentation, etc will be greatly appreciated. BTW, I'm using Seaside 3.0 with installed on Pharo rc2 with the Configuration provided by Dale. Cheers. -- ================================================= Germ?n S. Arduino Twitter: garduino Arduino Software & Web Hosting http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com ================================================= From p3anoman at gmail.com Sun Jan 31 16:52:33 2010 From: p3anoman at gmail.com (John McKeon) Date: Sun, 31 Jan 2010 10:52:33 -0500 Subject: [Magritte] MAToOneRelationDescription explanation In-Reply-To: References: Message-ID: <40f637ec1001310752jb9de0fds3eee30c818a310a2@mail.gmail.com> Hello German, On Sun, Jan 31, 2010 at 8:42 AM, Germ?n Arduino wrote: > Hi: > > I'm a bit confused using relationships between objects in Magritte. > Let's start with MAToOneRelationDescription. > > I've a Contracts system were each contract have 1:1 Relation with > Suppliers (another collection of the system), then on the form > to add contracts, on the place of Supplier I wants to show a combo > with, for example, all the suppliers names loaded on the > suppliers collection, to select one to use in the current contract. > Very common need I think (Is the way I used to do with Mewa). > > But trying with different options (not found much doc about each > possible method to use on MAToOneRelationDescription) I get > a "create" button than, certainly, is not what I need and really not > understand the fundamentals of this button on a single 1:1 > relationship. > > On the class side of MAToOneRelationDescription the defaultComponentClasses method returns an array with two component classes: MAExternalEditorComponent and MAInternalEditorComponent. By default, the first of these is what you are seeing rendered. To override this behavior you have to send componentClass: to your description. Magritte does not come with a select list component for the MAToOneRelationDescription but it is easy to create one descended from MAOneToOneComponent that will render a select list of all the instances of the classes declared in the classes: message sent to the description. So your descriptionSupplier method might look like: ^MAToOneRelationDescription new classes: (Array with: Supplier); componentClass: NewSelectionComponent; accessor: #supplier; &etc I threw one together and attached the FileOut of it. It is descended from the ExternalEditor component so it renders a Create button as well. One caveat, I am using Seaside 2.8 Hope this helps John > Any clarification about this topic, examples, documentation, etc will > be greatly appreciated. > > BTW, I'm using Seaside 3.0 with installed on Pharo rc2 with the > Configuration provided by Dale. > > Cheers. > -- > ================================================= > Germ?n S. Arduino Twitter: garduino > Arduino Software & Web Hosting http://www.arduinosoftware.com > PasswordsPro http://www.passwordspro.com > ================================================= > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- http://jmck.seasidehosting.st -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Magritte-SelectionComponent.st Type: application/octet-stream Size: 1178 bytes Desc: not available URL: From dale.henrichs at gemstone.com Sun Jan 31 19:11:48 2010 From: dale.henrichs at gemstone.com (Dale Henrichs) Date: Sun, 31 Jan 2010 10:11:48 -0800 (PST) Subject: ConfigurationOfSeaside available In-Reply-To: Message-ID: <1917020037.1240361264961508420.JavaMail.root@gir> Norbert, If you are intending to use Pier and Seaside3.0 in GemStone, I haven't done the port of Pier2 to GemStone yet ... I need to get to the point where GemStone is using the common configurations for Seaside/Magritte/Pier which I'm aiming for in GLASS 1.0-beta.7 ... Once that's done, the port can follow on. Dale ----- "Norbert Hartl" wrote: | Dale, | | that is just perfect. Thanks to all porting pier to seaside 3. I tried | to google about the progress of pier on seaside 3. I didn't read this | mailing list the last months. So I'm again right on time to save me | some work. Thanks. We just moved to a new server using openvz so I | have a second machine running gemstone just waiting to load pier2. Are | there any problems known exporting a pier tree from pier1 and import | it into pier2? | | thanks a lot, | | Norbert | | On 27.01.2010, at 02:33, Dale Henrichs wrote: | | > First load the configuration. | > | > For Pharo: | > Gofer new | > squeaksource: 'MetacelloRepository'; | > package: 'ConfigurationOfSeaside'; | > load. | > For Squeak: | > - load the latest version of ConfigurationOfSeaside from | http://www.squeaksource.com/MetacelloRepository | > | > | > Then pick the Seaside variant you want to load: | > | > "Seaside 2.8" | > ConfigurationOfSeaside project latestVersion load: 'Seaside 2.8'. | > ConfigurationOfSeaside project latestVersion load: 'Seaside 2.8 | Examples'. | > ConfigurationOfSeaside project latestVersion load: 'Magritte'. | > ConfigurationOfSeaside project latestVersion load: 'Magritte | Tests'. | > ConfigurationOfSeaside project latestVersion load: 'Pier'. | > ConfigurationOfSeaside project latestVersion load: 'Pier Tests'. | > ConfigurationOfSeaside project latestVersion load: 'Pier AddOns'. | > | > "Seaside 3.0" | > ConfigurationOfSeaside project latestVersion load: 'Seaside 3.0'. | > ConfigurationOfSeaside project latestVersion load: 'Seaside 3.0 | Tests'. | > ConfigurationOfSeaside project latestVersion load: 'Magritte2'. | > ConfigurationOfSeaside project latestVersion load: 'Magritte2 | Tests'. | > ConfigurationOfSeaside project latestVersion load: 'Pier2'. | > ConfigurationOfSeaside project latestVersion load: 'Pier2 Tests'. | > ConfigurationOfSeaside project latestVersion load: 'Pier2 AddOns'. | > | > I've tested the various loads with PharoCore-1.0-10508rc2 and | Squeak3.11-8931-alpha. The tests aren't 100% green on either | platform... | > | > Dale | > _______________________________________________ | > Magritte, Pier and Related Tools ... | > https://www.iam.unibe.ch/mailman/listinfo/smallwiki From garduino at gmail.com Sun Jan 31 20:22:09 2010 From: garduino at gmail.com (=?ISO-8859-1?Q?Germ=E1n_Arduino?=) Date: Sun, 31 Jan 2010 16:22:09 -0300 Subject: [Magritte] MAToOneRelationDescription explanation In-Reply-To: <40f637ec1001310752jb9de0fds3eee30c818a310a2@mail.gmail.com> References: <40f637ec1001310752jb9de0fds3eee30c818a310a2@mail.gmail.com> Message-ID: Thanks John by the explanation and the example!! As usual with your mails, very very clear. I will try to avoid the create button or include the create (as "New Supplier" or so) on the combo list, as Gmail does with the tags of the mails. Thanks again. Germ?n. 2010/1/31 John McKeon : > Hello German, > On Sun, Jan 31, 2010 at 8:42 AM, Germ?n Arduino wrote: >> >> Hi: >> >> I'm a bit confused using relationships between objects in Magritte. >> Let's start with MAToOneRelationDescription. >> >> I've a Contracts system were each contract have 1:1 Relation with >> Suppliers (another collection of the system), then on the form >> to add contracts, on the place of Supplier I wants to show a combo >> with, for example, all the suppliers names loaded on the >> suppliers collection, to select one to use in the current contract. >> Very common need I think (Is the way I used to do with Mewa). >> >> But trying with different options (not found much doc about each >> possible method to use on MAToOneRelationDescription) I get >> a "create" button than, certainly, is not what I need and really not >> understand the fundamentals of this button on a single 1:1 >> relationship. >> > On the class side of?MAToOneRelationDescription the defaultComponentClasses > method returns an array with two component classes: > MAExternalEditorComponent and MAInternalEditorComponent. By default, the > first of these is what you are seeing rendered. To override this behavior > you have to send componentClass: to your description. Magritte does not come > with a select list component for the MAToOneRelationDescription but it is > easy to create one descended from MAOneToOneComponent that will render a > select list of all the instances of the classes declared in the classes: > message sent to the description. So your descriptionSupplier method might > look like: > ^MAToOneRelationDescription new > ?? classes: (Array with: Supplier); > ?? componentClass: NewSelectionComponent; > ?? accessor: #supplier; > ?? &etc > I threw one together and attached the FileOut of it. It is descended from > the ExternalEditor component so it renders a Create button as well. > One caveat, I am using Seaside 2.8 > Hope this helps > John > >> >> Any clarification about this topic, examples, documentation, etc will >> be greatly appreciated. >> >> BTW, I'm using Seaside 3.0 with installed on Pharo rc2 with the >> Configuration provided by Dale. >> >> Cheers. >> -- >> ================================================= >> Germ?n S. Arduino ? ? Twitter: garduino >> Arduino Software & Web Hosting ? http://www.arduinosoftware.com >> PasswordsPro ?http://www.passwordspro.com >> ================================================= >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > > -- > http://jmck.seasidehosting.st > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > From ross at biostat.ucsf.edu Sun Jan 31 22:46:22 2010 From: ross at biostat.ucsf.edu (Ross Boylan) Date: Sun, 31 Jan 2010 13:46:22 -0800 Subject: PRFile, MAFileModel and friends Message-ID: <1264974382.11406.12.camel@corn.betterworld.us> I am trying to figure out the relation between PRFile, MAFileModel, MAFileDescription, and possibly others. They seem to duplicate a lot of information, such as mimetype and filename. I'm using the Pier-1.2 download. PRFile says it references an instance of MAFileModel, but a lot of test code for seems to get by without an MAFileModel. I've looked for references to the classes, but have found either extremely terse and trivial tests or the setupup for, e.g., defaultCSS. I also don't know which of the classes is intended for display, or how to display them. Initially, I just want to use these to display links to files that are on the disk. Presumably that will use MAExternalFileModel somehow. Later on, I may want to have pseudo files that include the ability to select a format in which to download the file or to display the file inline on the web page. Ross Boylan