3.1 repo?
Locked
 
|
I've seen a couple of commits come in to the 3.0 repo... should we be
using the 3.1 repo now or...? Julian _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
On 5 October 2010 10:04, Julian Fitzell <[hidden email]> wrote:
> I've seen a couple of commits come in to the 3.0 repo... should we be > using the 3.1 repo now or...? Yes, definitely. So far this were just updates of Javascript libraries and the (critical) bug that Sebastian discovered yesterday in the in-place editor. Lukas -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
In reply to this post by Julian Fitzell-2
2010/10/5 Julian Fitzell <[hidden email]>:
> I've seen a couple of commits come in to the 3.0 repo... should we be > using the 3.1 repo now or...? I believe so but: - When that happens all deprecated methods need to go - We need to decide whether we want to change codec semantics (they're currently in 3.1) Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
2010/10/5 Philippe Marschall <[hidden email]>:
> 2010/10/5 Julian Fitzell <[hidden email]>: >> I've seen a couple of commits come in to the 3.0 repo... should we be >> using the 3.1 repo now or...? > > I believe so but: > - When that happens all deprecated methods need to go > - We need to decide whether we want to change codec semantics > (they're currently in 3.1) Bump, let me summarize what that would probably mean: - GRCodec >> #encode: would take a String and answer a ByteArray - GRCode >> #decode: would take a ByteArray and answer a String The advantage of that would be to have a better, clear separation of byte oriented data (ByteArray) and character oriented data (String). This would potentially help to catch encoding errors earlier. Here's a guess what the implications of this are based on the individual dialects: Pharo: All TextConverter (WAPharoGenricCodec) based converters would stop working (anything but UTF-8 and ISO-8859-1). If needed, they could be rewritten. VW: AFAIK would better work with their existing infrastructure. GemStone: Would probably have to change their UTF-8 code. AFAIK some of it is primitive based so that might get a bit awkward. VAST: AFAIK they're not supporting UTF-8 anyway so it shouldn't be that big of a change. GST: dunno Dolphin: dunno There's still a place left where there's a mix of byte and character oriented data and that's URLs. Encoding works like this: 1. encode using the URL codec 2. escape URL unsafe characters 3. escape HTML unsafe characters 4. encode with the page encoding The problem is step 1 will now deliver a ByteArray (which is technically correct) but step 2 and 3 expect a String. Step 2 could be changed to work with a ByteArray but step 3 can't. So we still need a way to go from ByteArray to String without an encoding. Decoding OTHO shouldn't work quite straight forward. guessed performance implications on Pharo: We'll likely loose performance for the ISO-8859-1 and UTF-8 encoding because we'll no longer be able to write from one collection to an other without conversion. We could theoretically get around this if write a custom WriteStream that doesn't check the collection class. Depending on the solution chosen for URL encoding we might end up losing our URL encoding shortcut (#includesUnsafeUrlCharacter:) which is likely going to degrade performance on link intensive pages. The corresponding primitive could easily be written for ByteArray but I'm not sure we want to go that way. Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
On 10/23/2010 07:47 PM, Philippe Marschall wrote:
> GST: > dunno Needs small changes, but with proper unit tests it should not be a problem. > There's still a place left where there's a mix of byte and character > oriented data and that's URLs. Encoding works like this: > 1. encode using the URL codec > 2. escape URL unsafe characters > 3. escape HTML unsafe characters > 4. encode with the page encoding > > The problem is step 1 will now deliver a ByteArray (which is > technically correct) but step 2 and 3 expect a String. Step 2 could be > changed to work with a ByteArray but step 3 can't. So we still need a > way to go from ByteArray to String without an encoding. At step 3 you should have only ASCII characters, so making (2) output a String should be trivial. > Depending on the solution chosen for URL encoding we might end up > losing our URL encoding shortcut (#includesUnsafeUrlCharacter:) which > is likely going to degrade performance on link intensive pages. The > corresponding primitive could easily be written for ByteArray but I'm > not sure we want to go that way. Maybe the String primitive just works if you add it to ByteArray. Dunno about Squeak, but it's often the case for these primitives in GST. Paolo _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
2010/10/23 Paolo Bonzini <[hidden email]>:
> On 10/23/2010 07:47 PM, Philippe Marschall wrote: >> >> GST: >> dunno > > Needs small changes, but with proper unit tests it should not be a problem. > >> There's still a place left where there's a mix of byte and character >> oriented data and that's URLs. Encoding works like this: >> 1. encode using the URL codec >> 2. escape URL unsafe characters >> 3. escape HTML unsafe characters >> 4. encode with the page encoding >> >> The problem is step 1 will now deliver a ByteArray (which is >> technically correct) but step 2 and 3 expect a String. Step 2 could be >> changed to work with a ByteArray but step 3 can't. So we still need a >> way to go from ByteArray to String without an encoding. > > At step 3 you should have only ASCII characters, so making (2) output a > String should be trivial. > >> Depending on the solution chosen for URL encoding we might end up >> losing our URL encoding shortcut (#includesUnsafeUrlCharacter:) which >> is likely going to degrade performance on link intensive pages. The >> corresponding primitive could easily be written for ByteArray but I'm >> not sure we want to go that way. > > Maybe the String primitive just works if you add it to ByteArray. Dunno > about Squeak, but it's often the case for these primitives in GST. Indeed it does, so much for strong typing. Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
In reply to this post by Philippe Marschall
On 10/23/2010 10:47 AM, Philippe Marschall wrote:
> 2010/10/5 Philippe Marschall<[hidden email]>: >> 2010/10/5 Julian Fitzell<[hidden email]>: >>> I've seen a couple of commits come in to the 3.0 repo... should we be >>> using the 3.1 repo now or...? >> >> I believe so but: >> - When that happens all deprecated methods need to go >> - We need to decide whether we want to change codec semantics >> (they're currently in 3.1) > > Bump, let me summarize what that would probably mean: > - GRCodec>> #encode: would take a String and answer a ByteArray > - GRCode>> #decode: would take a ByteArray and answer a String > > The advantage of that would be to have a better, clear separation of > byte oriented data (ByteArray) and character oriented data (String). > This would potentially help to catch encoding errors earlier. > > Here's a guess what the implications of this are based on the > individual dialects: > > Pharo: > All TextConverter (WAPharoGenricCodec) based converters would stop > working (anything but UTF-8 and ISO-8859-1). If needed, they could be > rewritten. > > VW: > AFAIK would better work with their existing infrastructure. > > GemStone: > Would probably have to change their UTF-8 code. AFAIK some of it is > primitive based so that might get a bit awkward. Yes. Even more awkward now that we are gearing up for a GemStone 3.0 release next summer...which means that we're not planning to add new features to the new 2.x line unless necessary ... If Seaside3.1 will be in development through next summer then it wouldn't be too hard to accomplish, but we'd like to have the decision made before the end of this year (that's when our beta is planned)... > > VAST: > AFAIK they're not supporting UTF-8 anyway so it shouldn't be that big > of a change. > > GST: > dunno > > Dolphin: > dunno > > There's still a place left where there's a mix of byte and character > oriented data and that's URLs. Encoding works like this: > 1. encode using the URL codec > 2. escape URL unsafe characters > 3. escape HTML unsafe characters > 4. encode with the page encoding > The problem is step 1 will now deliver a ByteArray (which is > technically correct) but step 2 and 3 expect a String. Step 2 could be > changed to work with a ByteArray but step 3 can't. So we still need a > way to go from ByteArray to String without an encoding. > > Decoding OTHO shouldn't work quite straight forward. > > guessed performance implications on Pharo: > We'll likely loose performance for the ISO-8859-1 and UTF-8 encoding > because we'll no longer be able to write from one collection to an > other without conversion. We could theoretically get around this if > write a custom WriteStream that doesn't check the collection class. > > Depending on the solution chosen for URL encoding we might end up > losing our URL encoding shortcut (#includesUnsafeUrlCharacter:) which > is likely going to degrade performance on link intensive pages. The > corresponding primitive could easily be written for ByteArray but I'm > not sure we want to go that way. > > Cheers > Philippe > _______________________________________________ > seaside-dev mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
In reply to this post by Philippe Marschall
On 10/23/2010 11:37 AM, Philippe Marschall wrote:
> 2010/10/23 Paolo Bonzini<[hidden email]>: >> On 10/23/2010 07:47 PM, Philippe Marschall wrote: >>> >>> GST: >>> dunno >> >> Needs small changes, but with proper unit tests it should not be a problem. >> >>> There's still a place left where there's a mix of byte and character >>> oriented data and that's URLs. Encoding works like this: >>> 1. encode using the URL codec >>> 2. escape URL unsafe characters >>> 3. escape HTML unsafe characters >>> 4. encode with the page encoding >>> >>> The problem is step 1 will now deliver a ByteArray (which is >>> technically correct) but step 2 and 3 expect a String. Step 2 could be >>> changed to work with a ByteArray but step 3 can't. So we still need a >>> way to go from ByteArray to String without an encoding. >> >> At step 3 you should have only ASCII characters, so making (2) output a >> String should be trivial. >> >>> Depending on the solution chosen for URL encoding we might end up >>> losing our URL encoding shortcut (#includesUnsafeUrlCharacter:) which >>> is likely going to degrade performance on link intensive pages. The >>> corresponding primitive could easily be written for ByteArray but I'm >>> not sure we want to go that way. >> >> Maybe the String primitive just works if you add it to ByteArray. Dunno >> about Squeak, but it's often the case for these primitives in GST. > > Indeed it does, so much for strong typing. > I've just recently run into this in another project ... even better is that when the primitive fails, the failure code enforces the strong typing again:) Dale _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
In reply to this post by Dale Henrichs
2010/10/25 Dale Henrichs <[hidden email]>:
> On 10/23/2010 10:47 AM, Philippe Marschall wrote: >> >> 2010/10/5 Philippe Marschall<[hidden email]>: >>> >>> 2010/10/5 Julian Fitzell<[hidden email]>: >>>> >>>> I've seen a couple of commits come in to the 3.0 repo... should we be >>>> using the 3.1 repo now or...? >>> >>> I believe so but: >>> - When that happens all deprecated methods need to go >>> - We need to decide whether we want to change codec semantics >>> (they're currently in 3.1) >> >> Bump, let me summarize what that would probably mean: >> - GRCodec>> #encode: would take a String and answer a ByteArray >> - GRCode>> #decode: would take a ByteArray and answer a String >> >> The advantage of that would be to have a better, clear separation of >> byte oriented data (ByteArray) and character oriented data (String). >> This would potentially help to catch encoding errors earlier. >> >> Here's a guess what the implications of this are based on the >> individual dialects: >> >> Pharo: >> All TextConverter (WAPharoGenricCodec) based converters would stop >> working (anything but UTF-8 and ISO-8859-1). If needed, they could be >> rewritten. >> >> VW: >> AFAIK would better work with their existing infrastructure. >> >> GemStone: >> Would probably have to change their UTF-8 code. AFAIK some of it is >> primitive based so that might get a bit awkward. > > Yes. Even more awkward now that we are gearing up for a GemStone 3.0 release > next summer...which means that we're not planning to add new features to the > new 2.x line unless necessary ... If Seaside3.1 will be in development > through next summer then it wouldn't be too hard to accomplish, but we'd > like to have the decision made before the end of this year (that's when our > beta is planned)... Given how terrible we are at planning and the consequences of this change I propose to postpone it. Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
On Wed, Nov 3, 2010 at 7:09 PM, Philippe Marschall
<[hidden email]> wrote: > 2010/10/25 Dale Henrichs <[hidden email]>: >>> Bump, let me summarize what that would probably mean: >>> - GRCodec>> #encode: would take a String and answer a ByteArray >>> - GRCode>> #decode: would take a ByteArray and answer a String >>> >>> The advantage of that would be to have a better, clear separation of >>> byte oriented data (ByteArray) and character oriented data (String). >>> This would potentially help to catch encoding errors earlier. >>> >>> Here's a guess what the implications of this are based on the >>> individual dialects: >>> >>> Pharo: >>> All TextConverter (WAPharoGenricCodec) based converters would stop >>> working (anything but UTF-8 and ISO-8859-1). If needed, they could be >>> rewritten. >>> >>> VW: >>> AFAIK would better work with their existing infrastructure. >>> >>> GemStone: >>> Would probably have to change their UTF-8 code. AFAIK some of it is >>> primitive based so that might get a bit awkward. >> >> Yes. Even more awkward now that we are gearing up for a GemStone 3.0 release >> next summer...which means that we're not planning to add new features to the >> new 2.x line unless necessary ... If Seaside3.1 will be in development >> through next summer then it wouldn't be too hard to accomplish, but we'd >> like to have the decision made before the end of this year (that's when our >> beta is planned)... > > Given how terrible we are at planning and the consequences of this > change I propose to postpone it. Or alternatively, let's just do that change on a branch. Chances of us releasing 3.1 before summer are probably pretty low anyway and if we really find we want to, we can just not merge that branch in until 3.2. If we "postpone" it, there's no chance of having it done for the summer. Julian _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
2010/11/4 Julian Fitzell <[hidden email]>:
> On Wed, Nov 3, 2010 at 7:09 PM, Philippe Marschall > <[hidden email]> wrote: >> 2010/10/25 Dale Henrichs <[hidden email]>: >>>> Bump, let me summarize what that would probably mean: >>>> - GRCodec>> #encode: would take a String and answer a ByteArray >>>> - GRCode>> #decode: would take a ByteArray and answer a String >>>> >>>> The advantage of that would be to have a better, clear separation of >>>> byte oriented data (ByteArray) and character oriented data (String). >>>> This would potentially help to catch encoding errors earlier. >>>> >>>> Here's a guess what the implications of this are based on the >>>> individual dialects: >>>> >>>> Pharo: >>>> All TextConverter (WAPharoGenricCodec) based converters would stop >>>> working (anything but UTF-8 and ISO-8859-1). If needed, they could be >>>> rewritten. >>>> >>>> VW: >>>> AFAIK would better work with their existing infrastructure. >>>> >>>> GemStone: >>>> Would probably have to change their UTF-8 code. AFAIK some of it is >>>> primitive based so that might get a bit awkward. >>> >>> Yes. Even more awkward now that we are gearing up for a GemStone 3.0 release >>> next summer...which means that we're not planning to add new features to the >>> new 2.x line unless necessary ... If Seaside3.1 will be in development >>> through next summer then it wouldn't be too hard to accomplish, but we'd >>> like to have the decision made before the end of this year (that's when our >>> beta is planned)... >> >> Given how terrible we are at planning and the consequences of this >> change I propose to postpone it. > > Or alternatively, let's just do that change on a branch. Chances of us > releasing 3.1 before summer are probably pretty low anyway and if we > really find we want to, we can just not merge that branch in until > 3.2. It's the only committed so far in the 3.1 repo. We can just move it some place else or not merge it. Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
«
Return to Seaside Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |