RingDing/4.1.0 Production Release

Re: RingDing/4.1.0 Production Release

There's been a minor update to bring back the installation instructions 
- see r10142.  This is building now!

Mamye Kratt wrote:
> The RingDing/4.1.0 release can be downloaded from:
> http://download.openlaszlo.org/nightly/trunk/10138
>  
> The RingDing/4.1.0 release is deployed at:
> http://www.openlaszlo.org/lps4.1/
>  
> The release, r10138 has been tagged 4.1.0 in svn.
>  
> Thanks,
> Mamye

--

-- 
Regards,
Max Carlson
OpenLaszlo.org

Re: Simple idea on how to update dynamic instantiation of user classes

For Review: Change 20080630-maxcarlson-j Summary: Update lztestmanager and data test suite to run in swf9

Change 20080630-maxcarlson-j by maxcarlson <at> Roboto on 2008-06-30  
19:13:47 PDT
     in /Users/maxcarlson/openlaszlo/trunk-clean
     for http://svn.openlaszlo.org/openlaszlo/trunk

Summary: Update lztestmanager and data test suite to run in swf9

Bugs Fixed: LPP-6574 - swf9: lztestmanager fails to run

Technical Reviewer: promanik
QA Reviewer: ptw

Details: viewperf.lzx - Update to use lz.* when newing classes.

datanode.lzx - Use local variable for test, provide arg to  
LzDataElement constructor.

datapath.lzx - Add missing attributes, rename bag argument var.

alldata.lzs - Don't require the debugger (for swf9)

xmlequals.lzx - Add missing args

lztestmanager.lzx - Fix failure messages to be clearer

lzunit.lzx - Move top-level function declarations to methods on  
DebugObject, update optional args to use ... syntax.

Tests: /test/lfc/data/alldata.lzx?lzr=swf9 now compiles, but fails  
with runtime warnings.  This test runs as before in swf8 and dhtml.

Files:
M      test/lfc/perf/viewperf.lzx
M      test/lfc/data/datanode.lzx
M      test/lfc/data/datapath.lzx
M      test/lfc/data/alldata.lzx
M      lps/components/lztest/xmlequals.lzx
M      lps/components/lztest/lztestmanager.lzx
M      lps/components/lzunit/lzunit.lzx

Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20080630-maxcarlson-j.tar

Re: Simple idea on how to update dynamic instantiation of user classes

On 2008-06-30, at 18:21 EDT, Donald Anderson wrote:

> Here's the perl script (attached).  I tried to upload it to the  
> Runtime_Differences page,
> but it looks like I can only update .gif/.jpeg files.  Any advice  
> about where to put it?

The other conversion script is in WEB-INF/lps/server/bin (not that  
that is the right place, but it is where lzc and other scripts are, so  
should already be in the search path of most developers who will need  
this script).

> I think I got all the cases:
>
> -   if the class name already has lz. , no change

Correct.

> -   if the class name is a class defined in the input, then add lz.  
> (?)  [requires two passes]

Correct.  All LZX classes defined with <class name="foo"... must be  
referenced as lz.foo in `new` and `instanceof`.

> -   if the class name is class for a LFC tagname, convert it to  
> tagname and add lz.  (new LzView => lz.view)
>         I coded my list from WEB-INF/lps/server/src/org/openlaszlo/ 
> compiler/ClassModel.java

Optional, but good practice.

> -   if the class name is a known laszlo class, then add lz.
>         I have a fixed list embedded in the script, generated via  
> find WEB-INF/lps | xargs grep class

No.  Only LFC classes that implement LZX tags should be converted, and  
that is covered by the previous step.

[Detail:  Script class definitions _do_ create global definitions.   
Eventually we will want these in a laszlo namespace, but that will be  
by `use namespace` or something.  Certain LFC script classes implement  
tags and are entered into the `lz` namespace by hand in the LFC.   
E.g., if you look at the bottom of the file defining LzView, you will  
see:

   lz[LzView.tagname] = LzView;

That little bit of glue attaches the LFC implementation to the LZX  
interface.]

