Nabble - OpenLaszlo - Dev

Rethink - Write once run everywhere

2009-11-27T04:07:52Z

hi,

I've added some ... maybe contra-revolutionary ^^ points to the wiki... so don't take that too personal but I think its worth thinking about!

http://wiki.openlaszlo.org/OpenLaszlo_5_community_wishlist

General

Rethink pattern of *Write once, run everywhere*, it seems not to be feasible in the future or only with enormous effort. So its maybe better and cleaner to have different component sets for each Runtime, instead of trying to build ONE component set that then compiles into all runtimes (cause the code that produces those components has almost more exceptions then it has code that is equal among all platforms). So maybe you just make some basic definitions like:

view in dhtml = div

view in SWF8 = MovieClip

view in SWF9 = sprite

But based on that you can than work in different folders and component sets. Of course that means duplicate code in some areas but on the long run you need a team with 20+ permanent core developers to keep track of all runtimes. And a change ... even minimalistic things, in one runtime does effect automatically all runtimes. And what happens when you add a new runtime now? SVG or Silverlight or ... actually the complexity of even very simple things will be that kind of horrible that its almost a Science to bring a simple Hello World-Text component into all Runtimes.

And I think for some of the CSS or Flash10 features you just find no equivalent into the other runtimes. So the things that those runtimes have in common is getting smaller and smaller ... and you fill your time in fixing those runtime-gaps instead of improving and extending the Platform with new features.

just my two cents ^^
Sebastian

--
Sebastian Wagner
http://www.webbase-design.de
http://openmeetings.googlecode.com
http://www.laszlo-forum.de
seba.wagner@...

Re: [Laszlo-user] Looking for a faster grid

2009-11-25T07:36:32Z

hi,

I have build such a component, you can scroll through 10 or 1000 items, it makes not difference from the rendering point of view.
If you want to I can show you an example implementation in a live application.

Sebastian

2009/11/25 Andy Humphries <andy.humphries@...>

We have a pretty large OpenLaszlo application and on the whole I am very happy with what we have been able to achieve with it (as are our customers) however when we construct grids with large numbers of columns e.g. 50+, the grids are very slow at building each row.

We’re about to embark on building our own “lighter” grid component to reduce the heavy work that goes on underneath however before we did that I just wanted to check if anyone has experienced the same problem, has any tips, or indeed has a component they can share?

Cheers,

Andy

--
Sebastian Wagner
http://www.webbase-design.de
http://openmeetings.googlecode.com
http://www.laszlo-forum.de
seba.wagner@...

Re: createChildren

2009-11-25T06:52:26Z

On 2009-11-25, at 08:33, Rami Ojares / AMG Oy wrote:

>
> > I think the documentation on makeChild is more accurate.
>
> Unfortunately makeChild is marked as private and thus is not part of the documentation.

I agree. I wasn't clear: the documentation from makeChild should be on createChildren (or at least copied there). This should be filed as a bug.

> > createChildren is really just a hook to allow a subclass to change where and when it actually makes its children.
>
> I have done a splitpane that automatically creates a divider for each pane. Fairly normal and straightforward use case. So I think createChildren is a very powerful place for overrides and strongly suggest it is kept as part of the official api.

Agree.

> > c.name is still valid, it is used to make a child be of the class that implements a particular tag
>
> I don't think so.
>
> Code: (slightly modified from previous mail):
> -----
> <canvas debug="true">
> <view >
> <method name="createChildren" args="children"><![CDATA[
> for(var i=0; i<children.length; i++) {
> Debug.inspect(children[i]);
> }
> ]]></method>
> <view height="${canvas.height}"/>
> <view/>
> </view>
> </canvas>
>
> Output:
> -------
> «Object#0» {
> attrs: {…, height: $always{canvas.height}}
> class: <anonymous view>
> }
> «Object#4» {
> attrs: {…}
> class: <view>
> }

I guess I wasn't clear. `name` is still permitted and will be recognized and it is the easiest way for script to instantiate a particular tag. The compiler makes an optimization:

{name: 'view', attrs: ...} => {class: lz['view'], attrs: ...}

That is, when the compiler knows that `name` is a constant, and it knows the class that implements that tag, it evaluates the lookup of the tag in `lz` at compile time and inserts the class.

> > c.class is an optimization, used by the compiler to:
> > 1) Avoid having to look up the name
> > 2) Instantiate 'instance classes'
>
> Is there any other way for me (or the compiler) to recognize tags/classes from each other? Because if not then the word "optimization" is incorrect.

For any tag foo, the class that implements that tag is lz['foo'].

In script, if you want to know if a node is an instance of a particular tag (say you want to know if it is a <foo>) you would say:

if (mynode is lz['foo']) ...

> > The tagname in this case, is just for debugging. If you were to look > at the non-debug version, you would see the tagname is not emitted.
>
> What do you mean with "non-debug" version?
> It is clear to me that if there is no debug window then I will not see the debug messages :-)

If you could (e.g., using a browser debugger in DHTML, or using fdb in SWF10), you would see that there is no `tagname` property on classes when debugging is off. Hence, you should not rely on that in production code.

> > That's how it is supposed to be.
>
> So can I now rely on the tagname of my Pane tag to be either "Pane" or "anonymous Pane" ?

If you are trying to detect instances of <Pane> (even anonymous ones, which would be subclasses), the recommended approach would be to use the `is` operator as above. But I see where your problem lies, you are trying to sort the child "specifications" before they have been instantiated. To be totally accurate, that means you would have to look for `name` _or_ `class`, and that you would need to know if the tag or class is a subclass of the tag's class you are sorting on.

Something like:

function isPane(c) {
if (c.name) {
var childClass = lz[c.name];
} else {
var childClass = c.class;
}
return lz['Pane'].prototype.isPrototypeOf(childClass.prototype);
}

[That last line is pretty obscure, we should probably offer a built-in `extends` or `isSubclassOf` predicate.]

> > Before, we never emitted a tagname for "instance classes".
>
> So was the
> - child['class'].tagname
> previously in my example case "undefined" or "Pane" (It must have been "Pane" because otherwise my SplitPane would not have worked previously.)

I see. Well, we had to introduce the class option because of the swf9/10 runtime, which forced us to create the anonymous classes. Hopfully the above code will help.

Re: createChildren

2009-11-25T05:33:40Z

> I think the documentation on makeChild is more accurate.

Unfortunately makeChild is marked as private and thus is not part of the
documentation.

> createChildren is really just a hook to allow a subclass to change
where and when it actually makes its children.

I have done a splitpane that automatically creates a divider for each
pane. Fairly normal and straightforward use case. So I think
createChildren is a very powerful place for overrides and strongly
suggest it is kept as part of the official api.

> c.name is still valid, it is used to make a child be of the class
that implements a particular tag

I don't think so.

Code: (slightly modified from previous mail):
-----
<canvas debug="true">
<view >
<method name="createChildren" args="children"><![CDATA[
for(var i=0; i<children.length; i++) {
Debug.inspect(children[i]);
}
]]></method>
<view height="${canvas.height}"/>
<view/>
</view>
</canvas>

Output:
-------
«Object#0» {
attrs: {…, height: $always{canvas.height}}
class: <anonymous view>
}
«Object#4» {
attrs: {…}
class: <view>
}

> c.class is an optimization, used by the compiler to:
> 1) Avoid having to look up the name
> 2) Instantiate 'instance classes'

Is there any other way for me (or the compiler) to recognize
tags/classes from each other? Because if not then the word
"optimization" is incorrect.

> The tagname in this case, is just for debugging. If you were to look
> at the non-debug version, you would see the tagname is not emitted.

What do you mean with "non-debug" version?
It is clear to me that if there is no debug window then I will not see
the debug messages :-)

> That's how it is supposed to be.

So can I now rely on the tagname of my Pane tag to be either "Pane" or
"anonymous Pane" ?

> Before, we never emitted a tagname for "instance classes".

So was the
- child['class'].tagname
previously in my example case "undefined" or "Pane" (It must have been
"Pane" because otherwise my SplitPane would not have worked previously.)

- rami

Re: createChildren

2009-11-24T16:35:23Z

Hum. Well, I would have expected interstitials to create themselves as anonymous classes. Maybe I missed that.

On 2009-11-24, at 19:27, Henry Minsky wrote:

> I think this predates that change, but I'll check the 'publish' flag logic
>
> On Tue, Nov 24, 2009 at 6:43 PM, P T Withington <ptw@...> wrote:
>
>> That's a bug then. Perhaps this has the same root as the regression you
>> just fixed?
>>
>> Nothing should go in lz unless it is really defining a tag.
>>
>> On 2009-11-24, at 18:23, Henry Minsky wrote:
>>
>>> Hmm, now that you mention it, I notice we've been adding the
>> interstitial
>>> class names that come from compiling class mixins to the lz namespace
>>> object:
>>>
>>> lz["colored_square$view"] = $lzc$class_colored_square$view;
>>> lz["black_line$colored_square$view"] =
>>> $lzc$class_black_line$colored_square$view;
>>>
>>>
>>> I don't think we need them in there, do we? The compiler seems to be
>>> emitting
>>> calls to instantiate the objects directly using the classname when it
>> calls
>>> LzInstantiateView e.g.,
>>>
>>> "class": $lzc$class_black_line$colored_square$view
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Nov 24, 2009 at 5:36 PM, P T Withington <ptw@...> wrote:
>>>
>>>> On 2009-11-24, at 17:01, Rami Ojares / AMG Oy wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Current documentation has this to say about node's createChildren(carr)
>>>> argument
>>>>>
>>>>> "an array of children where the structure of each child [c] takes the
>>>> form:
>>>>> c.name = a string containing the name of the child -- usually its
>>>> constructor
>>>>> c.args = a dictionary of attributes and values to be passed to the
>>>> constructor of that child
>>>>> c.children = an array of children for the new child"
>>>>
>>>> You are venturing into things that most people don't, since they just
>> use
>>>> the XML language for their applications.
>>>>
>>>> I think the documentation on makeChild is more accurate. createChildren
>> is
>>>> really just a hook to allow a subclass to change where and when it
>> actually
>>>> makes its children. makeChild is the interface that actually interprets
>> the
>>>> children specification. (Don't blame me for the confusing names, I did
>> not
>>>> make them up!)
>>>>
>>>> c.name is still valid, it is used to make a child be of the class that
>>>> implements a particular tag (so you say 'view' to get a <view>, etc.
>> You
>>>> can use this to make any node that has a tag).
>>>>
>>>> c.class is an optimization, used by the compiler to:
>>>>
>>>> 1) Avoid having to look up the name
>>>> 2) Instantiate 'instance classes'
>>>>
>>>>> None of this seems to be true.
>>>>> Instead the children seems to have the structure:
>>>>> c.attrs = a dictionary of attributes and values to be passed to the
>>>> constructor of that child
>>>>> c.class = pointer to the class to be instantiated
>>>>>
>>>>> When you further inspect the class there is one useful attribute:
>>>>> tagname. That seems to have the same function as c.name in the above
>>>> mentioned documentation.
>>>>>
>>>>> Further it seems that in the current trunk if you instantiate a class
>>>> with a constrained attribute like this
>>>>>
>>>>> <view height="${foo.height}"/>
>>>>>
>>>>> It's tagname becomes
>>>>> "anonymous tagname"
>>>>
>>>> Right. This is a so-called "instance class". In order to have a
>>>> constraint, an instance needs some supporting methods. (You would see
>> the
>>>> same thing if you gave your instance an explicit <method>.) In order to
>>>> have methods, the compiler has to build a class, and then make just one
>>>> instance of that class. It doesn't define a tag for that class, because
>> it
>>>> will only ever be made by the compiler (or by replication, which works
>>>> automatically). The tagname in this case, is just for debugging. If
>> you
>>>> were to look at the non-debug version, you would see the tagname is not
>>>> emitted. And of course, the class is _not_ entered into `lz` (as are
>> all
>>>> real class definitions, e.g., lz['view'] => the class that implements
>>>> <view>, so lz[<any tag name>].tagname == <any tag name>, but not for
>>>> 'anonymous' or 'instance' classes.)
>>>>
>>>>> Code:
>>>>>
>>>>> <canvas debug="true">
>>>>> <view >
>>>>> <method name="createChildren" args="children"><![CDATA[
>>>>> for(var i=0; i<children.length; i++) {
>>>>> Debug.write(children[i]['class'].tagname);
>>>>> }
>>>>> ]]></method>
>>>>> <view height="${canvas.height}"/>
>>>>> <view/>
>>>>> </view>
>>>>> </canvas>
>>>>>
>>>>> Produces the output in debug window:
>>>>> anonymous view
>>>>> view
>>>>>
>>>>> Is this how it is supposed to be?
>>>>
>>>> That's how it is supposed to be. :)
>>>>
>>>>> Or is this an accident caused by the instance specific mixin
>> development?
>>>>
>>>> Although, we did just add this feature to make it easier to debug
>> instance
>>>> mixin's. Before, we never emitted a tagname for "instance classes".
>> But we
>>>> decided it would help debugging to give them a tagname that told what
>> tag
>>>> they were derived from.
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Henry Minsky
>>> Software Architect
>>> hminsky@...
>>
>>
>
>
> --
> Henry Minsky
> Software Architect
> hminsky@...

Re: createChildren

2009-11-24T16:27:30Z

I think this predates that change, but I'll check the 'publish' flag logic

On Tue, Nov 24, 2009 at 6:43 PM, P T Withington <ptw@...> wrote:

That's a bug then. Perhaps this has the same root as the regression you just fixed?

Nothing should go in lz unless it is really defining a tag.

On 2009-11-24, at 18:23, Henry Minsky wrote:

> Hmm, now that you mention it, I notice we've been adding the interstitial
> class names that come from compiling class mixins to the lz namespace
> object:
>
> lz["colored_square$view"] = $lzc$class_colored_square$view;
> lz["black_line$colored_square$view"] =
> $lzc$class_black_line$colored_square$view;
>
>
> I don't think we need them in there, do we? The compiler seems to be
> emitting
> calls to instantiate the objects directly using the classname when it calls
> LzInstantiateView e.g.,
>
> "class": $lzc$class_black_line$colored_square$view
>
>
>
>
>
>
> On Tue, Nov 24, 2009 at 5:36 PM, P T Withington <ptw@...> wrote:
>
>> On 2009-11-24, at 17:01, Rami Ojares / AMG Oy wrote:
>>
>>> Hi,
>>>
>>> Current documentation has this to say about node's createChildren(carr)
>> argument
>>>
>>> "an array of children where the structure of each child [c] takes the
>> form:
>>> c.name = a string containing the name of the child -- usually its
>> constructor
>>> c.args = a dictionary of attributes and values to be passed to the
>> constructor of that child
>>> c.children = an array of children for the new child"
>>
>> You are venturing into things that most people don't, since they just use
>> the XML language for their applications.
>>
>> I think the documentation on makeChild is more accurate. createChildren is
>> really just a hook to allow a subclass to change where and when it actually
>> makes its children. makeChild is the interface that actually interprets the
>> children specification. (Don't blame me for the confusing names, I did not
>> make them up!)
>>
>> c.name is still valid, it is used to make a child be of the class that
>> implements a particular tag (so you say 'view' to get a <view>, etc. You
>> can use this to make any node that has a tag).
>>
>> c.class is an optimization, used by the compiler to:
>>
>> 1) Avoid having to look up the name
>> 2) Instantiate 'instance classes'
>>
>>> None of this seems to be true.
>>> Instead the children seems to have the structure:
>>> c.attrs = a dictionary of attributes and values to be passed to the
>> constructor of that child
>>> c.class = pointer to the class to be instantiated
>>>
>>> When you further inspect the class there is one useful attribute:
>>> tagname. That seems to have the same function as c.name in the above
>> mentioned documentation.
>>>
>>> Further it seems that in the current trunk if you instantiate a class
>> with a constrained attribute like this
>>>
>>> <view height="${foo.height}"/>
>>>
>>> It's tagname becomes
>>> "anonymous tagname"
>>
>> Right. This is a so-called "instance class". In order to have a
>> constraint, an instance needs some supporting methods. (You would see the
>> same thing if you gave your instance an explicit <method>.) In order to
>> have methods, the compiler has to build a class, and then make just one
>> instance of that class. It doesn't define a tag for that class, because it
>> will only ever be made by the compiler (or by replication, which works
>> automatically). The tagname in this case, is just for debugging. If you
>> were to look at the non-debug version, you would see the tagname is not
>> emitted. And of course, the class is _not_ entered into `lz` (as are all
>> real class definitions, e.g., lz['view'] => the class that implements
>> <view>, so lz[<any tag name>].tagname == <any tag name>, but not for
>> 'anonymous' or 'instance' classes.)
>>
>>> Code:
>>>
>>> <canvas debug="true">
>>> <view >
>>> <method name="createChildren" args="children"><![CDATA[
>>> for(var i=0; i<children.length; i++) {
>>> Debug.write(children[i]['class'].tagname);
>>> }
>>> ]]></method>
>>> <view height="${canvas.height}"/>
>>> <view/>
>>> </view>
>>> </canvas>
>>>
>>> Produces the output in debug window:
>>> anonymous view
>>> view
>>>
>>> Is this how it is supposed to be?
>>
>> That's how it is supposed to be. :)
>>
>>> Or is this an accident caused by the instance specific mixin development?
>>
>> Although, we did just add this feature to make it easier to debug instance
>> mixin's. Before, we never emitted a tagname for "instance classes". But we
>> decided it would help debugging to give them a tagname that told what tag
>> they were derived from.
>>
>>
>>
>
>
> --
> Henry Minsky
> Software Architect
> hminsky@...

--
Henry Minsky
Software Architect
hminsky@...

Re: createChildren

2009-11-24T15:55:17Z

There's a 'publish' flag in ClassModel that should be respected. It should be false for anything that does not come from an LZX <class> or from a built-in, and that should prevent any entry from going into `lz`.

On 2009-11-24, at 18:43, P T Withington wrote:

> That's a bug then. Perhaps this has the same root as the regression you just fixed?
>
> Nothing should go in lz unless it is really defining a tag.
>
> On 2009-11-24, at 18:23, Henry Minsky wrote:
>
>> Hmm, now that you mention it, I notice we've been adding the interstitial
>> class names that come from compiling class mixins to the lz namespace
>> object:
>>
>> lz["colored_square$view"] = $lzc$class_colored_square$view;
>> lz["black_line$colored_square$view"] =
>> $lzc$class_black_line$colored_square$view;
>>
>>
>> I don't think we need them in there, do we? The compiler seems to be
>> emitting
>> calls to instantiate the objects directly using the classname when it calls
>> LzInstantiateView e.g.,
>>
>> "class": $lzc$class_black_line$colored_square$view
>>
>>
>>
>>
>>
>>
>> On Tue, Nov 24, 2009 at 5:36 PM, P T Withington <ptw@...> wrote:
>>
>>> On 2009-11-24, at 17:01, Rami Ojares / AMG Oy wrote:
>>>
>>>> Hi,
>>>>
>>>> Current documentation has this to say about node's createChildren(carr)
>>> argument
>>>>
>>>> "an array of children where the structure of each child [c] takes the
>>> form:
>>>> c.name = a string containing the name of the child -- usually its
>>> constructor
>>>> c.args = a dictionary of attributes and values to be passed to the
>>> constructor of that child
>>>> c.children = an array of children for the new child"
>>>
>>> You are venturing into things that most people don't, since they just use
>>> the XML language for their applications.
>>>
>>> I think the documentation on makeChild is more accurate. createChildren is
>>> really just a hook to allow a subclass to change where and when it actually
>>> makes its children. makeChild is the interface that actually interprets the
>>> children specification. (Don't blame me for the confusing names, I did not
>>> make them up!)
>>>
>>> c.name is still valid, it is used to make a child be of the class that
>>> implements a particular tag (so you say 'view' to get a <view>, etc. You
>>> can use this to make any node that has a tag).
>>>
>>> c.class is an optimization, used by the compiler to:
>>>
>>> 1) Avoid having to look up the name
>>> 2) Instantiate 'instance classes'
>>>
>>>> None of this seems to be true.
>>>> Instead the children seems to have the structure:
>>>> c.attrs = a dictionary of attributes and values to be passed to the
>>> constructor of that child
>>>> c.class = pointer to the class to be instantiated
>>>>
>>>> When you further inspect the class there is one useful attribute:
>>>> tagname. That seems to have the same function as c.name in the above
>>> mentioned documentation.
>>>>
>>>> Further it seems that in the current trunk if you instantiate a class
>>> with a constrained attribute like this
>>>>
>>>> <view height="${foo.height}"/>
>>>>
>>>> It's tagname becomes
>>>> "anonymous tagname"
>>>
>>> Right. This is a so-called "instance class". In order to have a
>>> constraint, an instance needs some supporting methods. (You would see the
>>> same thing if you gave your instance an explicit <method>.) In order to
>>> have methods, the compiler has to build a class, and then make just one
>>> instance of that class. It doesn't define a tag for that class, because it
>>> will only ever be made by the compiler (or by replication, which works
>>> automatically). The tagname in this case, is just for debugging. If you
>>> were to look at the non-debug version, you would see the tagname is not
>>> emitted. And of course, the class is _not_ entered into `lz` (as are all
>>> real class definitions, e.g., lz['view'] => the class that implements
>>> <view>, so lz[<any tag name>].tagname == <any tag name>, but not for
>>> 'anonymous' or 'instance' classes.)
>>>
>>>> Code:
>>>>
>>>> <canvas debug="true">
>>>> <view >
>>>> <method name="createChildren" args="children"><![CDATA[
>>>> for(var i=0; i<children.length; i++) {
>>>> Debug.write(children[i]['class'].tagname);
>>>> }
>>>> ]]></method>
>>>> <view height="${canvas.height}"/>
>>>> <view/>
>>>> </view>
>>>> </canvas>
>>>>
>>>> Produces the output in debug window:
>>>> anonymous view
>>>> view
>>>>
>>>> Is this how it is supposed to be?
>>>
>>> That's how it is supposed to be. :)
>>>
>>>> Or is this an accident caused by the instance specific mixin development?
>>>
>>> Although, we did just add this feature to make it easier to debug instance
>>> mixin's. Before, we never emitted a tagname for "instance classes". But we
>>> decided it would help debugging to give them a tagname that told what tag
>>> they were derived from.
>>>
>>>
>>>
>>
>>
>> --
>> Henry Minsky
>> Software Architect
>> hminsky@...
>

Re: createChildren

2009-11-24T15:43:33Z

That's a bug then. Perhaps this has the same root as the regression you just fixed?

Nothing should go in lz unless it is really defining a tag.

On 2009-11-24, at 18:23, Henry Minsky wrote:

> Hmm, now that you mention it, I notice we've been adding the interstitial
> class names that come from compiling class mixins to the lz namespace
> object:
>
> lz["colored_square$view"] = $lzc$class_colored_square$view;
> lz["black_line$colored_square$view"] =
> $lzc$class_black_line$colored_square$view;
>
>
> I don't think we need them in there, do we? The compiler seems to be
> emitting
> calls to instantiate the objects directly using the classname when it calls
> LzInstantiateView e.g.,
>
> "class": $lzc$class_black_line$colored_square$view
>
>
>
>
>
>
> On Tue, Nov 24, 2009 at 5:36 PM, P T Withington <ptw@...> wrote:
>
>> On 2009-11-24, at 17:01, Rami Ojares / AMG Oy wrote:
>>
>>> Hi,
>>>
>>> Current documentation has this to say about node's createChildren(carr)
>> argument
>>>
>>> "an array of children where the structure of each child [c] takes the
>> form:
>>> c.name = a string containing the name of the child -- usually its
>> constructor
>>> c.args = a dictionary of attributes and values to be passed to the
>> constructor of that child
>>> c.children = an array of children for the new child"
>>
>> You are venturing into things that most people don't, since they just use
>> the XML language for their applications.
>>
>> I think the documentation on makeChild is more accurate. createChildren is
>> really just a hook to allow a subclass to change where and when it actually
>> makes its children. makeChild is the interface that actually interprets the
>> children specification. (Don't blame me for the confusing names, I did not
>> make them up!)
>>
>> c.name is still valid, it is used to make a child be of the class that
>> implements a particular tag (so you say 'view' to get a <view>, etc. You
>> can use this to make any node that has a tag).
>>
>> c.class is an optimization, used by the compiler to:
>>
>> 1) Avoid having to look up the name
>> 2) Instantiate 'instance classes'
>>
>>> None of this seems to be true.
>>> Instead the children seems to have the structure:
>>> c.attrs = a dictionary of attributes and values to be passed to the
>> constructor of that child
>>> c.class = pointer to the class to be instantiated
>>>
>>> When you further inspect the class there is one useful attribute:
>>> tagname. That seems to have the same function as c.name in the above
>> mentioned documentation.
>>>
>>> Further it seems that in the current trunk if you instantiate a class
>> with a constrained attribute like this
>>>
>>> <view height="${foo.height}"/>
>>>
>>> It's tagname becomes
>>> "anonymous tagname"
>>
>> Right. This is a so-called "instance class". In order to have a
>> constraint, an instance needs some supporting methods. (You would see the
>> same thing if you gave your instance an explicit <method>.) In order to
>> have methods, the compiler has to build a class, and then make just one
>> instance of that class. It doesn't define a tag for that class, because it
>> will only ever be made by the compiler (or by replication, which works
>> automatically). The tagname in this case, is just for debugging. If you
>> were to look at the non-debug version, you would see the tagname is not
>> emitted. And of course, the class is _not_ entered into `lz` (as are all
>> real class definitions, e.g., lz['view'] => the class that implements
>> <view>, so lz[<any tag name>].tagname == <any tag name>, but not for
>> 'anonymous' or 'instance' classes.)
>>
>>> Code:
>>>
>>> <canvas debug="true">
>>> <view >
>>> <method name="createChildren" args="children"><![CDATA[
>>> for(var i=0; i<children.length; i++) {
>>> Debug.write(children[i]['class'].tagname);
>>> }
>>> ]]></method>
>>> <view height="${canvas.height}"/>
>>> <view/>
>>> </view>
>>> </canvas>
>>>
>>> Produces the output in debug window:
>>> anonymous view
>>> view
>>>
>>> Is this how it is supposed to be?
>>
>> That's how it is supposed to be. :)
>>
>>> Or is this an accident caused by the instance specific mixin development?
>>
>> Although, we did just add this feature to make it easier to debug instance
>> mixin's. Before, we never emitted a tagname for "instance classes". But we
>> decided it would help debugging to give them a tagname that told what tag
>> they were derived from.
>>
>>
>>
>
>
> --
> Henry Minsky
> Software Architect
> hminsky@...

Re: createChildren

2009-11-24T15:23:10Z

Hmm, now that you mention it, I notice we've been adding the interstitial class names that come from compiling class mixins to the lz namespace object:

lz["colored_square$view"] = $lzc$class_colored_square$view;
lz["black_line$colored_square$view"] = $lzc$class_black_line$colored_square$view;

I don't think we need them in there, do we? The compiler seems to be emitting
calls to instantiate the objects directly using the classname when it calls LzInstantiateView e.g.,

"class": $lzc$class_black_line$colored_square$view

On Tue, Nov 24, 2009 at 5:36 PM, P T Withington <ptw@...> wrote:

On 2009-11-24, at 17:01, Rami Ojares / AMG Oy wrote:

> Hi,
>
> Current documentation has this to say about node's createChildren(carr) argument
>
> "an array of children where the structure of each child [c] takes the form:
> c.name = a string containing the name of the child -- usually its constructor
> c.args = a dictionary of attributes and values to be passed to the constructor of that child
> c.children = an array of children for the new child"

You are venturing into things that most people don't, since they just use the XML language for their applications.

I think the documentation on makeChild is more accurate. createChildren is really just a hook to allow a subclass to change where and when it actually makes its children. makeChild is the interface that actually interprets the children specification. (Don't blame me for the confusing names, I did not make them up!)

c.name is still valid, it is used to make a child be of the class that implements a particular tag (so you say 'view' to get a <view>, etc. You can use this to make any node that has a tag).

c.class is an optimization, used by the compiler to:

1) Avoid having to look up the name
2) Instantiate 'instance classes'

> None of this seems to be true.
> Instead the children seems to have the structure:
> c.attrs = a dictionary of attributes and values to be passed to the constructor of that child
> c.class = pointer to the class to be instantiated
>
> When you further inspect the class there is one useful attribute:
> tagname. That seems to have the same function as c.name in the above mentioned documentation.
>
> Further it seems that in the current trunk if you instantiate a class with a constrained attribute like this
>
> <view height="${foo.height}"/>
>
> It's tagname becomes
> "anonymous tagname"

Right. This is a so-called "instance class". In order to have a constraint, an instance needs some supporting methods. (You would see the same thing if you gave your instance an explicit <method>.) In order to have methods, the compiler has to build a class, and then make just one instance of that class. It doesn't define a tag for that class, because it will only ever be made by the compiler (or by replication, which works automatically). The tagname in this case, is just for debugging. If you were to look at the non-debug version, you would see the tagname is not emitted. And of course, the class is _not_ entered into `lz` (as are all real class definitions, e.g., lz['view'] => the class that implements <view>, so lz[<any tag name>].tagname == <any tag name>, but not for 'anonymous' or 'instance' classes.)

> Code:
>
> <canvas debug="true">
> <view >
> <method name="createChildren" args="children"><![CDATA[
> for(var i=0; i<children.length; i++) {
> Debug.write(children[i]['class'].tagname);
> }
> ]]></method>
> <view height="${canvas.height}"/>
> <view/>
> </view>
> </canvas>
>
> Produces the output in debug window:
> anonymous view
> view
>
> Is this how it is supposed to be?

That's how it is supposed to be. :)

> Or is this an accident caused by the instance specific mixin development?

Although, we did just add this feature to make it easier to debug instance mixin's. Before, we never emitted a tagname for "instance classes". But we decided it would help debugging to give them a tagname that told what tag they were derived from.

--
Henry Minsky
Software Architect
hminsky@...

Re: createChildren

2009-11-24T14:36:17Z

On 2009-11-24, at 17:01, Rami Ojares / AMG Oy wrote:

> Hi,
>
> Current documentation has this to say about node's createChildren(carr) argument
>
> "an array of children where the structure of each child [c] takes the form:
> c.name = a string containing the name of the child -- usually its constructor
> c.args = a dictionary of attributes and values to be passed to the constructor of that child
> c.children = an array of children for the new child"

You are venturing into things that most people don't, since they just use the XML language for their applications.

I think the documentation on makeChild is more accurate. createChildren is really just a hook to allow a subclass to change where and when it actually makes its children. makeChild is the interface that actually interprets the children specification. (Don't blame me for the confusing names, I did not make them up!)

c.name is still valid, it is used to make a child be of the class that implements a particular tag (so you say 'view' to get a <view>, etc. You can use this to make any node that has a tag).

c.class is an optimization, used by the compiler to:

1) Avoid having to look up the name
2) Instantiate 'instance classes'

> None of this seems to be true.
> Instead the children seems to have the structure:
> c.attrs = a dictionary of attributes and values to be passed to the constructor of that child
> c.class = pointer to the class to be instantiated
>
> When you further inspect the class there is one useful attribute:
> tagname. That seems to have the same function as c.name in the above mentioned documentation.
>
> Further it seems that in the current trunk if you instantiate a class with a constrained attribute like this
>
> <view height="${foo.height}"/>
>
> It's tagname becomes
> "anonymous tagname"

Right. This is a so-called "instance class". In order to have a constraint, an instance needs some supporting methods. (You would see the same thing if you gave your instance an explicit <method>.) In order to have methods, the compiler has to build a class, and then make just one instance of that class. It doesn't define a tag for that class, because it will only ever be made by the compiler (or by replication, which works automatically). The tagname in this case, is just for debugging. If you were to look at the non-debug version, you would see the tagname is not emitted. And of course, the class is _not_ entered into `lz` (as are all real class definitions, e.g., lz['view'] => the class that implements <view>, so lz[<any tag name>].tagname == <any tag name>, but not for 'anonymous' or 'instance' classes.)

> Code:
>
> <canvas debug="true">
> <view >
> <method name="createChildren" args="children"><![CDATA[
> for(var i=0; i<children.length; i++) {
> Debug.write(children[i]['class'].tagname);
> }
> ]]></method>
> <view height="${canvas.height}"/>
> <view/>
> </view>
> </canvas>
>
> Produces the output in debug window:
> anonymous view
> view
>
> Is this how it is supposed to be?

That's how it is supposed to be. :)

> Or is this an accident caused by the instance specific mixin development?

Although, we did just add this feature to make it easier to debug instance mixin's. Before, we never emitted a tagname for "instance classes". But we decided it would help debugging to give them a tagname that told what tag they were derived from.

createChildren

2009-11-24T14:01:33Z

Hi,

Current documentation has this to say about node's createChildren(carr)
argument

"an array of children where the structure of each child [c] takes the form:
c.name = a string containing the name of the child -- usually its
constructor
c.args = a dictionary of attributes and values to be passed to the
constructor of that child
c.children = an array of children for the new child"

None of this seems to be true.
Instead the children seems to have the structure:
c.attrs = a dictionary of attributes and values to be passed to the
constructor of that child
c.class = pointer to the class to be instantiated

When you further inspect the class there is one useful attribute:
tagname. That seems to have the same function as c.name in the above
mentioned documentation.

Further it seems that in the current trunk if you instantiate a class
with a constrained attribute like this

<view height="${foo.height}"/>

It's tagname becomes
"anonymous tagname"

Code:

<canvas debug="true">
<view >
<method name="createChildren" args="children"><![CDATA[
for(var i=0; i<children.length; i++) {
Debug.write(children[i]['class'].tagname);
}
]]></method>
<view height="${canvas.height}"/>
<view/>
</view>
</canvas>

Produces the output in debug window:
anonymous view
view

Is this how it is supposed to be?
Or is this an accident caused by the instance specific mixin development?

- rami

Re: debug eval in swf10 of function expression

2009-11-24T08:29:23Z

If I remove that
with (Debug.environment) {
}
wrapper, then it compiles OK....

On Tue, Nov 24, 2009 at 11:20 AM, Henry Minsky <hminsky@...> wrote:

If you type this to the debug evaluator

(function (x) { return x.foo })(3)

It compiles down to this code, which is then linked to the debug LFC, and I do not understand why it complains about
"Error" being unknown. "lz" and "$lzsc$runtime" are declared globals in the LFC, so I don't see why it
complains about them either.

package {

    import flash.display.*;
    import flash.events.*;
    import flash.utils.*;
    import flash.text.*;
    import flash.system.*;
    import flash.net.*;
    import flash.ui.*;
    import flash.external.*;
    public class DebugEvaluate extends DebugExec {
        override public function runToplevelDefinitions () {;
            (function () {
                try {
                    try {
                        with (Debug.environment) {
                            Debug.displayResult((function (x_$1) {
                                        try {
                                            return x_$1.foo
                                                }
                                        catch ($lzsc$e) {
                                            if ($lzsc$e is Error && $lzsc$e !== lz["$lzsc$thrownError"]) {
                                                $lzsc$runtime.$reportException("[CommonGenerator.parseFragment]", 11, $lzsc$e)
                                                    } else {
                                                throw $lzsc$e
                                                    }}}
                                    )(3))
                                }}
                    catch (e_$1) {
                        Debug.displayResult(e_$1)
                            }}
                catch ($lzsc$e) {
                    if ($lzsc$e is Error && $lzsc$e !== lz["$lzsc$thrownError"]) {
                        $lzsc$runtime.$reportException("[CommonGenerator.parseFragment]", 8, $lzsc$e)
                            } else {
                        throw $lzsc$e
                            }}}
                )();
        }
    }
}

Which gets these flex compiler errors

Loading configuration file /Users/hqm/openlaszlo/trunk6/WEB-INF/frameworks/flex-config.xml
/Users/hqm/openlaszlo/lib/jakarta-tomcat-5.0.30/temp/lzswf9/Users/hqm/openlaszlo/trunk6/test/build/foo.lzx/DebugEvaluate.as(22): col: 16 Error: Access of undefined property Error.

