Re: For Review: Change 41001 Summary:Optimize LzView.updateSize

LPP-1915

On 2006-03-30 07:37 EST, P T Withington wrote:

> We could probably also write a similar transform to make this  
> sendEvent optimization, for cases where it is called directly.

Re: For Review: Change 41060 Summary: Automate unit tests using rhino. IN PROGRESS DON'T COMMIT!

_______________________________________________
Laszlo-dev mailing list
Laszlo-dev <at> openlaszlo.org
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev

Re: optimiziation for inheriting fontsize/name properties

On 2006-03-31 17:59 EST, Neil Mix wrote:

> That looks a lot like a cloning operation:
>
> function cloneObject(obj) {
>   var clone = {};
>   for(var n in obj) {
>     clone[n] = obj[n];
>   }
>   return clone;
> }

Except the clone will not track changes in the object it was cloned  
from.  By using the prototype chain, if a view inherits a style from  
its parent and the parent's style changes, the view would see it  
too.  (Hm, but there would still need to be an event sent to tell the  
child view to notice the change...)  [Note in my code I set the css  
object to have the parent object as it's prototype, and then set the  
local values from the init args into the local css, which will cause  
them to override any in the parent.  If you want to dynamically  
revert an overridden style to inherit from the parent, you just  
delete it and the parent value will be exposed.]

>>> use prototype-inheritance to give you memo-izing for nearly free.
>
> By "for nearly free" do you mean "without performance overhead"?

I mean, the chasing up the immediateparent chain would be done in the  
runtime (presumably _much_ faster than could be done by a Javascript  
for loop).

> On Mar 31, 2006, at 3:23 PM, P T Withington wrote:
>
>> I believe so.  I'm thinking you do something like this:
>>
>> // How to make a new object with an existing object as its prototype
>> // in standard Javascript
>> function makeNewObjectWithAnotherObjectAsItsPrototype  
>> (anotherObject) {
>>    var xtor = function () {};
>>    xtor.prototype = anotherObject;
>>    return new xtor();
>> }
>>
>> // Assuming the css attributes of a particular view are passed as  
>> a hash
>> // named style: in initargs
>> View.init = function (initargs) {
>>    var style = initargs['style'];
>>    var css = makeNewObjectWithAnotherObjectAsItsPrototype
>> (immediateparent.css);
>>    for (var k in style) {
>>      css[k] = style[k];
>>    }
>>    this.css = css;
>> }
>>
>> On 2006-03-31 16:01 EST, Henry Minsky wrote:
>>
>>>
>>>
>>> On 3/31/06, P T Withington <ptw <at> openlaszlo.org> wrote: I agree.  My
>>> question was about whether these things were inherited
>>> along the parent or immediateparent chain.  Since you don't know the
>>> immediateparent at compile time, it would be impossible to make any
>>> compile-time optimization.  Also, I'm suggesting that if you break
>>> these 'cascading' attributes out into separate objects, they could
>>> use prototype-inheritance to give you memo-izing for nearly free.
>>>
>>> Instead of putting the cascading attributes directly on the view,  
>>> put
>>> them in an object/hash that can have a different inheritance chain
>>> (i.e., the one specified by immediate parent).
>>>
>>> 'zat making any sense?
>>>
>>>
>>> Can we do that in IE JScript?
>>>
>>> On 2006-03-31 15:30 EST, Henry Minsky wrote:
>>>
>>>> We have some code that attempts to compute the font size/name/style
>>>> attributes at compile time, which means it has to use a model of
>>>> the default
>>>> attribute values ofr classes, etc. That code is there in
>>>> ViewCompiler to do
>>>> that, and  it works but is kind of baroque, so I was leaning  
>>>> towards
>>>> removing it if there would be not a runtime performance impact ; it
>>>> seems
>>>> like optimizing the runtime to memoize the inherited font all along
>>>> the
>>>> parent chain would be step towards increasing the runtime
>>>> efficiency, and
>>>> thus making the compile-time calculations less neccessary.
>>>>
>>>>
>>>>
>>>> On 3/31/06, P T Withington <ptw <at> openlaszlo.org> wrote:
>>>>>
>>>>> a) Is the font really determined by the immediate (dynamic)  
>>>>> parent?
>>>>> That's annoying because it means you can't compute it at compile
>>>>> time.
>>>>>
>>>>> b) If css properties like this _are_ determined by the immediate
>>>>> parent, then perhaps the props should all be stored in a
>>> separate css
>>>>> attribute and we could use proto-based inheritance to do the
>>> lookup.
>>>>> E.g., css would be an attribute of view that is a hash, and the
>>>>> hash's __proto__ would be the immediate parent's css hash.
>>>>
>>>>
>>>>
>>>> Is that something which behaves like the DHTML CSS model (which we
>>>> would
>>>> want to use I would think).
>>>>
>>>> On 2006-03-31 09:41 EST, Henry Minsky wrote:
>>>>>
>>>>>> The text class calls
>>>>>>
>>>>>>         this.fontname = this.searchParents 
>>>>>> ( "fontname" ).fontname;
>>>>>>
>>>>>> for font name/size/style properties
>>>>>>
>>>>>> searchParents is implemented as
>>>>>>
>>>>>> LzView.prototype.searchParents = function ( prop ){
>>>>>>     var sview = this;
>>>>>>     do{
>>>>>>         sview = sview.immediateparent;
>>>>>>         if (sview[ prop ] != null ){
>>>>>>             return sview;
>>>>>>         }
>>>>>>     }while ( sview != canvas );
>>>>>> }
>>>>>>
>>>>>> Would it be more efficient if the searchParents function set the
>>>>>> properties
>>>>>> all the way back down the parent
>>>>>> chain when it found one, so that other calls wouldn't have to
>>>>>> search up past
>>>>>> their first parent? It seems like with the
>>>>>> way the value is filled in now, that wouldn't change the behavior
>>>>>> because in
>>>>>> the current code the font style attributes which are null at
>>>>>> runtime are
>>>>>> found and cached on a text element, and then modifying the parent
>>>>>> has no
>>>>>> subsequent effect on the text font style. So caching the parent
>>>>>> values as
>>>>>> well wouldn't change things anyway.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Henry Minsky
>>>>>> Software Architect
>>>>>> hminsky <at> laszlosystems.com
>>>>>> _______________________________________________
>>>>>> Laszlo-dev mailing list
>>>>>> Laszlo-dev <at> openlaszlo.org
>>>>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Henry Minsky
>>>> Software Architect
>>>> hminsky <at> laszlosystems.com
>>>
>>>
>>>
>>>
>>> -- 
>>> Henry Minsky
>>> Software Architect
>>> hminsky <at> laszlosystems.com
>>>
>>
>> _______________________________________________
>> Laszlo-dev mailing list
>> Laszlo-dev <at> openlaszlo.org
>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>

Re: For Review: Change 41060 Summary: Automate unit tests using rhino. IN PROGRESS DON'T COMMIT!

Henry Minsky wrote:

> I installed Debian on my Linux box a while ago, and I have been unable 
> to figure out how to install a working JVM on it, anyone have a clue?

I just install the .bin file from: 
http://java.sun.com/j2se/1.4.2/download.html

and set the environment vairables by hand.

~md

>
>
>
> On 3/31/06, * Benjamin Shine* <ben <at> laszlosystems.com 
> <mailto:ben <at> laszlosystems.com>> wrote:
>
>
>     This an improved version of the changeset with the first part of
>     lzjum. I'm tracking down a problem with cygwin, but this should work
>     on linux and mac. Requires dojo, sync //depot/tools/dojo-
>     nightly-3.27.06/... then run ant lzjum.
>
>     dojo includes rhino, fyi.
>
>     Change 41060 by ben <at> ben-g5 on 2006/03/30 19:09:41 *pending*
>
>             Summary: Automate unit tests using rhino.
>
>             New Features: ant lzjum compiles and runs a very simple
>     lzx file.
>
>             Bugs Fixed:
>
>             Technical Reviewer:  hminsky, max (pending)
>             QA Reviewer:  mdavis
>             Doc Reviewer:  (pending)
>
>             Documentation:
>
>             Release Notes:
>
>             Details:
>
>             Tests:
>
>     Affected files ...
>
>     ... //depot/lps-legals/build.xml#6 edit
>     ... //depot/lps-legals/jum/lfc_dhtml_includes.js#1 add
>     ... //depot/lps-legals/jum/lfc_includes.js#1 add
>     ... //depot/lps-legals/test/jum-call.lzx#1 add
>
>
>
>
>
>
> -- 
> Henry Minsky
> Software Architect
> hminsky <at> laszlosystems.com <mailto:hminsky <at> laszlosystems.com>
>

--

-- 
--- 
Mark Davis
Sr. Manager, QA & IT -- Laszlo Systems
${this.title} -- OpenLaszlo.org 

Re: For Review: Change 41060 Summary: Automate unit tests using rhino. IN PROGRESS DON'T COMMIT!

_______________________________________________
Laszlo-dev mailing list
Laszlo-dev <at> openlaszlo.org
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev

log4j logs

Where do the log4j logs go when lzc is invoked from the command line?
-ben

benjamin shine
software engineer
laszlo systems

Re: log4j logs

I thought they went to stderr.  There is some secret config somewhere  
that does that...  Actually, try lzc --help, I think you can make it  
go wherever you want with the --log parameters.

On 2006-03-31 21:51 EST, Benjamin Shine wrote:

>
> Where do the log4j logs go when lzc is invoked from the command line?
> -ben
>
> benjamin shine
> software engineer
> laszlo systems
> _______________________________________________
> Laszlo-dev mailing list
> Laszlo-dev <at> openlaszlo.org
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev

For Review: Change 41100 Summary: Ant task to compile and invoke unit tests using rhino.

Now works on windows! And mac!
"ant lzjum" should do it.

Success looks like this:
lzjum.rhino:
      [java] (BUFakeDom.js) initializing fake DOM document
      [java] DEBUG: i am calling jum.debug from inside jum-call.lzx
      [java] i am calling print from inside jum-call.lzx
      [java] DEBUG: good, 100==100
      [java] DEBUG: this is good i think:

BUILD SUCCESSFUL

Change 41100 by ben <at> ben-g5 on 2006/03/31 19:36:13 *pending*

	Summary: Ant task to compile and invoke unit tests using rhino.
	Now we invoke lzc as a bona-fide java, not just with "exec",
	because exec doesn't work well on Windows.
	Now we listen to environment & system information specified in
         antland, ie, LPS_HOME.

         New Features:

         Bugs Fixed:

         Technical Reviewer: hminsky (pending)
         QA Reviewer:  (pending)
         Doc Reviewer:  (pending)

         Documentation:

         Release Notes:

         Details:

         Tests:

_______________________________________________
Laszlo-dev mailing list
Laszlo-dev <at> openlaszlo.org
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev

Re: log4j logs

Indeed:
lzc -v --runtime=dhtml --log lzclog.log test/jum-call.lzx
puts nice logging information into lzclog.log

and puts the compiled script into test/jum-call.swf
(So cool.)

Thanks, Tucker.

On Mar 31, 2006, at 7:06 PM, P T Withington wrote:

> I thought they went to stderr.  There is some secret config  
> somewhere that does that...  Actually, try lzc --help, I think you  
> can make it go wherever you want with the --log parameters.
>
> On 2006-03-31 21:51 EST, Benjamin Shine wrote:
>
>>
>> Where do the log4j logs go when lzc is invoked from the command line?
>> -ben
>>
>> benjamin shine
>> software engineer
>> laszlo systems
>> _______________________________________________
>> Laszlo-dev mailing list
>> Laszlo-dev <at> openlaszlo.org
>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>

Re: optimiziation for inheriting fontsize/name properties

That's very clever.  And I'm humbled -- you just taught me something  
about JavaScript that I didn't previously know.  This language slays  
me -- after 4 years of it I still don't have it down.  :/  Neat.

On Mar 31, 2006, at 5:33 PM, P T Withington wrote:

> On 2006-03-31 17:59 EST, Neil Mix wrote:
>
>> That looks a lot like a cloning operation:
>>
>> function cloneObject(obj) {
>>   var clone = {};
>>   for(var n in obj) {
>>     clone[n] = obj[n];
>>   }
>>   return clone;
>> }
>
> Except the clone will not track changes in the object it was cloned  
> from.  By using the prototype chain, if a view inherits a style  
> from its parent and the parent's style changes, the view would see  
> it too.  (Hm, but there would still need to be an event sent to  
> tell the child view to notice the change...)  [Note in my code I  
> set the css object to have the parent object as it's prototype, and  
> then set the local values from the init args into the local css,  
> which will cause them to override any in the parent.  If you want  
> to dynamically revert an overridden style to inherit from the  
> parent, you just delete it and the parent value will be exposed.]
>
>>>> use prototype-inheritance to give you memo-izing for nearly free.
>>
>> By "for nearly free" do you mean "without performance overhead"?
>
> I mean, the chasing up the immediateparent chain would be done in  
> the runtime (presumably _much_ faster than could be done by a  
> Javascript for loop).
>
>> On Mar 31, 2006, at 3:23 PM, P T Withington wrote:
>>
>>> I believe so.  I'm thinking you do something like this:
>>>
>>> // How to make a new object with an existing object as its prototype
>>> // in standard Javascript
>>> function makeNewObjectWithAnotherObjectAsItsPrototype  
>>> (anotherObject) {
>>>    var xtor = function () {};
>>>    xtor.prototype = anotherObject;
>>>    return new xtor();
>>> }
>>>
>>> // Assuming the css attributes of a particular view are passed as  
>>> a hash
>>> // named style: in initargs
>>> View.init = function (initargs) {
>>>    var style = initargs['style'];
>>>    var css = makeNewObjectWithAnotherObjectAsItsPrototype
>>> (immediateparent.css);
>>>    for (var k in style) {
>>>      css[k] = style[k];
>>>    }
>>>    this.css = css;
>>> }
>>>
>>> On 2006-03-31 16:01 EST, Henry Minsky wrote:
>>>
>>>>
>>>>
>>>> On 3/31/06, P T Withington <ptw <at> openlaszlo.org> wrote: I agree.  My
>>>> question was about whether these things were inherited
>>>> along the parent or immediateparent chain.  Since you don't know  
>>>> the
>>>> immediateparent at compile time, it would be impossible to make any
>>>> compile-time optimization.  Also, I'm suggesting that if you break
>>>> these 'cascading' attributes out into separate objects, they could
>>>> use prototype-inheritance to give you memo-izing for nearly free.
>>>>
>>>> Instead of putting the cascading attributes directly on the  
>>>> view, put
>>>> them in an object/hash that can have a different inheritance chain
>>>> (i.e., the one specified by immediate parent).
>>>>
>>>> 'zat making any sense?
>>>>
>>>>
>>>> Can we do that in IE JScript?
>>>>
>>>> On 2006-03-31 15:30 EST, Henry Minsky wrote:
>>>>
>>>>> We have some code that attempts to compute the font size/name/ 
>>>>> style
>>>>> attributes at compile time, which means it has to use a model of
>>>>> the default
>>>>> attribute values ofr classes, etc. That code is there in
>>>>> ViewCompiler to do
>>>>> that, and  it works but is kind of baroque, so I was leaning  
>>>>> towards
>>>>> removing it if there would be not a runtime performance  
>>>>> impact ; it
>>>>> seems
>>>>> like optimizing the runtime to memoize the inherited font all  
>>>>> along
>>>>> the
>>>>> parent chain would be step towards increasing the runtime
>>>>> efficiency, and
>>>>> thus making the compile-time calculations less neccessary.
>>>>>
>>>>>
>>>>>
>>>>> On 3/31/06, P T Withington <ptw <at> openlaszlo.org> wrote:
>>>>>>
>>>>>> a) Is the font really determined by the immediate (dynamic)  
>>>>>> parent?
>>>>>> That's annoying because it means you can't compute it at compile
>>>>>> time.
>>>>>>
>>>>>> b) If css properties like this _are_ determined by the immediate
>>>>>> parent, then perhaps the props should all be stored in a
>>>> separate css
>>>>>> attribute and we could use proto-based inheritance to do the
>>>> lookup.
>>>>>> E.g., css would be an attribute of view that is a hash, and the
>>>>>> hash's __proto__ would be the immediate parent's css hash.
>>>>>
>>>>>
>>>>>
>>>>> Is that something which behaves like the DHTML CSS model (which we
>>>>> would
>>>>> want to use I would think).
>>>>>
>>>>> On 2006-03-31 09:41 EST, Henry Minsky wrote:
>>>>>>
>>>>>>> The text class calls
>>>>>>>
>>>>>>>         this.fontname = this.searchParents 
>>>>>>> ( "fontname" ).fontname;
>>>>>>>
>>>>>>> for font name/size/style properties
>>>>>>>
>>>>>>> searchParents is implemented as
>>>>>>>
>>>>>>> LzView.prototype.searchParents = function ( prop ){
>>>>>>>     var sview = this;
>>>>>>>     do{
>>>>>>>         sview = sview.immediateparent;
>>>>>>>         if (sview[ prop ] != null ){
>>>>>>>             return sview;
>>>>>>>         }
>>>>>>>     }while ( sview != canvas );
>>>>>>> }
>>>>>>>
>>>>>>> Would it be more efficient if the searchParents function set the
>>>>>>> properties
>>>>>>> all the way back down the parent
>>>>>>> chain when it found one, so that other calls wouldn't have to
>>>>>>> search up past
>>>>>>> their first parent? It seems like with the
>>>>>>> way the value is filled in now, that wouldn't change the  
>>>>>>> behavior
>>>>>>> because in
>>>>>>> the current code the font style attributes which are null at
>>>>>>> runtime are
>>>>>>> found and cached on a text element, and then modifying the  
>>>>>>> parent
>>>>>>> has no
>>>>>>> subsequent effect on the text font style. So caching the parent
>>>>>>> values as
>>>>>>> well wouldn't change things anyway.
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Henry Minsky
>>>>>>> Software Architect
>>>>>>> hminsky <at> laszlosystems.com
>>>>>>> _______________________________________________
>>>>>>> Laszlo-dev mailing list
>>>>>>> Laszlo-dev <at> openlaszlo.org
>>>>>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Henry Minsky
>>>>> Software Architect
>>>>> hminsky <at> laszlosystems.com
>>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>> Henry Minsky
>>>> Software Architect
>>>> hminsky <at> laszlosystems.com
>>>>
>>>
>>> _______________________________________________
>>> Laszlo-dev mailing list
>>> Laszlo-dev <at> openlaszlo.org
>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>
>