seaside-dev February 2011

seaside-dev@lists.squeakfoundation.org

12 participants
18 discussions

Seaside 3.0.4...
by Dale Henrichs 04 Mar '11

04 Mar '11

Tomorrow I will pick up the Issue 643 bugfix from Avi and Philippe and verify the fix in GemStone ... Then I will pick up the additional changes that have been made over the last week and then Seaside3.0.4 should be ready to rumba ... Sorry about how long this integration took, but I had several GemStone-related issues that I had to track down... Dale

3 14

[OT] JQuery Terminal Emulator
by Torsten Bergmann 18 Feb '11

18 Feb '11

Nice plugin that may be helpfull for debugging/development: http://terminal.jcubic.pl/#demo When embedded on a (Seaside) page you can evaluate Javascript code. -- Schon gehört? GMX hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://www.gmx.net/de/go/toolbar

1 0

Seaside 3.0.4 ... Issue 482
by Dale Henrichs 16 Feb '11

16 Feb '11

I think Issue482 requires a post load doit when loaded into an existing Seaside3.0.x installation. The contents of the table class instance variable were changed to effect the speedup, but if you are updating an existing installation the class initialize methods won't be re-executed automatically, so the new code will be running with the old table contents.... Now it's true that I've seen the tests pass when run in an updated issue, but I am wondering if there might be trouble lurking somewhere... A naive comparison of the WAEncoder code in 3.0.3: encoded isString ifTrue: [ stream nextPutAll: encoded ] ifFalse: [ stream nextPut: encoded ] and in 3.0.4: encoded notNil ifTrue: [ stream nextPutAll: encoded ] ifFalse: [ stream nextPut: encoded ] makes me think that if the encode variable is a Character then it will be passed into the #nextPutAll:, which is expecting a String ... now it is possible that the Pharo implementation doesn't care whether the arg to nextPutAll: is a Character or a String, or maybe I'm missing something ... Anyway, I guess this is a long winded way of saying that I think an explicit post load doit is _required_ that explicitly rebuilds the tables with new contents: WAUrlEncoder initialize. WAXmlEncoder initialize. I expect to add this to the Metacello config. I ran into this in GemStone, because we have a primitive that encodes the string based on the encoding table and of course the primitive choked when the table contents changed. This happens to be one of the reasons that I've branched Seaside-Core for GemStone ... I don't expect to be able to eliminate all of the places where I've found it necessary to create a GemStone branch of the common Seaside code, but perhaps this _is_ an instance where some creative application of Grease would improve the portability? Dale

2 2

WAFileLibrary>>#deployFiles filename changing
by Nick Ager 16 Feb '11

16 Feb '11

Hi, I've hit a problem with WAFileLibrary derived libraries in that #deployFiles doesn't preserve the original filename, if that filename contains non alphanumeric characters. During development all is well as the WAFileLibrary converts the requested filename to a valid selector before testing against the file-libraries selectors. However when the files are served directly from the file system, the incoming conversion doesn't take place and the file is not located: jquery.ui.stars.gif => #jqueryuistarsGif => jqueryuistars.gif bubbletip-T-B.png => #bubbletipTBPng => bubbletipTB.png As a solution would it make sense to add a pragma which stored the original filename and if present would be used in #deploy files? bubbletipTBPng <filename: 'bubbletip-T-B-png'> ^ #(137 80 78 ....) asByteArray Happy to implement this if people think it makes sense Cheers Nick

1 1

Seaside 3.0.4 ... Issue 643
by Dale Henrichs 16 Feb '11

16 Feb '11

For Issue 643, I ran into a case during GemStone testing yesterday where there was WAUserConfiguration with a stale cache. WAUserConfigurations _aren't_ reachable by doing the: WASystemConfiguration allSubclasses do: [ :each | each instance clearSearchContexts. each instance clearDescription ]. trick. I ended up doing the following to get past the problem: WAFileHandler default: nil I consider this way too harsh, since it destroys any changes that a user may have made to the configuration ... I think that this really means that we have to have a fix for Issue 643 before finishing Seaside 3.0.4 ... In the bug report, Avi, mentions that it should be possible to do a second lookup that does not rely on the cache and it sounds to me that this is the preferable solution ... My WAConfiguration foo is not good enough to know the right answer here. I just know that Seaside users might be surprised if they upgrade their system to Seaside 3.0.4... Dale

3 8

Seaside 3.0.4?
by Avi Shefi 15 Feb '11

15 Feb '11

Hi, Where are we standing w.r.t. Seaside 3.0.4? Is it ready? Cheers, Avi.

4 5

Seaside 3.0.4 (Swazoo & Issue 629)
by Dale Henrichs 15 Feb '11

15 Feb '11

The fix for Issue 629 has broken Swazoo 2.2, so I was wondering how you'd like to address this: 1. add #stausCode: to Swazoo2.2 so that Swazoo2.2 and Swazoo2.3 are compatible 2. ask Janko to make Swazoo2.3 backwards compatible with Swazoo2.2 so that we don't have to hack Seaside3.0 to make Swazoo2.3 work 3. refactor the swazoo adaptor into two flavors: one for Swazoo2.2 and one for Swazoo2.3 4. end support for Swazoo2.2 and require a 2.3 upgrade This issue showed up for me in a GemStone sweep for sent but not implemented messages. Option 1 is the easiest, since we already have a pretty much Seaside-specific version of Swazoo2.2 that we're using: Swazoo-lr.3. Swazoo2.3 hasn't been port to GemStone yet, so Option 4 isn't an option for GemStone ... for GemStone, I will do Option 1, but I'm curious how you want the Squeak/Pharo issue handled... Oh, one more Swazoo2.3-related issue is that the Swazoo packages do not conform to the Monticello naming conventions (either old or new). Here's a sample of the package names: Swazoo-2.3beta2.1 Swazoo-2.3beta1.3 Swazoo-2.3beta1.2 Swazoo-2.3beta1 Swazoo-2.2 Swazoo-2.2beta4 These packages might be a bit difficult to load with Gofer (at least using Gofer to calculate the "latest mcz file") - in the past I fixed Metacello so that this package naming convention would sort of work, but because Gofer choked on trying to find the latest version, I surrendered...maybe the new sorting algorithm will work ... I haven't had a chance to play with it... Dale

4 6

3.0.4 status
by Dale Henrichs 12 Feb '11

12 Feb '11

PharoCore1.0: - WAHtmlFileHandlerListingTest>>testFileLibraries results in a WAAttributeNotFound being signalled (test error). I'll dig into this one a little bit more tomorrow. - several WAFileLibraryTests fail the first time tests run, pass on rerunning of tests ... I'll ignore these for now PharoCore1.1.1: - several WAFileLibraryTests fail the first time tests run, pass on rerunning of tests ... I'll ignore these for now Seaside-Core-jf.696: - WABaseElement>>target: is still in the package, so Philippe's edits weren't committed (presumably). If the only change that was made at the time was to move WABaseElement>>target: from Seaside-Core to Seaside-HTML5 then I can do the edit tomorrow (it's getting late here:) - no other (unexpected) dirty packages Grease-Pharo-Core and WAUrlEncoder: - I'll do these edits tomorrow as well... I also plan on making a pass at loading Seaside3.0 into Pharo1.2 and Pharo1.3 according to mail I've seen the only problem with Seaside3.0 on Pharo1.2 is related to using the proper version of OB and that's what symbolic versions are for, so I should be able to address that issue. Dale

3 16

3.0.4 status
by Dale Henrichs 12 Feb '11

12 Feb '11

With the a tentative resolution to Issue 643, it looks like 3.0.4 is looking good in Pharo1.0, Pharo1.1.1, Squeak4.1 and Squeak4.2... I've recorded the mcz files associated with 3.0.4 so you can resume checkins .... I've still got GemStone/S and MagLev to go ... You might want to stash the hudson build from tonight (I've updated the version numbers for Grease and Seaside30) as the release image for 3.0.4. Dale

2 2

Which dialects don't support byte array literals?
by Philippe Marschall 11 Feb '11

11 Feb '11

Hi Going over some file library code I was wondering, are there any dialects that don't support byte array literals with the following syntax: #[1 2 3 4] Cheers Philippe

4 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

seaside-dev February 2011