Benjamin Shine | 1 May 03:00 2006

error building on windows: C:\WINDOWS\system32\ntvdm.exe

Windows people: has anyone seen this error before, or know what to do  
about it? It seems to occur when actually invoking "ant build" to  
build LPS from source.

Googling ntvdm.exe seems to indicate that it's related to a registry  
error. This sort of thing is why I hate windows.

16 bit MS-DOS Subsystem
C:\WINDOWS\system32\ntvdm.exe
Error while setting up environment. Choose 'Close' to terminate the  
application.

Thanks to James Caple for bringing this one to my attention.

benjamin shine
software engineer
ben <at> laszlosystems.com
Henry Minsky | 1 May 18:59 2006
Picon

not putting names of dataset so many places

Tucker asked at one point if we could cut down the number of different places
we put in a pointer to a dataset.

We've got these three in the LzDataset.setName method:

    if ( this.oncanvas ){
        global[ name ] = this;
        canvas[ name ] = this;
    } else {
        // it's local - add the parent's UID
        name = this.parent.getUID() + '.' + name;
    }

    canvas.datasets[name] = this;

Would this be a good time to clean this up a little and pick one (or two) of the these choices?


--
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
Jim Grandy | 1 May 21:58 2006

Re: not putting names of dataset so many places

I'd be in favor of the following:

- add a 'global:' axis to match the 'local:' axis

- force use of <at> id attribute for global datasets -- that is, don't register in global/canvas namespace at all unless <at> id is given

We could add the 'global:' axis in 3.3 with declaration without <at> id deprecated in that release, and then require <at> id for global datasets in 4.0. We'd also make 'global:' the default in 3.3, and 'local:' (or neither) the default in 4.0.

I think this would be the cleanest and simplest -- <at> id is how you namebind in global namespaace, period. Just like HTML/CSS. Also, making 'local:' axis the default would match our move in the components to more data-driven design -- local datasets should be more common in 4.0 than global datasets.

I haven't thought deeply about the compat issues here, but I think this is pretty straightforward.

jim


On May 1, 2006, at 9:59 AM, Henry Minsky wrote:

Tucker asked at one point if we could cut down the number of different places
we put in a pointer to a dataset.

We've got these three in the LzDataset.setName method:

    if ( this.oncanvas ){
        global[ name ] = this;
        canvas[ name ] = this;
    } else {
        // it's local - add the parent's UID
        name = this.parent.getUID() + '.' + name;
    }

    canvas.datasets[name] = this;

Would this be a good time to clean this up a little and pick one (or two) of the these choices?


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

_______________________________________________
Laszlo-dev mailing list

_______________________________________________
Laszlo-dev mailing list
Laszlo-dev <at> openlaszlo.org
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
John Sundman | 1 May 22:49 2006

Re: not putting names of dataset so many places

OK.

if this is going into 3.3 I need to get right on it.

Just to be sure I understand this, can I see some examples please?

jrs

On May 1, 2006, at 3:58 PM, Jim Grandy wrote:

> I'd be in favor of the following:
>
> - add a 'global:' axis to match the 'local:' axis
>
> - force use of  <at> id attribute for global datasets -- that is, don't 
> register in global/canvas namespace at all unless  <at> id is given
>
> We could add the 'global:' axis in 3.3 with declaration without  <at> id 
> deprecated in that release, and then require  <at> id for global datasets 
> in 4.0. We'd also make 'global:' the default in 3.3, and 'local:' (or 
> neither) the default in 4.0.
>
> I think this would be the cleanest and simplest --  <at> id is how you 
> namebind in global namespaace, period. Just like HTML/CSS. Also, 
> making 'local:' axis the default would match our move in the 
> components to more data-driven design -- local datasets should be more 
> common in 4.0 than global datasets.
>
> I haven't thought deeply about the compat issues here, but I think 
> this is pretty straightforward.
>
> jim
>
>
> On May 1, 2006, at 9:59 AM, Henry Minsky wrote:
>
>> Tucker asked at one point if we could cut down the number of 
>> different places
>> we put in a pointer to a dataset.
>>
>> We've got these three in the LzDataset.setName method:
>>
>>     if ( this.oncanvas ){
>>         global[ name ] = this;
>>         canvas[ name ] = this;
>>     } else {
>>         // it's local - add the parent's UID
>>         name = this.parent.getUID() + '.' + name;
>>     }
>>
>>     canvas.datasets[name] = this;
>>
>> Would this be a good time to clean this up a little and pick one (or 
>> two) of the these choices?
>>
>>
>> -- 
>> 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
>
> _______________________________________________
> Laszlo-dev mailing list
> Laszlo-dev <at> openlaszlo.org
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
Henry Minsky | 1 May 22:45 2006
Picon

Re: [Laszlo-user] Upgraded package common-httpclient to version 3

I didn't check this in yet, pending a contributor agreement.

When I do check it in I was planning for it to go into the lps-legals branch, although I could check it into lps-dev if people are eager to get it sooner in a nightly build.

There were a couple of other source changes needed to support the newer library. I have attached is the full change set if other people want to apply it themselves for some reason.



On 5/1/06, William Krick <wkrick <at> eio-online.com> wrote:
I didn't see this change in the change log of the nightly builds.
Did it get accepted?

If not, you should probably submit a bug...

http://www.openlaszlo.org/jira/

...and attach your changed files to the bug for inclusion.





-----Original Message-----
From: DanteTHB <at> attackonline.net [mailto: DanteTHB <at> attackonline.net]
Sent: Friday, April 07, 2006 2:51 AM
To: laszlo-user <at> openlaszlo.org
Subject: [Laszlo-user] Upgraded package common-httpclient to version 3


Hi <at> all!

So, i´ve updated the lib file common-httpclient to version 3.
Here are the changed classes.

Hope this will help!

Attachment --> upgradedClasses_httpclientv3.zip

Best Regards

Dante

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



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

Attachment (changeset-41272.zip): application/zip, 855 KiB
_______________________________________________
Laszlo-dev mailing list
Laszlo-dev <at> openlaszlo.org
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
Henry Minsky | 1 May 22:56 2006
Picon

Re: not putting names of dataset so many places

Swapping the default for the scope
of the dataset name in the xpath query from global to local would
be a pretty incompatible change in terms of existing
code, I dunno if  that would be a
4.0 kind of thing or not.



On 5/1/06, John Sundman <jsundman <at> laszlosystems.com> wrote:
OK.

if this is going into 3.3 I need to get right on it.

Just to be sure I understand this, can I see some examples please?

jrs

On May 1, 2006, at 3:58 PM, Jim Grandy wrote:

> I'd be in favor of the following:
>
> - add a 'global:' axis to match the 'local:' axis
>
> - force use of <at> id attribute for global datasets -- that is, don't
> register in global/canvas namespace at all unless <at> id is given
>
> We could add the 'global:' axis in 3.3 with declaration without <at> id
> deprecated in that release, and then require <at> id for global datasets
> in 4.0. We'd also make 'global:' the default in 3.3, and 'local:' (or
> neither) the default in 4.0.
>
> I think this would be the cleanest and simplest -- <at> id is how you
> namebind in global namespaace, period. Just like HTML/CSS. Also,
> making 'local:' axis the default would match our move in the
> components to more data-driven design -- local datasets should be more
> common in 4.0 than global datasets.
>
> I haven't thought deeply about the compat issues here, but I think
> this is pretty straightforward.
>
> jim
>
>
> On May 1, 2006, at 9:59 AM, Henry Minsky wrote:
>
>> Tucker asked at one point if we could cut down the number of
>> different places
>> we put in a pointer to a dataset.
>>
>> We've got these three in the LzDataset.setName method:
>>
>>     if ( this.oncanvas ){
>>         global[ name ] = this;
>>         canvas[ name ] = this;
>>     } else {
>>         // it's local - add the parent's UID
>>         name = this.parent.getUID() + '.' + name;
>>     }
>>
>>     canvas.datasets[name] = this;
>>
>> Would this be a good time to clean this up a little and pick one (or
>> two) of the these choices?
>>
>>
>> --
>> 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
>
> _______________________________________________
> 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

_______________________________________________
Laszlo-dev mailing list
Laszlo-dev <at> openlaszlo.org
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
Jim Grandy | 1 May 23:17 2006

Re: not putting names of dataset so many places

We're just working out a proposal. Nothing's set in stone yet.

We also don't have a 3.3 schedule -- 3.2.1 is what's going out the  
door soon.

On May 1, 2006, at 1:49 PM, John Sundman wrote:

> OK.
>
> if this is going into 3.3 I need to get right on it.
>
> Just to be sure I understand this, can I see some examples please?
>
> jrs
>
> On May 1, 2006, at 3:58 PM, Jim Grandy wrote:
>
>> I'd be in favor of the following:
>>
>> - add a 'global:' axis to match the 'local:' axis
>>
>> - force use of  <at> id attribute for global datasets -- that is, don't  
>> register in global/canvas namespace at all unless  <at> id is given
>>
>> We could add the 'global:' axis in 3.3 with declaration without  
>>  <at> id deprecated in that release, and then require  <at> id for global  
>> datasets in 4.0. We'd also make 'global:' the default in 3.3, and  
>> 'local:' (or neither) the default in 4.0.
>>
>> I think this would be the cleanest and simplest --  <at> id is how you  
>> namebind in global namespaace, period. Just like HTML/CSS. Also,  
>> making 'local:' axis the default would match our move in the  
>> components to more data-driven design -- local datasets should be  
>> more common in 4.0 than global datasets.
>>
>> I haven't thought deeply about the compat issues here, but I think  
>> this is pretty straightforward.
>>
>> jim
>>
>>
>> On May 1, 2006, at 9:59 AM, Henry Minsky wrote:
>>
>>> Tucker asked at one point if we could cut down the number of  
>>> different places
>>> we put in a pointer to a dataset.
>>>
>>> We've got these three in the LzDataset.setName method:
>>>
>>>     if ( this.oncanvas ){
>>>         global[ name ] = this;
>>>         canvas[ name ] = this;
>>>     } else {
>>>         // it's local - add the parent's UID
>>>         name = this.parent.getUID() + '.' + name;
>>>     }
>>>
>>>     canvas.datasets[name] = this;
>>>
>>> Would this be a good time to clean this up a little and pick one  
>>> (or two) of the these choices?
>>>
>>>
>>> -- 
>>> 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
>>
>> _______________________________________________
>> Laszlo-dev mailing list
>> Laszlo-dev <at> openlaszlo.org
>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>
Jim Grandy | 1 May 23:18 2006

Re: not putting names of dataset so many places

Yes, it would be an incompatible change. We could deprecate implicit-global in 4.0 and either remove or switch the default in a later release.

What do you think of the proposal otherwise? Should we write it up more formally?

On May 1, 2006, at 1:56 PM, Henry Minsky wrote:

Swapping the default for the scope
of the dataset name in the xpath query from global to local would
be a pretty incompatible change in terms of existing
code, I dunno if  that would be a
4.0 kind of thing or not.



On 5/1/06, John Sundman <jsundman <at> laszlosystems.com> wrote:
OK.

if this is going into 3.3 I need to get right on it.

Just to be sure I understand this, can I see some examples please?

jrs

On May 1, 2006, at 3:58 PM, Jim Grandy wrote:

> I'd be in favor of the following:
>
> - add a 'global:' axis to match the 'local:' axis
>
> - force use of <at> id attribute for global datasets -- that is, don't
> register in global/canvas namespace at all unless <at> id is given
>
> We could add the 'global:' axis in 3.3 with declaration without <at> id
> deprecated in that release, and then require <at> id for global datasets
> in 4.0. We'd also make 'global:' the default in 3.3, and 'local:' (or
> neither) the default in 4.0.
>
> I think this would be the cleanest and simplest -- <at> id is how you
> namebind in global namespaace, period. Just like HTML/CSS. Also,
> making 'local:' axis the default would match our move in the
> components to more data-driven design -- local datasets should be more
> common in 4.0 than global datasets.
>
> I haven't thought deeply about the compat issues here, but I think
> this is pretty straightforward.
>
> jim
>
>
> On May 1, 2006, at 9:59 AM, Henry Minsky wrote:
>
>> Tucker asked at one point if we could cut down the number of
>> different places
>> we put in a pointer to a dataset.
>>
>> We've got these three in the LzDataset.setName method:
>>
>>     if ( this.oncanvas ){
>>         global[ name ] = this;
>>         canvas[ name ] = this;
>>     } else {
>>         // it's local - add the parent's UID
>>         name = this.parent.getUID() + '.' + name;
>>     }
>>
>>     canvas.datasets[name] = this;
>>
>> Would this be a good time to clean this up a little and pick one (or
>> two) of the these choices?
>>
>>
>> --
>> 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
>
> _______________________________________________
> 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


_______________________________________________
Laszlo-dev mailing list
Laszlo-dev <at> openlaszlo.org
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
Jim Grandy | 1 May 23:19 2006

Re: [Laszlo-user] Upgraded package common-httpclient to version 3

If there's no -legals dependency, let's put it into lps-dev (after a contributor agreement and appropriate reviews/testing, of course). Is this likely to be a fragile change?

On May 1, 2006, at 1:45 PM, Henry Minsky wrote:

I didn't check this in yet, pending a contributor agreement.

When I do check it in I was planning for it to go into the lps-legals branch, although I could check it into lps-dev if people are eager to get it sooner in a nightly build.

There were a couple of other source changes needed to support the newer library. I have attached is the full change set if other people want to apply it themselves for some reason.



On 5/1/06, William Krick <wkrick <at> eio-online.com> wrote:
I didn't see this change in the change log of the nightly builds.
Did it get accepted?

If not, you should probably submit a bug...

http://www.openlaszlo.org/jira/

...and attach your changed files to the bug for inclusion.





-----Original Message-----
From: DanteTHB <at> attackonline.net [mailto: DanteTHB <at> attackonline.net]
Sent: Friday, April 07, 2006 2:51 AM
To: laszlo-user <at> openlaszlo.org
Subject: [Laszlo-user] Upgraded package common-httpclient to version 3


Hi <at> all!

So, i´ve updated the lib file common-httpclient to version 3.
Here are the changed classes.

Hope this will help!

Attachment --> upgradedClasses_httpclientv3.zip

Best Regards

Dante

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



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

<changeset-41272.zip>
_______________________________________________
Laszlo-dev mailing list

_______________________________________________
Laszlo-dev mailing list
Laszlo-dev <at> openlaszlo.org
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
Cortlandt Winters | 1 May 23:55 2006
Picon

Re: error building on windows: C:\WINDOWS\system32\ntvdm.exe

Hi Benjamin,

I got that message once when I got too hopped up about cygwin and installed too many libraries from it. When I went back to a default install + a select few extras it went away. I'm sorry I can't tell you which libraries, but my best guess is that they were network ones or compiler ones.

I have long wished that they would force every process to contain a url link to detailed info about itself. I guess that would be too much like the internet as an operating system.

So it goes.

-Cort

On 4/30/06, Benjamin Shine <ben <at> laszlosystems.com> wrote:
Windows people: has anyone seen this error before, or know what to do
about it? It seems to occur when actually invoking "ant build" to
build LPS from source.

Googling ntvdm.exe seems to indicate that it's related to a registry
error. This sort of thing is why I hate windows.

16 bit MS-DOS Subsystem
C:\WINDOWS\system32\ntvdm.exe
Error while setting up environment. Choose 'Close' to terminate the
application.

Thanks to James Caple for bringing this one to my attention.

benjamin shine
software engineer
ben <at> laszlosystems.com



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

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

Gmane