WAUrlTest>>testFragment

Hi,

I'm currently using 2.8a1-pmm.411 and #testFragment fails in both Squeak
and VisualWorks. Has anyone fixed this in a newer version?

On the subject of tests - there's some weirdism with the test
#testCompileByteArraySource. In VW, it goes down a path of
#compileUseNewCompiler as the default is ^true.. this won't output a
'cache' variable and therefore the source doesn't match up. The test
assumes that the compileUseNewCompiler is false but has no way to ensure
that.

It gets weirder, since the non-useNewCompiler path goes in to a method
that says "Should never come here" - this may be Michel's VW
implementation here, but it will also not match up because it outputs
xxxCache and not cache as the temporary variable.

I guess I'm okay with it going through the non-caching path, etc, but
I'm curious as to what people think could/should be done with the test -
since I'd much rather have all the tests passing in both Squeak and
VisualWorks.

Cheers,
Michael
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> I'm currently using 2.8a1-pmm.411 and #testFragment fails in both Squeak
> and VisualWorks. Has anyone fixed this in a newer version?

This documents a bug (or problem) in the current code. As far as I
know it hasn't been fixed up to now. I have some much better URL code
ready, that fixes this and some other issues of WAUrl. It will also
allow to parse strings to URL objects, so that we have first-class
entitties that we can properly manipulate everywhere. The code is
partly based on the one of GNU Smalltalk's URL class, but backward
compatible to the one of Seaside. It will take some time to adapt
these changes.

Cheers,
Lukas


--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/7/24, Michael Lucas-Smith <[hidden email]>:
That's true. The test is broken, it tests platform specific stuff.
I'll recategorize it and make it work with new compiler.

> It gets weirder, since the non-useNewCompiler path goes in to a method
> that says "Should never come here" - this may be Michel's VW
> implementation here,

quite surely

> but it will also not match up because it outputs
> xxxCache and not cache as the temporary variable.

Probably the VW version hasn't been updated. I prefer xxxCache because
caching it's an ugly hack, this marks it as such and avoids shadowing
problems with instance variables. VW doesn't need this ugly hack since
it has bytearray literals. A wrote a transformation tool based on RB
that would transform methods to use bytearray literals. This could be
automatically done on exporting to VW but there was no interest in
this so far.

Cheers
Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 24 Jul 2007, at 09:34 , Philippe Marschall wrote:


>
> Probably the VW version hasn't been updated. I prefer xxxCache because
> caching it's an ugly hack, this marks it as such and avoids shadowing
> problems with instance variables. VW doesn't need this ugly hack since
> it has bytearray literals. A wrote a transformation tool based on RB
> that would transform methods to use bytearray literals. This could be
> automatically done on exporting to VW but there was no interest in
> this so far.
>

The VW versions can generate the methods in three flavors.
- xxxCache
- byte array literals
- packed strings

xxxCache generation is used when #compileUseNewCompiler is false.

The Squeak compatibility layer provides support for Squeak preferences.
This allows the port of the Squeak code that rely of these preferences.
Out of the box #compileUseNewCompiler is set to true by the Squeak
compatibility layer.
FYI, preference #showDeprecationWarnings is also supported by the
Squeak compatibility layer, although I do not remember what it is  
used for.

Since #compileUseNewCompiler is set to false, xxxCache generation
is never used. That's why the VW method in charge of xxxCache has this
strange comment "should not come here".

byte array literals are used when #favorStorage answers false.
packed strings are used when #favorStorage answers true.
Out of the box, #favorStorage answers false.

The current VW port mechanism would accept whatever comes from Squeak,
whether it is using xxxCache or byte arrays. At the moment all  
versions are
based on xxxCache. I have not yet seen byte arrays in use in Squeak.

To summarize the above: when new binary files are uploaded into file  
libraries,
their corresponding methods are generated using byte arrays. However  
those
binary files that were ported from Squeak are based on xxxCache. This  
mix
is perfectly legal.

I think this should be simplified: we should get rid of xxxCache  
generation
in VW and rework the corresponding code in SeasidePlatformSupport.

Sooner or later.

HTH
Michel.


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 24 Jul 2007, at 09:34 , Philippe Marschall wrote:

On the other hand, the test could be reworked to perform two  
different assertions
based on #compileUseNewCompiler. The test would then pass in both Squeak
and VW.


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/7/24, Michel Bany <[hidden email]>:
But #compileUseNewCompiler really only makes sense on Squeak. If we
want to keep that we should rename it to #useByteArrayLiterals which
on Squeak would send Preferences compileUseNewCompiler and on VW do
whatever makes sense there.

Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Philippe Marschall wrote: Which category? *seaside2-squeak ?

Michael
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

 

> > That's true. The test is broken, it tests platform specific stuff.
> > I'll recategorize it and make it work with new compiler.
> >
> Which category? *seaside2-squeak ?

Michael,

Just to clarify: category *seaside2-squeak would not exclude the method
from being exported. This rule only applies for extension methods, i.e.
methods that are added to classes that do not belong to the package.

Of course new export rules could be added to the exporter to exclude
methods from classes that belong to the package, but this has not been
done yet.

That said, I'd like Philippe to explain what effect he is expecting
from the recategorization. Could it be that Squeak selects a different
compiler based upon the method category?
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

 

As you like, but as it stands now, VW understands #compileUseNewCompiler
and would react correctly because it knows it is dealing with code
that comes from Squeak.

Of course it is better to spend some more time and make it right
as you suggest.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/7/24, Michael Lucas-Smith <[hidden email]>:
Seaside-Platform. I created SeasidePlatformSupport that tests for all
this this compilation related stuff. It has souce tests for new and
old compiler and sets the values. The test for the new compiler is
only run if the new compiler is present.  I'm not sure if its not
better to throw a failure instead because in this case we can't be
sure the test would succeed. Also categorization is tested, this was
broken in Squeak 3.8. SeasidePlatformSupport access Preferences now
only through the accesssor #useByteArrayLiterals.

So now dialects can implement SeasiePlatformSupport >>
#asMethodReturningByteArray:named: how they see fit.

Cheers Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/7/24, Philippe Marschall <[hidden email]>:
That should read, I created the class WAPlatformSpecificTest in the
class category Seaside-Platform. See Seaside2.8a1-pmm.413. Sorry.

Cheers
Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside