Reporting Issues

View active issues, report bugs and contribute feature requests through our issues tracking system. Alternatively we also accept bug reports or feature requests through the mailing-list.

Recent Updates

• Update 3 to issue 556 ("WAFileHandler not dealing with full paths?") 2010-03-13T08:05:00+00:00
  Name: Seaside-Core-pmm.626 Author: pmm Time: 13 March 2010, 9:03:51 am UUID: 04b74962-a5a6-4920-bd54-9c65ad1e7d92 Ancestors: Seaside-Core-lr.625 - http://code.google.com/p/seaside/issues/detail?id=556 - Issue 556: WAFileHandler not dealing with full paths? - use generic #handle: method in WAFileLibrary Status: Fixed
• Update 2 to issue 556 ("WAFileHandler not dealing with full paths?") 2010-03-13T07:59:57+00:00
  Status: StartedOwner: philippe.marschall
• Update 10 to issue 555 ("SequenceableCollection>>#beginsWith: and #endsWith: are non-portable") 2010-03-12T15:28:07+00:00
  Fortunately, this will work since the idea is to get something (for the moment at least, #beginsWithSubCollection:) that works exactly like #beginsWith: on Squeak/Pharo. Then everyone can be happy since no one needs to change their implementation of #beginsWith:. So: '123' indexOfSubCollection: '' ==> 0 (as defined by ANSI) '123' beginsWith: '' ==> true or false (depending on platform) '123' beginsWithSubCollection: '' ==> false (on all platforms)
• Update 9 to issue 555 ("SequenceableCollection>>#beginsWith: and #endsWith: are non-portable") 2010-03-12T15:00:53+00:00
  Unfortunately, this wouldn't work because Squeak/Pharo's #indexOfSubCollection: _is_ consistent with their #beginsWith:/#endsWith: '123' indexOfSubCollection: '' startingAt: 1 ifAbsent: [0] => 0 (returns 1 in GST, since now I have made it consistent). I see no way out than asking them to change their behavior (for all three methods), or refrain from using these methods if you aren't sure that the argument is non-empty.
• Update 8 to issue 555 ("SequenceableCollection>>#beginsWith: and #endsWith: are non-portable") 2010-03-12T14:51:40+00:00
  I like the idea of #beginsWithSubCollection:/#endsWithSubCollection because: * it is more intention-revealing regarding its argument * it parallels #indexOfSubCollection:, both in spelling and in behavior * it doesn't require anyone to change their base implementation of #beginsWith:/#endsWith:
• Update 7 to issue 555 ("SequenceableCollection>>#beginsWith: and #endsWith: are non-portable") 2010-03-12T12:24:13+00:00
  Or maybe: 3) We define #beginsWithSubCollection: in Grease that behaves consistently with #indexOfSubCollection: That makes the name clearer too and is quite obviously parallel to #indexOfSubCollection: I don't really care one way or another, I think. I kind of think Squeak/Pharo are right (or alternatively ANSI is wrong) so I'm not interested in arguing for them to change their implementation. Someone certainly might be able to do so, though. I also don't mind adding them to Slime and either working around or adding an alternative to Grease.
• Update 1 to issue 556 ("WAFileHandler not dealing with full paths?") 2010-03-12T08:50:37+00:00
  Just do be sure I'm understanding you correctly, you'd like #documentAt:forContext: to take a collection of Strings instead a single String? OTOH we could just pass in the context and access the consumer from there.
• Issue 556 created: "WAFileHandler not dealing with full paths?" 2010-03-12T08:50:09+00:00
  Perhaps I'm missing some element to this, but right now I'm looking at the handling of URLs such as, /handler/library/directory/style.css and it looks like it's impossible to have my library class respond to a request for file whose path includes a directory. The problem is that as WAFileHandler (/handler) is consuming the path #('library' 'directory' 'style.css') , immediately after finding a proper libraryClass it asks it to serve the document and passes value of "consumer next" instead of "consumer upToEnd" or some such thing resulting in my library being asked to serve 'directory' not 'directory/style.css'. Is this plain broken or by design? In case you're curious, I'm collapsing a directory tree into a single library by storing resources using their full path which includes directories. Regards, -Boris
• Update 6 to issue 555 ("SequenceableCollection>>#beginsWith: and #endsWith: are non-portable") 2010-03-11T17:40:30+00:00
  Sorry Paolo, I obviously misread the intention of your "Guess I'll change GST' post. So all but Pharo/Squeak/VAST now answer true. While I can change the VAST implementation to answer true, I would much prefer simply removing the usage of the 2 methods in Seaside since I agree that it is very odd for '123' beginsWith: '' and '123' endsWith: '' to answer true while '123' indexOfSubCollection: '' answers 0. This approach also solves my customers problem since their only interest is in preserving the behavior of THEIR implementation of #beginsWith: and #endsWith:. Status: Accepted
• Update 5 to issue 555 ("SequenceableCollection>>#beginsWith: and #endsWith: are non-portable") 2010-03-11T17:11:53+00:00
  No, GNU ==> true (over my dead body) but, I did change #indexOfSubCollection: to return the index where the search is done in order to be consistent. With VA being strongly encouraged to change, that leaves only Squeak/Pharo.
• Update 4 to issue 555 ("SequenceableCollection>>#beginsWith: and #endsWith: are non-portable") 2010-03-11T17:00:39+00:00
  OK, a further survey shows that for '123' beginsWith: '' Dolphin ==> true GNU ==> true (willing to change) Pharo ==> false Squeak ==> false VAST ==> false (being strongly encouraged by customer to change) VW ==> true I agree with the rationale on the Seaside-dev mailing list that #beginsWith: and #indexOfSubCollection: should treat an empty parameter the same. The choices seem to be: 1) some number of platforms change their implementation (and suffer the pains of migration) 2) Seaside removes usage of #beginsWith: and #endsWith: (they really are simply convenience methods) and there are no migration issues for anyone At this point, I think 2) is the least painful choice. If there is agreement on this approach, I will make the changes (and write the Slime rules).
• Update 2 to issue 364 ("add always redirect option to WARegistry") 2010-03-10T22:12:53+00:00
  I added this possible fix (untested) to a recent email discussion: You can get around this by calling "self requestContext redirect" somewhere like your root component's #initialRequest: method. I'm not certain that's the right place, but I think it should work ok as a workaround.
• Update 3 to issue 555 ("SequenceableCollection>>#beginsWith: and #endsWith: are non-portable") 2010-03-06T00:45:59+00:00
  Ok, and you're convinced it's a Pharo/VA bug, not a VW bug? I can see an argument either way but if #indexOfSubcollection:startingAt: says an empty collection is not found, I don't particularly like that inconsistency.
• Update 2 to issue 555 ("SequenceableCollection>>#beginsWith: and #endsWith: are non-portable") 2010-03-05T22:58:16+00:00
  I only used a String example, but the intent is for SequenceableCollections. The issue was first raised by Gabriel as a VA Smalltalk defect and, after discovering that Pharo ona VW differed, I identified it as a Seaside portability issue. Gabriel has been persuing the issue on the Pharo list independently.
• Update 1 to issue 555 ("SequenceableCollection>>#beginsWith: and #endsWith: are non-portable") 2010-03-05T15:08:46+00:00
  You only mention Strings but I'm guessing you mean for all SequenceableCollections? (and I assume this has come out of the recent discussion on the pharo list?)
• Issue 555 created: "SequenceableCollection>>#beginsWith: and #endsWith: are non-portable" 2010-03-05T14:49:35+00:00
  What steps will reproduce the problem? Inspect: '123' beginsWith: '' Inspect: '123' endsWith: '' What is the expected output? What do you see instead? On Pharo and (currently) VA Smalltalk - Expected: true Observed: false On VisualWorks - Expected: true Observed: true Please use labels and text to provide additional information. Since this difference is not important to any usage of these methods that I can see in Seaside, I suppose this should be converted to a Pharo issue, but I wanted to give notice that I am changing the VA Smalltalk implementation to match VW's.
• Update 3 to issue 554 ("WABuilder>>codec should try WACurrentRequestContext first before using GRNullCodec") 2010-03-01T16:35:06+00:00
  that's only true if you assume that you only have file libraries that store the filename in the selector. Or even files in methods. Subclasses of WAFileLibrary can change that easily, while changing the WAHtmlFileHandlerListing is not so easy. If the WAHtmlFileHandler listing is subject to change, please also refactor the #perform: out of it so that the file library is responsible for returning the size of a file.
• Update 2 to issue 554 ("WABuilder>>codec should try WACurrentRequestContext first before using GRNullCodec") 2010-03-01T16:25:08+00:00
  Yes, WAHtmlFileHandlerListing passing the codec seems to be a better option. Having that said, non-ASCII method selectors make me a bit nervous.
• Update 1 to issue 554 ("WABuilder>>codec should try WACurrentRequestContext first before using GRNullCodec") 2010-03-01T15:46:10+00:00
  Or perhaps the WAHtmlFileHandlerListing should pass in the codec... not sure and haven't looked at the code yet.
• Issue 554 created: "WABuilder>>codec should try WACurrentRequestContext first before using GRNullCodec" 2010-03-01T15:32:40+00:00
  What steps will reproduce the problem? 1. open a file library in the browser 2. add a file like äncödüng.css to the library 2. click the link to the file 3. the file can't be found, as the encoding of the URL is wrong What version of the product are you using? On what operating system? VisualWorks 7.7/Seaside 3.0 Please provide any additional information below. The problem is that WAHtmlFileHandlerListing does "WARenderCanvas builder", where the builder is not initialized with a proper codec. It is then lazy initialized to the nullcodec. WAUrl>>printOn: does the right thing and tries the current request context first, before falling back to the null codec.