Bob,
Thanks again for debugging this problem on squeaksource.com (and apologies for not following up on the matter sooner). The updated version of the decodeUrlEncodedForm:multipleValues: does indeed resolve the problem that we were seeing. Unfortunately, I found another problem related to WideString member names, which is that I cannot (in squeaksource.com screens) edit a project and add a new developer to that existing project.
It seems clear (as previously noted) that we really need to update our source.squeak.org and squeaksource.com images to use an up to date Seaside. I'm not going to attempt that effort (I'm mainly concerned with just keeping squeaksource.com operating), so in the mean time I think I will just work around the problem by converting the WideString member names to ByteString.
Fortunately there are only two member names that are WideString, and they both belong to the same person (CC'ed on this message), so I think that the impact is minor.
Thanks,
Dave
On Mon, Dec 23, 2013 at 12:16:46PM -0500, Bob Arning wrote:
And I see that's exactly what newer versions of this method do...
decodeUrlEncodedForm: string multipleValues: boolean | dict key value start end eqSignPos more | dict := boolean ifTrue: [HttpFormDictionary new] ifFalse: [Dictionary new]. string isEmptyOrNil ifTrue: [^dict]. more := true. start := 1. [end := string indexOf: $& startingAt: start. end == 0 ifTrue: [end := string size. more := false] ifFalse: [end := end - 1]. eqSignPos := string indexOf: $= startingAt: start. (eqSignPos > end or: [eqSignPos == 0]) ifTrue: [key := (key := string copyFrom: start to: end) unescapePercentsWithTextEncoding: nil. value := ''] ifFalse: [key := (key := string copyFrom: start to: eqSignPos-1) unescapePercentsWithTextEncoding: nil. value := (value := string copyFrom: eqSignPos+1 to: end) unescapePercentsWithTextEncoding: nil]. self addKey: key value: value toForm: dict multipleValues: boolean. start := end + 2. more] whileTrue.
^dict
Cheers, Bob
On 12/23/13 11:04 AM, Bob Arning wrote:
I see how it happens...
using Mac, Chrome with 8859-1 encoding as default, I typed
S, t, option-e, e, p, h, a, n, e
in the login screen. What arrives back at the server is
'11=St%E9phane&12=&13=Login'
wherupon HttpRequest tries to parse this
decodeUrlEncodedForm: string multipleValues: boolean | dict key value start end eqSignPos more | dict _ boolean ifTrue: [HttpFormDictionary new] ifFalse: [Dictionary new]. string isEmptyOrNil ifTrue: [^dict]. more _ true. start _ 1. [end _ string indexOf: $& startingAt: start. end == 0 ifTrue: [end _ string size. more _ false] ifFalse: [end _ end - 1]. eqSignPos _ string indexOf: $= startingAt: start. (eqSignPos > end or: [eqSignPos == 0]) ifTrue: [key _ (key _ string copyFrom: start to: end) unescapePercents. value _ ''] ifFalse: [key _ (key _ string copyFrom: start to: eqSignPos-1) unescapePercents. value _ (value _ string copyFrom: eqSignPos+1 to: end) *unescapePercents*]. self addKey: key value: value toForm: dict multipleValues: boolean. start _ end + 2. more] whileTrue.
^dict
and #unescapePercents does
self unescapePercentsWithTextEncoding: 'utf-8'
'St%E9phane' unescapePercents ==> 'St???ane'
whereas, if we knew it was not utf-8, then
'St%E9phane' unescapePercentsWithTextEncoding: nil ==> 'St??phane'
gives the expected answer. I tried to coax my browser to return utf-8, but that had no effect, so I'm wondering if this application would be better off using unescapePercentsWithTextEncoding: nil rather than unescapePercents
Cheers, Bob
On 12/23/13 8:15 AM, Philippe Marschall wrote:
On Mon, Dec 23, 2013 at 1:43 PM, Bob Arningarning315@comcast.net wrote:
It is a WideString and
self asArray collect: [ :e | e asciiValue radix: 16] = #('53' '74' '3FC09C28' '61' '6E' '65' '20' '4D' '75' '6E' '69' '6F' '7A')
Interesting, so somebody somewhere along the way converted the input from something (likely utf-8 although the page is iso-8859-1) to Squeak encoding.
Cheers Philippe _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
On 12.01.2014, at 15:58, David T. Lewis lewis@mail.msen.com wrote:
Bob,
Thanks again for debugging this problem on squeaksource.com (and apologies for not following up on the matter sooner). The updated version of the decodeUrlEncodedForm:multipleValues: does indeed resolve the problem that we were seeing. Unfortunately, I found another problem related to WideString member names, which is that I cannot (in squeaksource.com screens) edit a project and add a new developer to that existing project.
It seems clear (as previously noted) that we really need to update our source.squeak.org and squeaksource.com images to use an up to date Seaside. I'm not going to attempt that effort (I'm mainly concerned with just keeping squeaksource.com operating)
Let me tell you, it takes years ;)
Best -Tobiad
, so in the mean time I think I will just work around the problem by converting the WideString member names to ByteString.
Fortunately there are only two member names that are WideString, and they both belong to the same person (CC'ed on this message), so I think that the impact is minor.
Thanks,
Dave
On Mon, Dec 23, 2013 at 12:16:46PM -0500, Bob Arning wrote:
And I see that's exactly what newer versions of this method do...
decodeUrlEncodedForm: string multipleValues: boolean | dict key value start end eqSignPos more | dict := boolean ifTrue: [HttpFormDictionary new] ifFalse: [Dictionary new]. string isEmptyOrNil ifTrue: [^dict]. more := true. start := 1. [end := string indexOf: $& startingAt: start. end == 0 ifTrue: [end := string size. more := false] ifFalse: [end := end - 1]. eqSignPos := string indexOf: $= startingAt: start. (eqSignPos > end or: [eqSignPos == 0]) ifTrue: [key := (key := string copyFrom: start to: end) unescapePercentsWithTextEncoding: nil. value := ''] ifFalse: [key := (key := string copyFrom: start to: eqSignPos-1) unescapePercentsWithTextEncoding: nil. value := (value := string copyFrom: eqSignPos+1 to: end) unescapePercentsWithTextEncoding: nil]. self addKey: key value: value toForm: dict multipleValues: boolean. start := end + 2. more] whileTrue.
^dict
Cheers, Bob
On 12/23/13 11:04 AM, Bob Arning wrote:
I see how it happens...
using Mac, Chrome with 8859-1 encoding as default, I typed
S, t, option-e, e, p, h, a, n, e
in the login screen. What arrives back at the server is
'11=St%E9phane&12=&13=Login'
wherupon HttpRequest tries to parse this
decodeUrlEncodedForm: string multipleValues: boolean | dict key value start end eqSignPos more | dict _ boolean ifTrue: [HttpFormDictionary new] ifFalse: [Dictionary new]. string isEmptyOrNil ifTrue: [^dict]. more _ true. start _ 1. [end _ string indexOf: $& startingAt: start. end == 0 ifTrue: [end _ string size. more _ false] ifFalse: [end _ end - 1]. eqSignPos _ string indexOf: $= startingAt: start. (eqSignPos > end or: [eqSignPos == 0]) ifTrue: [key _ (key _ string copyFrom: start to: end) unescapePercents. value _ ''] ifFalse: [key _ (key _ string copyFrom: start to: eqSignPos-1) unescapePercents. value _ (value _ string copyFrom: eqSignPos+1 to: end) *unescapePercents*]. self addKey: key value: value toForm: dict multipleValues: boolean. start _ end + 2. more] whileTrue.
^dict
and #unescapePercents does
self unescapePercentsWithTextEncoding: 'utf-8'
'St%E9phane' unescapePercents ==> 'St???ane'
whereas, if we knew it was not utf-8, then
'St%E9phane' unescapePercentsWithTextEncoding: nil ==> 'St??phane'
gives the expected answer. I tried to coax my browser to return utf-8, but that had no effect, so I'm wondering if this application would be better off using unescapePercentsWithTextEncoding: nil rather than unescapePercents
Cheers, Bob
On 12/23/13 8:15 AM, Philippe Marschall wrote:
On Mon, Dec 23, 2013 at 1:43 PM, Bob Arningarning315@comcast.net wrote:
It is a WideString and
self asArray collect: [ :e | e asciiValue radix: 16] = #('53' '74' '3FC09C28' '61' '6E' '65' '20' '4D' '75' '6E' '69' '6F' '7A')
Interesting, so somebody somewhere along the way converted the input from something (likely utf-8 although the page is iso-8859-1) to Squeak encoding.
Cheers Philippe _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
It seems clear (as previously noted) that we really need to update our source.squeak.org and squeaksource.com images to use an up to date Seaside.
A prerequisite to that is to update our source.squeak.org and squeaksource.com images to be 4.5 images.
Just FYI -- I've done with the source.squeak.org backup on box4. It's running the code which is committed to the "ss" repository of source.squeak.org (so, self hosting its own code) in a 2-month old trunk image.
A future step to update Seaside in there would be nice.
On 14.01.2014, at 00:00, Chris Muller asqueaker@gmail.com wrote:
It seems clear (as previously noted) that we really need to update our source.squeak.org and squeaksource.com images to use an up to date Seaside.
A prerequisite to that is to update our source.squeak.org and squeaksource.com images to be 4.5 images.
Just FYI -- I've done with the source.squeak.org backup on box4. It's running the code which is committed to the "ss" repository of source.squeak.org (so, self hosting its own code) in a 2-month old trunk image.
A future step to update Seaside in there would be nice.
Or, y'know, just upgrade to SS3 in the forseable future…
best -tobias
On Mon, Jan 13, 2014 at 05:00:48PM -0600, Chris Muller wrote:
It seems clear (as previously noted) that we really need to update our source.squeak.org and squeaksource.com images to use an up to date Seaside.
A prerequisite to that is to update our source.squeak.org and squeaksource.com images to be 4.5 images.
Just FYI -- I've done with the source.squeak.org backup on box4. It's running the code which is committed to the "ss" repository of source.squeak.org (so, self hosting its own code) in a 2-month old trunk image.
A future step to update Seaside in there would be nice.
That certainly sounds like the right direction. I think that the Seaside update is the part that is relevant to the widestring issues. I don't personally have the time to make this happen, but I'm glad to see the progress you are making. Whenever source.squeak.org moves to the new code base on box4, I'll do whatever is necessary to get squeaksource.com to follow along with it.
Dave
On Tue, Jan 14, 2014 at 12:10:56AM +0100, Tobias Pape wrote:
On 14.01.2014, at 00:00, Chris Muller asqueaker@gmail.com wrote:
It seems clear (as previously noted) that we really need to update our source.squeak.org and squeaksource.com images to use an up to date Seaside.
A prerequisite to that is to update our source.squeak.org and squeaksource.com images to be 4.5 images.
Just FYI -- I've done with the source.squeak.org backup on box4. It's running the code which is committed to the "ss" repository of source.squeak.org (so, self hosting its own code) in a 2-month old trunk image.
A future step to update Seaside in there would be nice.
Or, y'know, just upgrade to SS3 in the forseable future?
This is going to sound ignorant because it is ... would it be feasible to move the current squeaksource.com repository onto SS3 and keep it running as if (from the user point of view) nothing had happened?
My goal for squeaksource.com is to keep it reliable and available as a resource to the community. I updated it to match the code base for source.squeak.org for that reason only. If the repository could be moved to SS3 to provide a more reliable system, that might be a very good thing.
The only thing from my personal point of view is that I cannot put a great deal of time into development or changes to the system. I just want squeaksource.com to work and be reliable, that is all.
Dave
On 14.01.2014, at 00:36, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Jan 14, 2014 at 12:10:56AM +0100, Tobias Pape wrote:
On 14.01.2014, at 00:00, Chris Muller asqueaker@gmail.com wrote:
It seems clear (as previously noted) that we really need to update our source.squeak.org and squeaksource.com images to use an up to date Seaside.
A prerequisite to that is to update our source.squeak.org and squeaksource.com images to be 4.5 images.
Just FYI -- I've done with the source.squeak.org backup on box4. It's running the code which is committed to the "ss" repository of source.squeak.org (so, self hosting its own code) in a 2-month old trunk image.
A future step to update Seaside in there would be nice.
Or, y'know, just upgrade to SS3 in the forseable future?
This is going to sound ignorant because it is ... would it be feasible to move the current squeaksource.com repository onto SS3 and keep it running as if (from the user point of view) nothing had happened?
It is possible but certainly some work. Andreas had written an xml-im/exporter that can be used to export the squeaksource.com image and re-import it into a ss3 image with marginal changes.
My goal for squeaksource.com is to keep it reliable and available as a resource to the community. I updated it to match the code base for source.squeak.org for that reason only. If the repository could be moved to SS3 to provide a more reliable system, that might be a very good thing.
The only thing from my personal point of view is that I cannot put a great deal of time into development or changes to the system. I just want squeaksource.com to work and be reliable, that is all.
Yes. but this need a time investment, one way or another
best -tobias (in autopilot mode, it’s late)
SS3 is already up and running, and all projects which are still alive in 2014 and care to do so have moved their individual projects to SS3. That's a perfect fit for its place in the universe.
I think attempting to cram the rest of the old squeaksource.com model en masse would be a big mistake.
SS3 is great for external projects. I have all of mine there now. But it has had issues in the past which are left to the mercy of Dale's and Tobias' availability. I personally think Squeak needs incentive to stay fit, at least enough to self-host its own code for source.squeak.org.
On Mon, Jan 13, 2014 at 5:36 PM, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Jan 14, 2014 at 12:10:56AM +0100, Tobias Pape wrote:
On 14.01.2014, at 00:00, Chris Muller asqueaker@gmail.com wrote:
It seems clear (as previously noted) that we really need to update our source.squeak.org and squeaksource.com images to use an up to date Seaside.
A prerequisite to that is to update our source.squeak.org and squeaksource.com images to be 4.5 images.
Just FYI -- I've done with the source.squeak.org backup on box4. It's running the code which is committed to the "ss" repository of source.squeak.org (so, self hosting its own code) in a 2-month old trunk image.
A future step to update Seaside in there would be nice.
Or, y'know, just upgrade to SS3 in the forseable future?
This is going to sound ignorant because it is ... would it be feasible to move the current squeaksource.com repository onto SS3 and keep it running as if (from the user point of view) nothing had happened?
My goal for squeaksource.com is to keep it reliable and available as a resource to the community. I updated it to match the code base for source.squeak.org for that reason only. If the repository could be moved to SS3 to provide a more reliable system, that might be a very good thing.
The only thing from my personal point of view is that I cannot put a great deal of time into development or changes to the system. I just want squeaksource.com to work and be reliable, that is all.
Dave
My goal for squeaksource.com is to keep it reliable and available as a resource to the community. I updated it to match the code base for source.squeak.org for that reason only. If the repository could be moved to SS3 to provide a more reliable system, that might be a very good thing.
The code base for source.squeak.org running on that old image from Bert, while maybe better than what squeaksource.com was running before, has a lot of its own problems which have been fixed in the "source.squeak.org/ss" repository.
The only thing from my personal point of view is that I cannot put a great deal of time into development or changes to the system. I just want squeaksource.com to work and be reliable, that is all.
Really, for that goal we need no more than to look to the code in our own basement. There's more work that could be done and I, personally, would _love_ to see commits to that repository get mailed to the list and that we, as a community, would care about a reference example Web-server application powering and powered-by, Squeak.
Hm, I thought Tobias meant "run source.squeak.org's image with SS3 code" rather than "move source.squeak.org's code to the SS3 servers".
Which would address your concerns about external/internal projects, and the need to self-host.
frank
On 14 January 2014 00:09, Chris Muller asqueaker@gmail.com wrote:
SS3 is already up and running, and all projects which are still alive in 2014 and care to do so have moved their individual projects to SS3. That's a perfect fit for its place in the universe.
I think attempting to cram the rest of the old squeaksource.com model en masse would be a big mistake.
SS3 is great for external projects. I have all of mine there now. But it has had issues in the past which are left to the mercy of Dale's and Tobias' availability. I personally think Squeak needs incentive to stay fit, at least enough to self-host its own code for source.squeak.org.
On Mon, Jan 13, 2014 at 5:36 PM, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Jan 14, 2014 at 12:10:56AM +0100, Tobias Pape wrote:
On 14.01.2014, at 00:00, Chris Muller asqueaker@gmail.com wrote:
It seems clear (as previously noted) that we really need to update our source.squeak.org and squeaksource.com images to use an up to date Seaside.
A prerequisite to that is to update our source.squeak.org and squeaksource.com images to be 4.5 images.
Just FYI -- I've done with the source.squeak.org backup on box4. It's running the code which is committed to the "ss" repository of source.squeak.org (so, self hosting its own code) in a 2-month old trunk image.
A future step to update Seaside in there would be nice.
Or, y'know, just upgrade to SS3 in the forseable future?
This is going to sound ignorant because it is ... would it be feasible to move the current squeaksource.com repository onto SS3 and keep it running as if (from the user point of view) nothing had happened?
My goal for squeaksource.com is to keep it reliable and available as a resource to the community. I updated it to match the code base for source.squeak.org for that reason only. If the repository could be moved to SS3 to provide a more reliable system, that might be a very good thing.
The only thing from my personal point of view is that I cannot put a great deal of time into development or changes to the system. I just want squeaksource.com to work and be reliable, that is all.
Dave
On 14.01.2014, at 11:21, Frank Shearar frank.shearar@gmail.com wrote:
Hm, I thought Tobias meant "run source.squeak.org's image with SS3 code" rather than "move source.squeak.org's code to the SS3 servers".
Which would address your concerns about external/internal projects, and the need to self-host.
Yes.
On Tue, Jan 14, 2014 at 11:25:14AM +0100, Tobias Pape wrote:
On 14.01.2014, at 11:21, Frank Shearar frank.shearar@gmail.com wrote:
Hm, I thought Tobias meant "run source.squeak.org's image with SS3 code" rather than "move source.squeak.org's code to the SS3 servers".
Which would address your concerns about external/internal projects, and the need to self-host.
Yes.
That was my understanding of the conversation as well.
Dave
On 14.01.2014, at 13:50, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Jan 14, 2014 at 11:25:14AM +0100, Tobias Pape wrote:
On 14.01.2014, at 11:21, Frank Shearar frank.shearar@gmail.com wrote:
Hm, I thought Tobias meant "run source.squeak.org's image with SS3 code" rather than "move source.squeak.org's code to the SS3 servers".
Which would address your concerns about external/internal projects, and the need to self-host.
Yes.
That was my understanding of the conversation as well.
So you argue that patching ssc (squeaksource.com) to support newer Squeak and Seaside *again* is easier or more sustainable than migrating to the sqeaksource3 codebase?
Best -Tobias
On 14.01.2014, at 14:02, Tobias Pape Das.Linux@gmx.de wrote:
On 14.01.2014, at 13:50, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Jan 14, 2014 at 11:25:14AM +0100, Tobias Pape wrote:
On 14.01.2014, at 11:21, Frank Shearar frank.shearar@gmail.com wrote:
Hm, I thought Tobias meant "run source.squeak.org's image with SS3 code" rather than "move source.squeak.org's code to the SS3 servers".
Which would address your concerns about external/internal projects, and the need to self-host.
Yes.
That was my understanding of the conversation as well.
So you argue that patching ssc (squeaksource.com) to support newer Squeak and Seaside *again* is easier or more sustainable than migrating to the sqeaksource3 codebase?
OH forget that mail! I confused Chris and Dave. I am so stupid today :( Sorry
Best -Tobiad
Hm, I thought Tobias meant "run source.squeak.org's image with SS3 code" rather than "move source.squeak.org's code to the SS3 servers".
Porting SS3 from GemStone to Squeak would probably be harder than just upgrading the existing code.
Neither activity has what it needs though -- someone with enough time and will to do it.
On 14.01.2014, at 17:02, Chris Muller ma.chris.m@gmail.com wrote:
Hm, I thought Tobias meant "run source.squeak.org's image with SS3 code" rather than "move source.squeak.org's code to the SS3 servers".
Porting SS3 from GemStone to Squeak would probably be harder than just upgrading the existing code.
Have you actually looked at SS3? I develop SS3 in Squeak (and pharo and gemstone) and it always runs on Squeak (as long as Seaside does, for that matter).
Installer squeaksource project: 'MetacelloRepository'; install: 'ConfigurationOfSqueakSource'.
((Smalltalk classNamed: #'ConfigurationOfSqueakSource') project version: #bleedingEdge) load: 'All'. " Or without tests: ((Smalltalk classNamed: #'ConfigurationOfSqueakSource') project version: #bleedingEdge) load: 'Full'. "
Have an image, see for yourself: https://dl.dropboxusercontent.com/u/14917452/SS3.zip http://localhost:8080/installSS
You know, SS3 is one of the two only reasons I have made the Squeak/Seaside all-in-one images. It is as if nobody cared about seaside in the squeak world anymore. It actually upsets me a little bit.
Neither activity has what it needs though -- someone with enough time and will to do it.
Best -Tobias
box-admins@lists.squeakfoundation.org