[Glass] Grease and Seaside31

Hi Dale,

I defined a tag '3.1.1-gs31' for Seaside 3.1.1 in ConfigurationOfSeaside3-JohanBrichau.145

        spec for: #'gs3.x' do: [
                spec baseline: 'Seaside3' with: [
                                spec repository: 'github://glassdb/Seaside31:3.1.1-gs31/repository' ]. ].

So, I think that 3.1.1 is always loading that specific release, no?

Note that I tried explicitly writing the ConfigurationOfSeaside such that Grease for Gemstone was fetched from the github repository, but I encountered some troubles. I think we exchanged some mails about that either on this list or the metacello group, but I cannot put my hands on them for now. I will keep looking.

cheers
Johan

On 04 Jun 2014, at 20:38, Dale Henrichs <[hidden email]> wrote:

> I am starting to get busy characterizing and fixing Seaside3.1.1 issue #21[1].
>
> The issue involves UTF8 performance and a fair amount of the UTF8 support is located in the Grease project.
>
>  Sooo, I am inclined to start using the Github-based Grease repository ... the packages are all synchronized with the packages on smalltalk hub (thanks Johan!).
>
> The upshot will be that Seaside3.1.1 will still use ConfigurationOfGrease, but just as Johan has done for ConfigurationOfSeaside3, the configuration will directly reference the github repository.
>
> BTW, Johan, I notice that the reference in ConfgurationOfSeaside# that you did not point to a specific SHA, which means that folks loading Seaside3.1.1.1 could get different versions. I think it should be frozen at 9c53917253e0512a8a3ffd569b6d20fea8c5179e... what do you think?
>
> Dale
>
> [1] https://github.com/glassdb/Seaside31/issues/21

> _______________________________________________
> Glass mailing list
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass

On Wed, Jun 4, 2014 at 8:38 PM, Dale Henrichs
<[hidden email]> wrote:
> I am starting to get busy characterizing and fixing Seaside3.1.1 issue
> #21[1].

Producing a byte array is "the right thing to do ™". That Seaside
currently expects is an unfortunate Squeak-ism that slipped into the
design. I believe this has already popped up once (maybe for VW) but I
can't remember what came out of this.

There are a couple of things to consider:

 * Most strings that we render are HTML safe ASCII. The fastest way to
render these is to do a quick test (we use CharacterSet on Pharo) and
then copy them directly into the response buffer. You can make you own
subclass of WAResponse to facilitate this.
 * All UTF-8 related tests should be in a custom packages.
 * URL rendering is also affected since we need to convert convert it
to a byte array before escaping it and sending it through the HTML
pipeline (and encoding it a second time)

Cheers
Philippe