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 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.
• Update 1 to issue 102 ("WAFileLibrary should rely on WAContext for url generation") 2010-02-28T20:55:29+00:00
  while you're at it WAFileLibrary class>>urlOf: aSymbol ^self new urlOf: aSymbol should be: ^self default urlOf: aSymbol This has been corrected in 3.0.
• Issue 553 created: "#isolate: broken" 2010-02-28T18:12:19+00:00
  The problem is that #isolate: depends on WASession's filter state being restored. Unfortunately, the state is restored by the saved Continuation, which isn't looked up until #handleFiltered: (after we have already been through the *current* chain of filters). The obvious solution would seem to involve applying the continuation state in #handle: and then invoking the continuation in #handleFiltered: but this means (a) exposing the restoring of continuation state outside WAContinuation (and splitting the restore/invoke into two operations) and (b) looking up the continuation in two places. Neither of those seem very nice. Also, are we certain that it even makes sense to revert the filter chain for all filters? The ugliness of this issue is pointing to a design problem somewhere in my mind...
• Issue 552 created: "Wrong redirect for expired sessions" 2010-02-28T09:32:46+00:00
  I have a configuration where my Seaside application (a Pier 2 website) is available in the root context. I use apache as a proxy to forward the requests to Seaside. Something like this: RewriteEngine On RewriteRule ^/files/ - [last] RewriteRule ^/(.*)$ http://localhost:9093/myapp/$1 [proxy,last] In Seaside I added the following preference: application preferenceAt: #serverPath put: '/' Everything works fine most of the time. Except when the session has expired. When the users clicks on a link http://host/page?_s=xyz he is redirected to http://host/myapp/page. And of course this page doesn't exist. Any ideas how this can be fixed? Jan.
• Update 5 to issue 523 ("State of Download Links") 2010-02-27T16:09:21+00:00
  Excellent, thank you very much. Status: FixedOwner: renggli
• Update 4 to issue 523 ("State of Download Links") 2010-02-27T15:49:08+00:00
  You can use text like <a href="http://smalltalk.gnu.org/">GNU Smalltalk</a> has included a port of Seaside since GST 3.1. The distribution includes a package called "Seaside", which will load all the necessary code and (if loaded with <tt>--start<var>[=PORT]</var></tt>) will start a server on the given port (default 8080). --- The next version will support downloading updates via git, I'll ask you to update the text when it will be released.
• Update 3 to issue 550 ("WAUrl encodeOn: writes a question mark when there are no queryFields") 2010-02-27T11:13:15+00:00
  The use case is that WARequest>>uri should provide exactly what was given in the request. Even if we opt to normalize that URI (which there should certainly be a method to do, but I'm not convinced we should do automatically), RFC 3986 specifically says in 6.2.3 that: Normalization should not remove delimiters when their associated component is empty unless licensed to do so by the scheme specification. For example, the URI "http://example.com/?" cannot be assumed to be equivalent to [http://example.com/]. I agree that in practice this is not going to be an issue for most people, but I think our URL implementation really shouldn't force any assumptions on its users. I've created Issue 551.
• Issue 551 created: "WAUrl needs to be a bit more flexible in the syntax it can parse" 2010-02-27T11:13:00+00:00
  WAUrl really needs to be able to parse and preserve any valid URL. Changes in Issue 550, for example, will now cause it to drop a trailing question mark when the query string part is empty. It also assumes that the query string is in html form encoding (foo=bar&baz=bar) when it could, in fact, be any arbitrary string. This is all fine for now, but it we should try to make sure we support and preserve all URLs when parsing and and using low-level accessors, even if not all the helpers (like WARequestFields) work on those that don't follow "normal" practices. There should be a method (#normalized ?) to normalize the URL but I'm pretty sure we should NOT normalize them automatically when they are parsed. Also, even when normalized, RFC 3986 specifically says in 6.2.3 that: Normalization should not remove delimiters when their associated component is empty unless licensed to do so by the scheme specification. For example, the URI "http://example.com/?" cannot be assumed to be equivalent to [http://example.com/].
• Update 3 to issue 523 ("State of Download Links") 2010-02-27T10:24:11+00:00
  Thank you. I've updated the link for Dolphin. The situation for Squeak has been resolved too. GNU Smalltalk remains a problem. Can this be finally fixed?