Frisco Del Rosario | 1 Aug 01:38
Favicon

"Unexpected element 'condition' " causing Windows build to fail

frisco <at> laszlo-frisco ~/src/svn/openlaszlo/trunk
$ ant build
Buildfile: build.xml

BUILD FAILED
file:C:/cygwin/home/frisco/src/svn/openlaszlo/trunk/build.xml:86:  
Unexpected ele
ment "condition"

Total time: 2 seconds

This is the pertinent line in build.xml:

<!-- Properties describing which OS as binary flags -->
     <condition property="os.isunix">
         <equals arg1="${build.platform}" arg2="unix"/>
     </condition>

--
Frisco Del Rosario
Tester, OpenLaszlo and IDE4Laszlo
Scott Evans | 1 Aug 02:19
Favicon

Re: 2 spaces or 4?

I never voted for 4!  I vote for consistency.  But I'm personally a big 
fan of 2.  And a 100-ish column screen width!  (hi pablo)

gse

On Tue, 25 Jul 2006, P T Withington wrote:

> Scott, please explain yourself.  4 seems wasteful.
> 
> Long lines are considered harmful, no matter how wide your average screen.
> Have you read the Times lately?
> 
> On 2006-07-25, at 13:36 EDT, Benjamin Shine wrote:
> 
> > 
> > 4! 4! 4!
> > Which I only say after having Scott slap me around repeatedly for doing it
> > wrong.
> > I used to be into 3, myself.
> > While we're at it, DARE WE come up with a line length recommended limit?
> > Pablo uses
> > 80 and maybe you hardcore oldskoolers do, but please, have you seen the size
> > of the standard screen lately? Show me a coder who doesn't have at least
> > 1280 across and I'll show you... um.
> > 
> > On Jul 25, 2006, at 7:05 AM, P T Withington wrote:
> > 
> > > After the 'grand class conversion', Phil and I plan to re-indent the
> > > LFC sources.  [Right now Phil is making the conversion trying to
> > > minimize the whitespace changes to make it easy to review.  Once we
(Continue reading)

Scott Evans | 1 Aug 02:19
Favicon

Re: 2 spaces or 4?

XML needs 2 spaces more than anything!

On Fri, 28 Jul 2006, Jim Grandy wrote:

> Perhaps that argues for 2 spaces for .js/.lzs/.as files and 4 spaces  
> for .lzx files...
> 
> On Jul 28, 2006, at 4:49 AM, P T Withington wrote:
> 
> > Yes, I have the design whitespace issue fairly well beaten into me by
> > Neil.
> >
> > But is it true you can never have too much whitespace?  Why do we use
> > only 4 spaces?  Why not 8, or 80?  I can see that 1 is not visually
> > distinct, but in a fixed width font, 2 seems enough.  And if we
> > enforce 80 cols, 4 can start to seem wasteful.  There are deeply
> > nested blocks in the LFC where the lines get _very_ short because of
> > the 4-space indent.
> >
> > Now that we are moving to class declarations, your function body
> > starts out with 2 levels of indentation, add a little control flow,
> > and before you know it, you have less than 50 chars left on your  
> > line...
> >
> > On 2006-07-28, at 00:33 EDT, Sarah Allen wrote:
> >
> >> my $.02...
> >>
> >> I like 4 spaces, but maybe that's just because Adam insisted upon
> >> in at the beginning of time and I've just gotten used to it.
(Continue reading)

Max Carlson | 1 Aug 02:58
Favicon

For Review: Change change.e7nv4C8e9.txt Summary: Fix image loading in IE DHTML at the source level for now. Without backtraces, It's too difficult. I'll fix the issue in the LFC later.

Change change.e7nv4C8e9.txt by maxcarlson <at> max-carlsons- 
computer.local /Users/maxcarlson/openlaszlo/legals-pr2/ on 2006-07-31  
15:52:21 PDT

Summary: Fix image loading in IE DHTML at the source level for now.   
Without backtraces, It's too difficult.  I'll fix the issue in the  
LFC later.

New Features:

Bugs Fixed: LPP-2241 - Top row of thumbnails goes blank while  
scrolling in DHTML

Technical Reviewer: henry
QA Reviewer: ptw
Doc Reviewer: (pending)

Documentation:

Release Notes:

Details:

Tests: To see the original bug, run lps/includes/lfc/test/ 
resourceload.lzx

Files:
M      demos/lzpix/classes/photo.lzx

(Continue reading)

Max Carlson | 1 Aug 04:05
Favicon

For Review: Change change.gXa09uSFp.txt Summary: Fix LPP-2357 in LZX source, disable hack in sprite (easy, thanks to requires/provides) and reopen LPP-2357 as a standing bug. The workaround breaks drag and drop in IE :(

Change change.gXa09uSFp.txt by maxcarlson <at> max-carlsons- 
computer.local /Users/maxcarlson/openlaszlo/legals-pr2/ on 2006-07-31  
19:00:25 PDT

Summary: Fix LPP-2357 in LZX source, disable hack in sprite (easy,  
thanks to requires/provides) and reopen LPP-2357 as a standing bug.   
The workaround breaks drag and drop in IE :(

New Features:

Bugs Fixed: LPP-2357 is fixed for the app, but remains open as a  
deprioritized LFC bug.  The source-level fix makes sense and is  
simpler than the original LZX which was likely a workaround for  
differences between runtime functionality...

Technical Reviewer: henry
QA Reviewer: jgrandy
Doc Reviewer: (pending)

Documentation:

Release Notes:

Details:

Tests:

Files:
M      WEB-INF/lps/lfc/kernel/dhtml/LzRequires.js
M      demos/lzpix/views/details.lzx
(Continue reading)

Henry Minsky | 1 Aug 05:17
Picon

Re: For Review: Change change.e7nv4C8e9.txt Summary: Fix image loading in IE DHTML at the source level for now. Without backtraces, It's too difficult. I'll fix the issue in the LFC later.

approved

On 7/31/06, Max Carlson <max <at> openlaszlo.org> wrote:
Change change.e7nv4C8e9.txt by maxcarlson <at> max-carlsons-
computer.local /Users/maxcarlson/openlaszlo/legals-pr2/ on 2006-07-31
15:52:21 PDT

Summary: Fix image loading in IE DHTML at the source level for now.
Without backtraces, It's too difficult.  I'll fix the issue in the
LFC later.

New Features:

Bugs Fixed: LPP-2241 - Top row of thumbnails goes blank while
scrolling in DHTML

Technical Reviewer: henry
QA Reviewer: ptw
Doc Reviewer: (pending)

Documentation:

Release Notes:

Details:


Tests: To see the original bug, run lps/includes/lfc/test/
resourceload.lzx

Files:
M      demos/lzpix/classes/photo.lzx






--
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 | 1 Aug 05:30
Picon

Re: For Review: Change change.gXa09uSFp.txt Summary: Fix LPP-2357 in LZX source, disable hack in sprite (easy, thanks to requires/provides) and reopen LPP-2357 as a standing bug. The workaround breaks drag and drop in IE :(

approved

On 7/31/06, Max Carlson <max <at> openlaszlo.org> wrote:
Change change.gXa09uSFp.txt by maxcarlson <at> max-carlsons-
computer.local /Users/maxcarlson/openlaszlo/legals-pr2/ on 2006-07-31
19:00:25 PDT

Summary: Fix LPP-2357 in LZX source, disable hack in sprite (easy,
thanks to requires/provides) and reopen LPP-2357 as a standing bug.
The workaround breaks drag and drop in IE :(

New Features:

Bugs Fixed: LPP-2357 is fixed for the app, but remains open as a
deprioritized LFC bug.  The source-level fix makes sense and is
simpler than the original LZX which was likely a workaround for
differences between runtime functionality...

Technical Reviewer: henry
QA Reviewer: jgrandy
Doc Reviewer: (pending)

Documentation:

Release Notes:

Details:


Tests:

Files:
M      WEB-INF/lps/lfc/kernel/dhtml/LzRequires.js
M      demos/lzpix/views/details.lzx






--
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 | 1 Aug 06:04
Picon

warning when calling setAttribute on destroyed node?

I came across an error in DHTML which is hard to reproduce but seems like it might have been due
to an animator calling setAttribute on a node which had already had destroy() called on it.
At least, that was the only way I could see that the 'setters' slot could be null on an LzNode.

http://www.openlaszlo.org/jira/browse/LPP-2447

So I'm proposing putting a check into setAttribute which checks if setters is null, and gives a warning in debug
mode. Anyone think this is a good or bad idea?


LzNode.prototype.setAttribute = function(prop, val) {
    // <at> field String name: The name for this subnode. If given, then this node's
    //parent and immediate parent will use store a pointer to this node as the
    //given name value

    // <at> field String id: A global identifer for this node. If given, a pointer
    //to this node with the given value will be placed in the global namespace

    // <at> field String datapath: The string to use as this node's datapath. This
    //usually creates a datapath that attaches to the node.

    if ( this.setters == null || null == this.setters[ prop ] ){
        if ( $debug && this.setters == null){
            Debug.warn( "setAttribute called on destroy()'ed node: ", prop, val, this );
        }
        this[ prop ] = val;
        var evt = ("on" + prop);
        if (evt in this) {
            this[ evt ].sendEvent( val );
        }
    } else {
        this[ this.setters [ prop ] ] ( val );
    }
}

--
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
Benjamin Shine | 1 Aug 06:09
Favicon

Re: "Unexpected element 'condition' " causing Windows build to fail

Hm. The condition element is built-in to ant:
http://ant.apache.org/manual/CoreTasks/condition.html
and trunk builds have been working, and work right now for me...

This implies that there is something wrong with your ant setup. Did  
this *just* break, or has this been broken? Have you been able to get  
a good build of trunk on this machine ever? If it's still endless  
pain, maybe it's time to restart the install in a clean user  
environment.

On Jul 31, 2006, at 4:38 PM, Frisco Del Rosario wrote:

> frisco <at> laszlo-frisco ~/src/svn/openlaszlo/trunk
> $ ant build
> Buildfile: build.xml
>
> BUILD FAILED
> file:C:/cygwin/home/frisco/src/svn/openlaszlo/trunk/build.xml:86:
> Unexpected ele
> ment "condition"
>
> Total time: 2 seconds
>
> This is the pertinent line in build.xml:
>
> <!-- Properties describing which OS as binary flags -->
>      <condition property="os.isunix">
>          <equals arg1="${build.platform}" arg2="unix"/>
>      </condition>
>
> --
> Frisco Del Rosario
> Tester, OpenLaszlo and IDE4Laszlo
>
>
>
> _______________________________________________
> Laszlo-dev mailing list
> Laszlo-dev <at> openlaszlo.org
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
Henry Minsky | 1 Aug 07:20
Picon

for review Change change.bEAaK5100.txt workaround for LPP-2377 - hide details button

Change change.bEAaK5100.txt by hqm <at> domokun /home/hqm/src/svn/openlaszlo/branches/legals-pr2/demos/ on 2006-08-01 01:14:53 EDT

Summary: workaround for LPP-2377 - hide details button

New Features:

Bugs Fixed:LPP-2377

Technical Reviewer: max (pending)
QA Reviewer: mkratt (pending)
Doc Reviewer: (pending)

Documentation:

Release Notes:

Details:

work around a bug in mouse handling in DHTML / Safari runtime

opening new bug to describe the underlying problem

Removed the transparent overlay on hideDetailsButton and added an onclick handler
on the parent view.



Tests:

Files:
M      lzpix/app.lzx


--
Henry Minsky
Software Architect
hminsky <at> laszlosystems.com

Attachment (patch.hqm.5680.tgz): application/x-gzip, 1047 bytes
_______________________________________________
Laszlo-dev mailing list
Laszlo-dev <at> openlaszlo.org
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev

Gmane