if ($lzsc$e is Error && $lzsc$e !== lz["$lzsc$thrownError"]) {
               ^

/Users/hqm/openlaszlo/lib/jakarta-tomcat-5.0.30/temp/lzswf9/Users/hqm/openlaszlo/trunk6/test/build/foo.lzx/DebugEvaluate.as(22): col: 37 Error: Access of undefined property lz.

if ($lzsc$e is Error && $lzsc$e !== lz["$lzsc$thrownError"]) {
                                    ^

/Users/hqm/openlaszlo/lib/jakarta-tomcat-5.0.30/temp/lzswf9/Users/hqm/openlaszlo/trunk6/test/build/foo.lzx/DebugEvaluate.as(23): col: 1 Error: Access of undefined property $lzsc$runtime.

$lzsc$runtime.$reportException("[CommonGenerator.parseFragment]", 11, $lzsc$e)
^

--
Henry Minsky
Software Architect
hminsky@...

--
Henry Minsky
Software Architect
hminsky@...

debug eval in swf10 of function expression

2009-11-24T08:20:34Z

If you type this to the debug evaluator

(function (x) { return x.foo })(3)

It compiles down to this code, which is then linked to the debug LFC, and I do not understand why it complains about
"Error" being unknown. "lz" and "$lzsc$runtime" are declared globals in the LFC, so I don't see why it
complains about them either.

package {

    import flash.display.*;
    import flash.events.*;
    import flash.utils.*;
    import flash.text.*;
    import flash.system.*;
    import flash.net.*;
    import flash.ui.*;
    import flash.external.*;
    public class DebugEvaluate extends DebugExec {
        override public function runToplevelDefinitions () {;
            (function () {
                try {
                    try {
                        with (Debug.environment) {
                            Debug.displayResult((function (x_$1) {
                                        try {
                                            return x_$1.foo
                                                }
                                        catch ($lzsc$e) {
                                            if ($lzsc$e is Error && $lzsc$e !== lz["$lzsc$thrownError"]) {
                                                $lzsc$runtime.$reportException("[CommonGenerator.parseFragment]", 11, $lzsc$e)
                                                    } else {
                                                throw $lzsc$e
                                                    }}}
                                    )(3))
                                }}
                    catch (e_$1) {
                        Debug.displayResult(e_$1)
                            }}
                catch ($lzsc$e) {
                    if ($lzsc$e is Error && $lzsc$e !== lz["$lzsc$thrownError"]) {
                        $lzsc$runtime.$reportException("[CommonGenerator.parseFragment]", 8, $lzsc$e)
                            } else {
                        throw $lzsc$e
                            }}}
                )();
        }
    }
}

Which gets these flex compiler errors

Loading configuration file /Users/hqm/openlaszlo/trunk6/WEB-INF/frameworks/flex-config.xml
/Users/hqm/openlaszlo/lib/jakarta-tomcat-5.0.30/temp/lzswf9/Users/hqm/openlaszlo/trunk6/test/build/foo.lzx/DebugEvaluate.as(22): col: 16 Error: Access of undefined property Error.

if ($lzsc$e is Error && $lzsc$e !== lz["$lzsc$thrownError"]) {
               ^

/Users/hqm/openlaszlo/lib/jakarta-tomcat-5.0.30/temp/lzswf9/Users/hqm/openlaszlo/trunk6/test/build/foo.lzx/DebugEvaluate.as(22): col: 37 Error: Access of undefined property lz.

if ($lzsc$e is Error && $lzsc$e !== lz["$lzsc$thrownError"]) {
                                    ^

/Users/hqm/openlaszlo/lib/jakarta-tomcat-5.0.30/temp/lzswf9/Users/hqm/openlaszlo/trunk6/test/build/foo.lzx/DebugEvaluate.as(23): col: 1 Error: Access of undefined property $lzsc$runtime.

$lzsc$runtime.$reportException("[CommonGenerator.parseFragment]", 11, $lzsc$e)
^

--
Henry Minsky
Software Architect
hminsky@...

Re: no way to actually turn off catcherrors in swf10 ?

2009-11-23T16:54:11Z

But that loses the info about exactly which line blew out... I think we need a 'dont catch errors, even in debug mode' flag.

On Mon, Nov 23, 2009 at 7:53 PM, Henry Minsky <henry.minsky@...> wrote:

Hmm, well, maybe at least we should have an option in the debug swf10 runtime to print the flash stack trace out to the debugger, it's sometimes needed if you're trying to track down a bug in the LFC and want to see the exact line in the intermediate .as file .

We can get our hands on it as a string by doing
new Error('I want a stack trace please').getStackTrace())

On Mon, Nov 23, 2009 at 7:39 PM, P T Withington <ptw@...> wrote:

Turn off debugging.

catcherrors is for the non-debug case

If you really need to have debugging on and not have it catch and report, we'll have to make you a new flag.

On Nov 23, 2009, at 16:24, Henry Minsky <hminsky@...> wrote:

Even if I set compiler.catcherrors=false, it seems like the compiler is not really ever building me an LFC / app without the
try/catches added to functions. Is there something else I need to toggle to keep it from inserting them?

--
Henry Minsky
Software Architect
hminsky@...hminsky@...

--
Henry Minsky
Software Architect
hminsky@...

--
Henry Minsky
Software Architect
hminsky@...

Re: [Laszlo-user] Flex 4 documentation

2009-11-23T13:43:29Z

It might make sense to put some/all of this info on this page:
http://wiki.openlaszlo.org/Runtime_Differences

P T Withington wrote:

> Can you start a page on the wiki for this kind of info, and maybe add some bits about how to get the debug player and use fdb?
>
> On 2009-11-23, at 10:01, Henry Minsky wrote:
>
>> Note for swf10 app developers:
>>
>> OpenLaszlo currently ships with a copy of the Flex 4 Compiler SDK (Adobe's
>> code name is Gumbo), specifically the last 'stable build', which is
>> flex_sdk_4.0.0.6898 May 14
>>
>> I am not sure which Adobe documentation web page corresponds most closely to
>> this flex build. They are up to a Flex 4 Beta 2 release now, but I don't
>> know how much the API differs from the milestone build we're using.
>>
>> I've been using this URL for documentation of the Flex SDK
>> http://help.adobe.com/en_US/FlashPlatform/beta/reference/actionscript/3/index.html?filter_flex=4
>>
>>
>>
>>
>> On Mon, Nov 23, 2009 at 9:43 AM, Henry Minsky <henry.minsky@...>wrote:
>>
>>> This compiles for me in swf10 without error in trunk
>>>
>>>
>>> <canvas debug="true" height="500" width="100%">
>>> <attribute name="_conn"/>
>>> <attribute name="s1"/>
>>> <attribute name="s2"/>
>>>
>>> <switch>
>>> <when property="$as3">
>>> <passthrough>
>>> import flash.net.*;
>>> import flash.events.*;
>>> import flash.media.Camera;
>>> import flash.media.Video;
>>> import flash.media.Microphone;
>>>
>>> </passthrough>
>>> </when>
>>> </switch>
>>>
>>>
>>>
>> --
>> Henry Minsky
>> Software Architect
>> hminsky@...
>
>

--
Regards,
Max Carlson
OpenLaszlo.org

Re: How can we eliminate the 'conditional class definitions' from the AV components?

2009-11-23T13:37:24Z

I think those are there so DHTML apps wouldn't autoinclude a bunch of
code that fails when someone accidentally includes one of those
components. Instead of some mysterious runtime error, the class won't
be included - making for a much more straightforward debugging experience.

It seems like what we really want is to be able to signal a compiler
error when trying to include one of these components in DHTML...

Failing that, we could eliminate the condition in the components and ask
developers to put conditions in their own apps when they want
cross-runtime support. We will likely need to add if ($dhtml) { warn }
else { ... } clauses to most methods.

P T Withington wrote:
> [exec] extensions/av/mediastream.lzx:13:9: Compile may fail due to conditional class definitions in <switch>
> [exec] extensions/av/rtmpconnection.lzx:12:11: Compile may fail due to conditional class definitions in <switch>
> [exec] extensions/av/videoview.lzx:13:9: Compile may fail due to conditional class definitions in <switch>
>

--
Regards,
Max Carlson
OpenLaszlo.org

Re: errors while swf10 compilation during NetConnection operations

2009-11-23T13:26:17Z

One thing you might want to try is installing the Flash 10 debug player:
http://www.adobe.com/support/flashplayer/downloads.html

The debug player makes it much easier to pinpoint these kinds of issues.
Let me know if that helps!

cem sonmez wrote:

> Hi
> Especially i m compiling my code on swf10 but especially at the
> netconnection operations (sharedobject, netconnection, netstream..) i m
> getting many errors.
> For example at this code for swf8 everything goes fine
> <canvas debug="true" height="500" width="100%">
> <attribute name="_conn"/>
> <attribute name="s1"/>
> <attribute name="s2"/>
>
> <handler name="oninit">
> // These lines begin broadcasting.
> this._conn = new NetConnection(); // Create connection object.
> this._conn.connect("rtmp://192.168.1.94/Red5SharedObject/
> <http://192.168.1.94/Red5SharedObject/>"); // Connect to server.
> s1 = new NetStream(this._conn); // Open stream within connection.
> //s1.attachAudio(Microphone.get()); // Capture audio.
> s1.attachVideo(Camera.get()); // Capture video.
> s1.publish("todays_news"); // Begin broadcasting.
>
> s2 = new NetStream(this._conn);
> live._attachStream(s2); // Specify where to display video.
> s2.play("todays_news"); // play() uses the same name as
> publish() above.
>
> this.s1.onStatus = function(info) {
> Debug.write("simpleNetStream onStatus",info);
> };
> this.s1.onCuePoint = function(info) {
> Debug.write("simpleNetStream onCuePoint",info);
> };
> this.s1.onPlayStatus = function(info) {
> Debug.write("simpleNetStream onPlayStatus",info);
> };
> this.s1.onMetaData = function(info) {
> Debug.write("simpleNetStream onMetaData",info);
> };
> </handler>
>
> <simplelayout/>
>
> <videoview id="live" width="150" height="150" type="rtmp" />
>
> </canvas>
>
> But when i try the same operations with as3 way on swf10. Althought i
> have added lines below in order to add the flash classes to the
> application for as3, e.g last problem about this issue is an error, like
> : |Error: Call to a possibly undefined method NetStream...|
>
> <switch>
> <when property="$as3">
> <passthrough>
> import flash.net.*;
> import flash.events.*;
> </passthrough>
> </when>
> </switch>
>
>
> I am planning to try my applications just on swf10 env. But most of the
> time, it is a bit harder than swf8 to work without problem. Do you
> suggest swf10 development on openlaszlo platform for now.
>
> Best regards.
> --
> Cem SONMEZ

--
Regards,
Max Carlson
OpenLaszlo.org

no way to actually turn off catcherrors in swf10 ?

2009-11-23T13:24:45Z

Even if I set compiler.catcherrors=false, it seems like the compiler is not really ever building me an LFC / app without the
try/catches added to functions. Is there something else I need to toggle to keep it from inserting them?

--
Henry Minsky
Software Architect
hminsky@...

How can we eliminate the 'conditional class definitions' from the AV components?

2009-11-23T13:10:36Z

[exec] extensions/av/mediastream.lzx:13:9: Compile may fail due to conditional class definitions in <switch>
[exec] extensions/av/rtmpconnection.lzx:12:11: Compile may fail due to conditional class definitions in <switch>
[exec] extensions/av/videoview.lzx:13:9: Compile may fail due to conditional class definitions in <switch>

Fwd: errors while swf10 compilation during NetConnection operations

2009-11-23T13:07:19Z

forwarding to laszlo-user, and dev in case anyone else has an idea

---------- Forwarded message ----------
From: cem sonmez <cemosonmez@...>
Date: Mon, Nov 23, 2009 at 4:03 PM
Subject: Re: [Laszlo-dev] errors while swf10 compilation during NetConnection operations
To: Henry Minsky <henry.minsky@...>

I did small changes and When i handle the netconnection status. I see
the application has connected to the flash server successfully. But
another error message is :

ArgumentError: Error #2126: NetConnection object must be connected.

And the error occurs with the "s1 = new NetStream(this._conn);" line.
I have no idea where i m wrong at. Openlaszlo platform version and
code are the same with yours but the behaviour is different. Isn't
this so strange. I m getting these like errors for a couple of days.
And i donT want to be obliged to working on swf8 bec. of. these
errors.

Thanks.

<canvas debug="true" height="500" width="100%">
    <attribute name="_conn"/>
    <attribute name="s1"/>
    <attribute name="s2"/>

    <switch>
      <when property="$as3">
        <passthrough>
          import flash.net.*;
          import flash.events.*;
          import flash.media.Camera;
          import flash.media.Video;
          import flash.media.Microphone;

        </passthrough>
      </when>
    </switch>

    <handler name="oninit">

NetConnection.defaultObjectEncoding = flash.net.ObjectEncoding.AMF0;

// These lines begin broadcasting.
this._conn = new NetConnection(); // Create connection object.

this._conn.connect("rtmp://192.168.1.4/Red5SharedObject/"); //
Connect to server.
this._conn.addEventListener(NetStatusEvent.NET_STATUS, netStatusHandler);

        s1 = new NetStream(this._conn);   // Open stream within connection.
        //s1.attachAudio(Microphone.get());   // Capture audio.
        s1.attachVideo(Camera.getCamera());       // Capture video.

        s1.publish("todays_news");          // Begin broadcasting.

        s2 = new NetStream(this._conn);
        live._attachStream(s2); // Specify where to display video.
        s2.play("todays_news"); // play() uses the same name as publish() above.

            this.s1.onStatus = function(info) {
                Debug.write("simpleNetStream onStatus",info);
            };
            this.s1.onCuePoint = function(info) {
                Debug.write("simpleNetStream onCuePoint",info);
            };
            this.s1.onPlayStatus = function(info) {
                Debug.write("simpleNetStream onPlayStatus",info);
            };
            this.s1.onMetaData = function(info) {
                Debug.write("simpleNetStream onMetaData",info);
            };
    </handler>

    <method name="netStatusHandler" args="event">
        switch (event.info.code) {
                case "NetConnection.Connect.Success":
                    Debug.write("The connection attempt succeeded.");

                    break;

                case "NetConnection.Connect.Failed":
                    Debug.write("The connection attempt failed.");
                    break;
        }
    </method>

2009/11/23 cem sonmez <cemosonmez@...>

>
> I have downloaded the latest nightly build of openlaszlo from [1]. And i m using the flash debugger plugin as well. When i try the code below in swf10. The error message is :
>
> Error #2044: Unhadled NetStatusEvent:. level=error, code=NetConnection.Connect.Failed ...
>
> [1] - http://download.openlaszlo.org/nightly/trunk/15210
>
>
> 2009/11/23 Henry Minsky <henry.minsky@...>
>>
>> This compiles for me in swf10 without error in trunk
>>
>> <canvas debug="true" height="500" width="100%">
>>     <attribute name="_conn"/>
>>     <attribute name="s1"/>
>>     <attribute name="s2"/>
>>
>>     <switch>
>>       <when property="$as3">
>>         <passthrough>
>>           import flash.net.*;
>>           import flash.events.*;
>>           import flash.media.Camera;
>>           import flash.media.Video;
>>           import flash.media.Microphone;
>>
>>         </passthrough>
>>       </when>
>>     </switch>
>>
>>     <handler name="oninit">
>>         // These lines begin broadcasting.
>>         this._conn = new NetConnection(); // Create connection object.
>>         this._conn.connect("rtmp://192.168.1.94/Red5SharedObject/"); // Connect to server.
>>         s1 = new NetStream(this._conn);   // Open stream within connection.
>>         //s1.attachAudio(Microphone.get());   // Capture audio.
>>         s1.attachVideo(Camera.getCamera());       // Capture video.
>>         s1.publish("todays_news");          // Begin broadcasting.
>>
>>         s2 = new NetStream(this._conn);
>>         live._attachStream(s2); // Specify where to display video.
>>         s2.play("todays_news"); // play() uses the same name as publish() above.
>>
>>             this.s1.onStatus = function(info) {
>>                 Debug.write("simpleNetStream onStatus",info);
>>             };
>>             this.s1.onCuePoint = function(info) {
>>                 Debug.write("simpleNetStream onCuePoint",info);
>>             };
>>             this.s1.onPlayStatus = function(info) {
>>                 Debug.write("simpleNetStream onPlayStatus",info);
>>             };
>>             this.s1.onMetaData = function(info) {
>>                 Debug.write("simpleNetStream onMetaData",info);
>>             };
>>     </handler>
>>
>>     <simplelayout/>
>>
>>     <videoview id="live" width="150" height="150" type="rtmp" />
>>
>>
>>
>> </canvas>
>>
>>
>>
>>
>>
>>
>> On Mon, Nov 23, 2009 at 7:05 AM, cem sonmez <cemosonmez@...> wrote:
>>>
>>> Hi
>>> Especially i m compiling my code on swf10 but especially at the netconnection operations (sharedobject, netconnection, netstream..) i m getting many errors.
>>> For example at this code for swf8 everything goes fine
>>> <canvas debug="true" height="500" width="100%">
>>>     <attribute name="_conn"/>
>>>     <attribute name="s1"/>
>>>     <attribute name="s2"/>
>>>
>>>     <handler name="oninit">
>>>         // These lines begin broadcasting.
>>>         this._conn = new NetConnection(); // Create connection object.
>>>         this._conn.connect("rtmp://192.168.1.94/Red5SharedObject/"); // Connect to server.
>>>         s1 = new NetStream(this._conn);   // Open stream within connection.
>>>         //s1.attachAudio(Microphone.get());   // Capture audio.
>>>         s1.attachVideo(Camera.get());       // Capture video.
>>>         s1.publish("todays_news");          // Begin broadcasting.
>>>
>>>         s2 = new NetStream(this._conn);
>>>         live._attachStream(s2); // Specify where to display video.
>>>         s2.play("todays_news"); // play() uses the same name as publish() above.
>>>
>>>             this.s1.onStatus = function(info) {
>>>                 Debug.write("simpleNetStream onStatus",info);
>>>             };
>>>             this.s1.onCuePoint = function(info) {
>>>                 Debug.write("simpleNetStream onCuePoint",info);
>>>             };
>>>             this.s1.onPlayStatus = function(info) {
>>>                 Debug.write("simpleNetStream onPlayStatus",info);
>>>             };
>>>             this.s1.onMetaData = function(info) {
>>>                 Debug.write("simpleNetStream onMetaData",info);
>>>             };
>>>     </handler>
>>>
>>>     <simplelayout/>
>>>
>>>     <videoview id="live" width="150" height="150" type="rtmp" />
>>>
>>> </canvas>
>>>
>>> But when i try the same operations with as3 way on swf10. Althought i have added lines below in order to add the flash classes to the application for as3, e.g last problem about this issue is an error, like : Error: Call to a possibly undefined method NetStream...
>>>
>>> <switch>
>>>             <when property="$as3">
>>>                 <passthrough>
>>>                     import flash.net.*;
>>>                     import flash.events.*;
>>>                 </passthrough>
>>>             </when>
>>> </switch>
>>>
>>>
>>> I am planning to try my applications just on swf10 env. But most of the time, it is a bit harder than swf8 to work without problem. Do you suggest swf10 development on openlaszlo platform for now.
>>>
>>> Best regards.
>>> --
>>> Cem SONMEZ
>>
>>
>>
>> --
>> Henry Minsky
>> Software Architect
>> hminsky@...
>>
>>
>
>
>
> --
> Cem SONMEZ

--
Cem SONMEZ

--
Henry Minsky
Software Architect
hminsky@...

Re: Flex 4 documentation

2009-11-23T08:40:26Z

Can you start a page on the wiki for this kind of info, and maybe add some bits about how to get the debug player and use fdb?

On 2009-11-23, at 10:01, Henry Minsky wrote:

> Note for swf10 app developers:
>
> OpenLaszlo currently ships with a copy of the Flex 4 Compiler SDK (Adobe's
> code name is Gumbo), specifically the last 'stable build', which is
> flex_sdk_4.0.0.6898 May 14
>
> I am not sure which Adobe documentation web page corresponds most closely to
> this flex build. They are up to a Flex 4 Beta 2 release now, but I don't
> know how much the API differs from the milestone build we're using.
>
> I've been using this URL for documentation of the Flex SDK
> http://help.adobe.com/en_US/FlashPlatform/beta/reference/actionscript/3/index.html?filter_flex=4
>
>
>
>
> On Mon, Nov 23, 2009 at 9:43 AM, Henry Minsky <henry.minsky@...>wrote:
>
>> This compiles for me in swf10 without error in trunk
>>
>>
>> <canvas debug="true" height="500" width="100%">
>> <attribute name="_conn"/>
>> <attribute name="s1"/>
>> <attribute name="s2"/>
>>
>> <switch>
>> <when property="$as3">
>> <passthrough>
>> import flash.net.*;
>> import flash.events.*;
>> import flash.media.Camera;
>> import flash.media.Video;
>> import flash.media.Microphone;
>>
>> </passthrough>
>> </when>
>> </switch>
>>
>>
>>
> --
> Henry Minsky
> Software Architect
> hminsky@...

Flex 4 documentation

2009-11-23T07:01:40Z

Note for swf10 app developers:

OpenLaszlo currently ships with a copy of the Flex 4 Compiler SDK (Adobe's code name is Gumbo), specifically the last 'stable build', which is flex_sdk_4.0.0.6898 May 14

I am not sure which Adobe documentation web page corresponds most closely to this flex build. They are up to a Flex 4 Beta 2 release now, but I don't know how much the API differs from the milestone build we're using.

I've been using this URL for documentation of the Flex SDK
http://help.adobe.com/en_US/FlashPlatform/beta/reference/actionscript/3/index.html?filter_flex=4

On Mon, Nov 23, 2009 at 9:43 AM, Henry Minsky <henry.minsky@...> wrote:

This compiles for me in swf10 without error in trunk

<canvas debug="true" height="500" width="100%">
    <attribute name="_conn"/>
    <attribute name="s1"/>
    <attribute name="s2"/>

    <switch>
      <when property="$as3">
        <passthrough>
          import flash.net.*;
          import flash.events.*;

          import flash.media.Camera;
          import flash.media.Video;
          import flash.media.Microphone;

        </passthrough>
      </when>
    </switch>

--
Henry Minsky
Software Architect
hminsky@...

Re: errors while swf10 compilation during NetConnection operations

2009-11-23T06:43:26Z

This compiles for me in swf10 without error in trunk

<canvas debug="true" height="500" width="100%">
    <attribute name="_conn"/>
    <attribute name="s1"/>
    <attribute name="s2"/>

    <switch>
      <when property="$as3">
        <passthrough>
          import flash.net.*;
          import flash.events.*;
          import flash.media.Camera;
          import flash.media.Video;
          import flash.media.Microphone;

        </passthrough>
      </when>
    </switch>

    <handler name="oninit">
        // These lines begin broadcasting.
        this._conn = new NetConnection(); // Create connection object.
        this._conn.connect("rtmp://192.168.1.94/Red5SharedObject/"); // Connect to server.
        s1 = new NetStream(this._conn);   // Open stream within connection.
        //s1.attachAudio(Microphone.get());   // Capture audio.
        s1.attachVideo(Camera.getCamera());       // Capture video.
        s1.publish("todays_news");          // Begin broadcasting.

        s2 = new NetStream(this._conn);
        live._attachStream(s2); // Specify where to display video.
        s2.play("todays_news"); // play() uses the same name as publish() above.

            this.s1.onStatus = function(info) {
                Debug.write("simpleNetStream onStatus",info);
            };
            this.s1.onCuePoint = function(info) {
                Debug.write("simpleNetStream onCuePoint",info);
            };
            this.s1.onPlayStatus = function(info) {
                Debug.write("simpleNetStream onPlayStatus",info);
            };
            this.s1.onMetaData = function(info) {
                Debug.write("simpleNetStream onMetaData",info);
            };
    </handler>

    <simplelayout/>

    <videoview id="live" width="150" height="150" type="rtmp" />


</canvas>

On Mon, Nov 23, 2009 at 7:05 AM, cem sonmez <cemosonmez@...> wrote:

Hi
Especially i m compiling my code on swf10 but especially at the netconnection operations (sharedobject, netconnection, netstream..) i m getting many errors.
For example at this code for swf8 everything goes fine
<canvas debug="true" height="500" width="100%">
    <attribute name="_conn"/>
    <attribute name="s1"/>
    <attribute name="s2"/>

    <handler name="oninit">
        // These lines begin broadcasting.
        this._conn = new NetConnection(); // Create connection object.
        this._conn.connect("rtmp://192.168.1.94/Red5SharedObject/"); // Connect to server.
        s1 = new NetStream(this._conn);   // Open stream within connection.
        //s1.attachAudio(Microphone.get());   // Capture audio.
        s1.attachVideo(Camera.get());       // Capture video.
        s1.publish("todays_news");          // Begin broadcasting.

        s2 = new NetStream(this._conn);
        live._attachStream(s2); // Specify where to display video.
        s2.play("todays_news"); // play() uses the same name as publish() above.

            this.s1.onStatus = function(info) {
                Debug.write("simpleNetStream onStatus",info);
            };
            this.s1.onCuePoint = function(info) {
                Debug.write("simpleNetStream onCuePoint",info);
            };
            this.s1.onPlayStatus = function(info) {
                Debug.write("simpleNetStream onPlayStatus",info);
            };
            this.s1.onMetaData = function(info) {
                Debug.write("simpleNetStream onMetaData",info);
            };
    </handler>

    <simplelayout/>

    <videoview id="live" width="150" height="150" type="rtmp" />

</canvas>

But when i try the same operations with as3 way on swf10. Althought i have added lines below in order to add the flash classes to the application for as3, e.g last problem about this issue is an error, like : Error: Call to a possibly undefined method NetStream...

<switch>
            <when property="$as3">
                <passthrough>
                    import flash.net.*;
                    import flash.events.*;
                </passthrough>
            </when>
</switch>

I am planning to try my applications just on swf10 env. But most of the time, it is a bit harder than swf8 to work without problem. Do you suggest swf10 development on openlaszlo platform for now.

Best regards.
--
Cem SONMEZ

--
Henry Minsky
Software Architect
hminsky@...

Re: errors while swf10 compilation during NetConnection operations

2009-11-23T05:11:27Z

On 2009-11-23, at 07:05, cem sonmez wrote:

> But when i try the same operations with as3 way on swf10. Althought i have
> added lines below in order to add the flash classes to the application for
> as3, e.g last problem about this issue is an error, like : Error: Call to a
> possibly undefined method NetStream...
>
> <switch>
> <when property="$as3">
> <passthrough>
> import flash.net.*;
> import flash.events.*;
> </passthrough>
> </when>
> </switch>

Possibly try explicitly importing flash.net.NetStream? The fact that you are getting this warning from the compiler implies it does not think NetStream is defined.

> I am planning to try my applications just on swf10 env. But most of the
> time, it is a bit harder than swf8 to work without problem. Do you suggest
> swf10 development on openlaszlo platform for now.

We believe development directly on swf10 is working as well as swf8, although the runtime is stricter, so you will have to address any errors.

For detailed debugging, you can use the debug version of the Flash Player in combination with the Flex debugger.

See http://www.openlaszlo.org/pipermail/laszlo-dev/2009-March/020236.html

(Someone should write up how to use the flex debugger at wiki.openlaszlo.org.)

errors while swf10 compilation during NetConnection operations

2009-11-23T04:05:27Z

Hi
Especially i m compiling my code on swf10 but especially at the netconnection operations (sharedobject, netconnection, netstream..) i m getting many errors.
For example at this code for swf8 everything goes fine
<canvas debug="true" height="500" width="100%">
    <attribute name="_conn"/>
    <attribute name="s1"/>
    <attribute name="s2"/>

    <handler name="oninit">
        // These lines begin broadcasting.
        this._conn = new NetConnection(); // Create connection object.
        this._conn.connect("rtmp://192.168.1.94/Red5SharedObject/"); // Connect to server.
        s1 = new NetStream(this._conn);   // Open stream within connection.
        //s1.attachAudio(Microphone.get());   // Capture audio.
        s1.attachVideo(Camera.get());       // Capture video.
        s1.publish("todays_news");          // Begin broadcasting.

        s2 = new NetStream(this._conn);
        live._attachStream(s2); // Specify where to display video.
        s2.play("todays_news"); // play() uses the same name as publish() above.

            this.s1.onStatus = function(info) {
                Debug.write("simpleNetStream onStatus",info);
            };
            this.s1.onCuePoint = function(info) {
                Debug.write("simpleNetStream onCuePoint",info);
            };
            this.s1.onPlayStatus = function(info) {
                Debug.write("simpleNetStream onPlayStatus",info);
            };
            this.s1.onMetaData = function(info) {
                Debug.write("simpleNetStream onMetaData",info);
            };
    </handler>

    <simplelayout/>

    <videoview id="live" width="150" height="150" type="rtmp" />

</canvas>

But when i try the same operations with as3 way on swf10. Althought i have added lines below in order to add the flash classes to the application for as3, e.g last problem about this issue is an error, like : Error: Call to a possibly undefined method NetStream...

<switch>
            <when property="$as3">
                <passthrough>
                    import flash.net.*;
                    import flash.events.*;
                </passthrough>
            </when>
</switch>

I am planning to try my applications just on swf10 env. But most of the time, it is a bit harder than swf8 to work without problem. Do you suggest swf10 development on openlaszlo platform for now.

Best regards.
--
Cem SONMEZ

Re: [Laszlo-reviews] For Review: Change, 20091120-hqm-i Summary: support mixins on instances

2009-11-20T15:05:00Z

instance-class isn't right either.

It's a node without a tag. The class that makes this node doesn't have a tag, so in that sense the tag for the node is anonymous. You can't have no tag, you need to have something; and it has to be a valid XML identifier.

So far, anonymous seems like the best choice.

On 2009-11-20, at 17:49, Henry Minsky wrote:

> I didn't like 'anonymous' at all. I was thinking of 'instance-class' but
> that's pretty un-informative too.
>
>
>
> On Fri, Nov 20, 2009 at 5:03 PM, P T Withington <ptw@...> wrote:
>
>> Good point.
>>
>> Back to anonymous?
>>
>> Is there a better term?
>>
>> On 2009-11-20, at 17:07, André Bargull wrote:
>>
>>> I disagree about this point:
>>> I wouldn't call it a `singleton`, because in case of replication the
>> "instance class" might have multiple instances and therefore isn't a
>> singleton.
>>>
>>>
>>>> [laszlo-reviews -> laszlo-dev]
>>>>
>>>> I'll try to look at this in just a bit, but I had a thought:
>>>>
>>>> I wonder if instead of `anonymous` we should use `singleton`, I think
>> that might be more descriptive/accurate. An "instance class" as we have
>> been calling it is really an instance of a singleton class, a class that
>> will only ever have this one instance as a member, so we don't give it a tag
>> name (which is why we think of it as anonymous).
>>
>>
>
>
> --
> Henry Minsky
> Software Architect
> hminsky@...

Re: [Laszlo-reviews] For Review: Change, 20091120-hqm-i Summary: support mixins on instances

2009-11-20T14:49:00Z

I didn't like 'anonymous' at all. I was thinking of 'instance-class' but that's pretty un-informative too.

On Fri, Nov 20, 2009 at 5:03 PM, P T Withington <ptw@...> wrote:

Good point.

Back to anonymous?

Is there a better term?

On 2009-11-20, at 17:07, André Bargull wrote:

> I disagree about this point:
> I wouldn't call it a `singleton`, because in case of replication the "instance class" might have multiple instances and therefore isn't a singleton.
>
>
>> [laszlo-reviews -> laszlo-dev]
>>
>> I'll try to look at this in just a bit, but I had a thought:
>>
>> I wonder if instead of `anonymous` we should use `singleton`, I think that might be more descriptive/accurate. An "instance class" as we have been calling it is really an instance of a singleton class, a class that will only ever have this one instance as a member, so we don't give it a tag name (which is why we think of it as anonymous).

--
Henry Minsky
Software Architect
hminsky@...

Re: [Laszlo-reviews] For Review: Change, 20091120-hqm-i Summary: support mixins on instances

2009-11-20T14:03:50Z

Good point.

Back to anonymous?

Is there a better term?

On 2009-11-20, at 17:07, André Bargull wrote:

> I disagree about this point:
> I wouldn't call it a `singleton`, because in case of replication the "instance class" might have multiple instances and therefore isn't a singleton.
>
>
>> [laszlo-reviews -> laszlo-dev]
>>
>> I'll try to look at this in just a bit, but I had a thought:
>>
>> I wonder if instead of `anonymous` we should use `singleton`, I think that might be more descriptive/accurate. An "instance class" as we have been calling it is really an instance of a singleton class, a class that will only ever have this one instance as a member, so we don't give it a tag name (which is why we think of it as anonymous).

Re: [Laszlo-reviews] For Review: Change, 20091120-hqm-i Summary: support mixins on instances

2009-11-20T14:02:16Z

I disagree about this point:
I wouldn't call it a `singleton`, because in case of replication the
"instance class" might have multiple instances and therefore isn't a
singleton.

> [laszlo-reviews -> laszlo-dev]
>
> I'll try to look at this in just a bit, but I had a thought:
>
> I wonder if instead of `anonymous` we should use `singleton`, I think that might be more descriptive/accurate. An "instance class" as we have been calling it is really an instance of a singleton class, a class that will only ever have this one instance as a member, so we don't give it a tag name (which is why we think of it as anonymous).

Re: Runtime-independent Binary Libraries [Was: [UPDATE^2] For Review: Change 20091118-ptw-8 Summary: Binary compiler tweaks]

2009-11-20T12:23:53Z

On 2009-11-20, at 15:19, Max Carlson wrote:

> P T Withington wrote:
>> [cc-ing Laszlo-dev]
[...]
>>> Which got me thinking: could we allow library compilation for a specific runtime(s)? Either the library would support a given runtime, or it wouldn't.
>>>
>>> Then we could put off this notion of runtime-independent libraries for a little while. It's not clear to me that cross-runtime lzos are a requirement at this time - though they would be nice.
>> Good point. There are really 2 parts to runtime-indepencence for binary libraries:
>> 1) Make the compiler emit a binary library in a format that can be linked on any platform. This is what the majority of the current work has been toward. There were some major bugs in the old binary library format that meant that even if you compiled for a particular platform, it just wasn't going to work (there were some parts that were hard-wired to assume a particular target platform). That's mostly fixed.
>> 2) IWBRN to have a single binary library that could be linked and compiled to any platform. I think we are real close to having this, modulo the <switch> issue (http://jira.openlaszlo.org/jira/browse/LPP-8623), and as you point out, the <passthrough> tag (http://jira.openlaszlo.org/jira/browse/LPP-8608). If necessary, we can fall back to runtime-specific binary libraries, but I'd like to push a little further to see if we can avoid that.
>> Note that if you are not actually binary-compiling a file (for example mediastream above is an autoinclude, not part of the library you are binary compiling), the compiler could issue a less dreadful warning, because the only issue then is that if you define new <class>s in the switch body, they will not be seen by the binary compiler and could lead to the compile failing (if there is a class in the binary compile that depends on a class defined inside a <switch> in an external include).
>
> Sounds good. Can you make this change?

Working on it right now.
>
>> So, one solution to the <switch> problem is simply to move any <switch>s that you _must_ have, out of the binary-compiled library to an external include that is not binary-compiled.
>
> Yeah, I think we can do that for a lot of the cases. For webtop, refactoring isn't my department - I think we'll need input there.

I'll send them a message.

Re: Runtime-independent Binary Libraries [Was: [UPDATE^2] For Review: Change 20091118-ptw-8 Summary: Binary compiler tweaks]

2009-11-20T12:19:41Z

P T Withington wrote:

> [cc-ing Laszlo-dev]
>
> On 2009-11-19, at 18:38, Max Carlson wrote:
>
>> Okay, so now that we're compiling (yay!) I've been going through to see what stops the app from running.
>>
>> On the LPS side, there are lots of errors with the av, drawview and html components. html is lzx, so it's not so easy to rewrite to <script/> syntax...
>>
>> I noticed extensions/av/mediastream contains:
>>
>> <class name="mediastream" extends="node">
>> <switch>
>> <when property="$as3">
>> <passthrough>
>> import flash.media.*;
>> import flash.events.*;
>> import flash.net.NetConnection;
>> import flash.net.NetStream;
>> import flash.utils.setTimeout;
>> </passthrough>
>> </when>
>> </switch>
>>
>> Which got me thinking: could we allow library compilation for a specific runtime(s)? Either the library would support a given runtime, or it wouldn't.
>>
>> Then we could put off this notion of runtime-independent libraries for a little while. It's not clear to me that cross-runtime lzos are a requirement at this time - though they would be nice.
>
> Good point. There are really 2 parts to runtime-indepencence for binary libraries:
>
> 1) Make the compiler emit a binary library in a format that can be linked on any platform. This is what the majority of the current work has been toward. There were some major bugs in the old binary library format that meant that even if you compiled for a particular platform, it just wasn't going to work (there were some parts that were hard-wired to assume a particular target platform). That's mostly fixed.
>
> 2) IWBRN to have a single binary library that could be linked and compiled to any platform. I think we are real close to having this, modulo the <switch> issue (http://jira.openlaszlo.org/jira/browse/LPP-8623), and as you point out, the <passthrough> tag (http://jira.openlaszlo.org/jira/browse/LPP-8608). If necessary, we can fall back to runtime-specific binary libraries, but I'd like to push a little further to see if we can avoid that.
>
> Note that if you are not actually binary-compiling a file (for example mediastream above is an autoinclude, not part of the library you are binary compiling), the compiler could issue a less dreadful warning, because the only issue then is that if you define new <class>s in the switch body, they will not be seen by the binary compiler and could lead to the compile failing (if there is a class in the binary compile that depends on a class defined inside a <switch> in an external include).

Sounds good. Can you make this change?

> So, one solution to the <switch> problem is simply to move any <switch>s that you _must_ have, out of the binary-compiled library to an external include that is not binary-compiled.

Yeah, I think we can do that for a lot of the cases. For webtop,
refactoring isn't my department - I think we'll need input there.

--
Regards,
Max Carlson
OpenLaszlo.org

Re: [Laszlo-reviews] For Review: Change 20091120-hqm-i Summary: support mixins on instances

2009-11-20T11:32:34Z

Might as well change this too:

Index: LzNode.lzs
===================================================================
--- LzNode.lzs (revision 15195)
+++ LzNode.lzs (working copy)
@@ -2215,7 +2215,7 @@
// '.' prefix, over tagname, as it will be more specific.
var nct = node.constructor.tagname;
if (!nct) {
- path = 'anonymous';
+ path = 'singleton';
} else {
path = nct;
var sn = parent.subnodes;

On 2009-11-20, at 14:27, Henry Minsky wrote:

> Yeah, that's better, I'll change the string.
>
> On Fri, Nov 20, 2009 at 11:00 AM, P T Withington <ptw@...>wrote:
>
>> [laszlo-reviews -> laszlo-dev]
>>
>> I'll try to look at this in just a bit, but I had a thought:
>>
>> I wonder if instead of `anonymous` we should use `singleton`, I think that
>> might be more descriptive/accurate. An "instance class" as we have been
>> calling it is really an instance of a singleton class, a class that will
>> only ever have this one instance as a member, so we don't give it a tag name
>> (which is why we think of it as anonymous).
>
>
>
>
> --
> Henry Minsky
> Software Architect
> hminsky@...

Re: [Laszlo-reviews] For Review: Change 20091120-hqm-i Summary: support mixins on instances

2009-11-20T11:27:08Z

Yeah, that's better, I'll change the string.

On Fri, Nov 20, 2009 at 11:00 AM, P T Withington <ptw@...> wrote:

[laszlo-reviews -> laszlo-dev]

I'll try to look at this in just a bit, but I had a thought:

I wonder if instead of `anonymous` we should use `singleton`, I think that might be more descriptive/accurate. An "instance class" as we have been calling it is really an instance of a singleton class, a class that will only ever have this one instance as a member, so we don't give it a tag name (which is why we think of it as anonymous).

--
Henry Minsky
Software Architect
hminsky@...

Re: [Laszlo-reviews] For Review: Change 20091120-hqm-i Summary: support mixins on instances

2009-11-20T08:00:02Z

[laszlo-reviews -> laszlo-dev]

I'll try to look at this in just a bit, but I had a thought:

I wonder if instead of `anonymous` we should use `singleton`, I think that might be more descriptive/accurate. An "instance class" as we have been calling it is really an instance of a singleton class, a class that will only ever have this one instance as a member, so we don't give it a tag name (which is why we think of it as anonymous).

Runtime-independent Binary Libraries [Was: [UPDATE^2] For Review: Change 20091118-ptw-8 Summary: Binary compiler tweaks]

2009-11-20T06:48:11Z

[cc-ing Laszlo-dev]

On 2009-11-19, at 18:38, Max Carlson wrote:

> Okay, so now that we're compiling (yay!) I've been going through to see what stops the app from running.
>
> On the LPS side, there are lots of errors with the av, drawview and html components. html is lzx, so it's not so easy to rewrite to <script/> syntax...
>
> I noticed extensions/av/mediastream contains:
>
> <class name="mediastream" extends="node">
> <switch>
> <when property="$as3">
> <passthrough>
> import flash.media.*;
> import flash.events.*;
> import flash.net.NetConnection;
> import flash.net.NetStream;
> import flash.utils.setTimeout;
> </passthrough>
> </when>
> </switch>
>
> Which got me thinking: could we allow library compilation for a specific runtime(s)? Either the library would support a given runtime, or it wouldn't.
>
> Then we could put off this notion of runtime-independent libraries for a little while. It's not clear to me that cross-runtime lzos are a requirement at this time - though they would be nice.

Good point. There are really 2 parts to runtime-indepencence for binary libraries:

1) Make the compiler emit a binary library in a format that can be linked on any platform. This is what the majority of the current work has been toward. There were some major bugs in the old binary library format that meant that even if you compiled for a particular platform, it just wasn't going to work (there were some parts that were hard-wired to assume a particular target platform). That's mostly fixed.

2) IWBRN to have a single binary library that could be linked and compiled to any platform. I think we are real close to having this, modulo the <switch> issue (http://jira.openlaszlo.org/jira/browse/LPP-8623), and as you point out, the <passthrough> tag (http://jira.openlaszlo.org/jira/browse/LPP-8608). If necessary, we can fall back to runtime-specific binary libraries, but I'd like to push a little further to see if we can avoid that.

Note that if you are not actually binary-compiling a file (for example mediastream above is an autoinclude, not part of the library you are binary compiling), the compiler could issue a less dreadful warning, because the only issue then is that if you define new <class>s in the switch body, they will not be seen by the binary compiler and could lead to the compile failing (if there is a class in the binary compile that depends on a class defined inside a <switch> in an external include).

So, one solution to the <switch> problem is simply to move any <switch>s that you _must_ have, out of the binary-compiled library to an external include that is not binary-compiled.