> -   new global[*] is converted to new lz[*]

Correct, unless the user code is doing something really tricky.   
Perhaps the script should announce when it is making this transform,  
as it should be manually verified.

> -   otherwise, no change (this includes Object, Array, ...).

Correct.

> Let me know if there are any changes, should be easy to modify.
> Script includes a testcase to try all these situations.

Once the above fixes are made, how about sending out a regular review  
request.  Perhaps Sebastian would like to be one of the reviewers.

> - Don
>
> <convert_instantiation.pl>
>
> On Jun 30, 2008, at 3:01 PM, P T Withington wrote:
>
>> One flaw in thus idea:  many times the argument to new will be a  
>> parameter of the class, so you have to skip all the class  
>> attributes too. That may make searching for only the defined class  
>> names a better choice of algorithm.
>>
>> On Jun 30, 2008, at 13:59, P T Withington <ptw <at> pobox.com> wrote:
>>
>>> The only 'native' classes that you might say `new *` or `x  
>>> instanceof *` about are:
>>>
>>> Object, Array, String, Number, or Boolean.
>>>
>>> So we should be able to add to the conversion script that if you  
>>> see `new *` or `x instanceof *` and * does not start with lz. and  
>>> is not one of the five native classes above, you should rewrite it  
>>> to lz.*.
>>>
>>> We also need to cover the case `new global[*]` needs to become  
>>> `new lz[*]`.
>>>
>>> Icing on the cake would be to replace instances of the LFC class  
>>> names with their tagname, e.g., (LzView becomes lz.view).
>>>
>
>
> --
>
> Don Anderson
> Java/C/C++, Berkeley DB, systems consultant
>
> voice: 617-547-7881
> email: dda <at> ddanderson.com
> www: http://www.ddanderson.com
>
>
>

Re: For Review: Change 20080630-maxcarlson-j Summary: Update lztestmanager and data test suite to run in swf9

Cool!  Approved.

On 2008-06-30, at 22:28 EDT, Max Carlson wrote:

> Change 20080630-maxcarlson-j by maxcarlson <at> Roboto on 2008-06-30  
> 19:13:47 PDT
>    in /Users/maxcarlson/openlaszlo/trunk-clean
>    for http://svn.openlaszlo.org/openlaszlo/trunk
>
> Summary: Update lztestmanager and data test suite to run in swf9
>
> Bugs Fixed: LPP-6574 - swf9: lztestmanager fails to run
>
> Technical Reviewer: promanik
> QA Reviewer: ptw
>
> Details: viewperf.lzx - Update to use lz.* when newing classes.
>
> datanode.lzx - Use local variable for test, provide arg to  
> LzDataElement constructor.
>
> datapath.lzx - Add missing attributes, rename bag argument var.
>
> alldata.lzs - Don't require the debugger (for swf9)
>
> xmlequals.lzx - Add missing args
>
> lztestmanager.lzx - Fix failure messages to be clearer
>
> lzunit.lzx - Move top-level function declarations to methods on  
> DebugObject, update optional args to use ... syntax.
>
> Tests: /test/lfc/data/alldata.lzx?lzr=swf9 now compiles, but fails  
> with runtime warnings.  This test runs as before in swf8 and dhtml.
>
> Files:
> M      test/lfc/perf/viewperf.lzx
> M      test/lfc/data/datanode.lzx
> M      test/lfc/data/datapath.lzx
> M      test/lfc/data/alldata.lzx
> M      lps/components/lztest/xmlequals.lzx
> M      lps/components/lztest/lztestmanager.lzx
> M      lps/components/lzunit/lzunit.lzx
>
> Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20080630-maxcarlson-j.tar

Re: Simple idea on how to update dynamic instantiation of user classes

Right.  I sent the same caveat to Don.  His final script will be  
driven off the defined classes.

Even so, the script will not be able to find all the cases that need  
updating because it is only going to do trivial analysis, looking for  
tag names as arguments to `new` and `instanceof` and replacing them  
with class names.

I am working on some better compile-time warnings.

You will always get a runtime warning in debug mode because you will  
be calling `new` or `instanceof` on undefined.

On 2008-06-30, at 14:55 EDT, André Bargull wrote:

> What happens if I you write:
>> var clazz:Class = lz.view;
>> new clazz();
>> new LzDataElement("entry", {}, null);
>
> In these cases, you must not rewrite it to
>> new lz.clazz();
>> new lz.LzDataElement("entry", {}, null);
>
>> The only 'native' classes that you might say `new *` or `x  
>> instanceof  *` about are:
>>
>>   Object, Array, String, Number, or Boolean.
>>
>> So we should be able to add to the conversion script that if you  
>> see  `new *` or `x instanceof *` and * does not start with lz. and  
>> is not  one of the five native classes above, you should rewrite it  
>> to lz.*.
>>
>> We also need to cover the case `new global[*]` needs to become  
>> `new  lz[*]`.
>>
>> Icing on the cake would be to replace instances of the LFC class  
>> names  with their tagname, e.g., (LzView becomes lz.view).
>

Re: Simple idea on how to update dynamic instantiation of user classes

Re: Simple idea on how to update dynamic instantiation of user classes

On 2008-07-01, at 08:32 EDT, Donald Anderson wrote:

>>> -   if the class name is a class defined in the input, then add  
>>> lz. (?)  [requires two passes]
>>
>> Correct.  All LZX classes defined with <class name="foo"... must be  
>> referenced as lz.foo in `new` and `instanceof`.
>
> I'm a little confused.  I thought this script only converted .lzs  
> files.
> It sounds like the script operates on and converts both, but we  
> should only collect the class names
> I see in LZX on the first pass.   ??

Yes the script is for LZX files.  Yes the script should accumulate  
class names in first pass (by looking for <class name="...", probably  
also <interface name="...", just in case).  But you can't just replace  
class names with lz.<name> everywhere.  You should only replace it  
when they are an operand of a `new` or `instanceof` operator.

Why?  Because in the old days, <class name="foo" ... defined both a  
tag 'foo' and a class 'foo'.  Now, we separate those two concepts.

In LZX you can create an instance of an LZX class either by using the  
tag in declarative code:

   <foo />

_or_ by using `new` and the class in script:

   <method ...>
     new ¿foo? ;
   </method>

You used to say `new foo`, but now the actual class is (effectively)  
in a private namespace, so that it won't clutter up the global  
namespace.  Instead, we build a mapping from tag name to class, so  
that you can get at the class that implements a tag by saying  
`lz['foo']` (which for a constant tag can be abbreviated `lz.foo`).

But!

A common idiom in components was to say:

   <class name="complex">
     <attribute name="subviewClass" type="String" />
     <method ...>
       new global[subviewClass](...);
     </method>

In this case, `subviewClass` _really_ meant subviewTag.  The user  
would pass the tag name (as a string) for the type of subview they  
wanted.  So you would invoke it:

   <complex subviewClass="text" />

In the new world, all you want to do is change `global` to `lz`.  You  
don't want to change `text` to `lz.text`.

For Review: Change 20080701-ptw-H Summary: Distribute .css files

[Submitting so it can be reviewed by inspecting the nightly build.]

Change 20080701-ptw-H by ptw <at> dueling-banjos.local on 2008-07-01  
09:41:32 EDT
     in /Users/ptw/OpenLaszlo/ringding-clean
     for http://svn.openlaszlo.org/openlaszlo/trunk

Summary: Distribute .css files

Bugs Fixed:
LPP-6578 'Change ant build script to include css file needed by rel  
notes'

Technical Reviewer: liorio (pending)
QA Reviewer: mamye (pending)

Details:
     Copy .css files.

Tests:
     Inspect the next nightly

Files:
M      build.xml

Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20080701-ptw-H.tar