Re: Script locals in library stack script

[J. Landman Gay via use-livecode]

I know, that's why I didn't report it. I scoured the script looking for 
a difference but I couldn't find anything, the two queries were executed 
by the same handler. I looked for anything that would empty the variable 
and that wasn't there either.


My current theory is creeping stack corruption. The stack ran with only 
this one oddity, but when I tried to reload it from disk later it was 
reported as corrupted and wouldn't open. I had to open it in BBEdit and 
use a days-old backup in LC to paste in all the changes. Apparently it 
had corrupted several days before, but because I'd left the Mac on with 
the stack open I didn't know.


I've sent the working stack and the corrupted one to bugzilla though I 
don't know if the team can make anything of it. The missing variable 
appeared in LC 8.1.2 so I switched over to LC 9 to see if that helped. 
That's when the stack gave up. I think I'll stay away from 9 until it's 
out of dp, but there's something going on with LC 8 too in some unique 
circumstance. I haven't had any trouble with 8 before now.


On 2/10/17 8:47 PM, Bob Sneidar via use-livecode wrote:

I don't mean to oversimplify, but when customers call complaing that only one 
of several scan to SMB registrations is failing, I have to get them to see that 
if all the others are not failing ever, it cannot be a problem with the copier.

If only one script local is getting reset, then it cannot be that LC is 
resetting script locals because they would ALL reset, not just one.

It may be possible to set a breakpoint on the script local to trigger when it 
becomes empty.

Bob S



On Feb 10, 2017, at 12:22 , J. Landman Gay via use-livecode 
 wrote:

The extremely odd thing was that the script had three script locals, and only 
one of them lost its value. The other two were fine. It was impossible to track 
down.



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode




--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Windows and OSX 64-bit builds?

[Phil Davis via use-livecode]

Your labels are one order of magnitude off the actual values, Bob. Say 
it with me: 1,024,000,000 BYTES is "one billion bytes" (and change, 
depending on whose standard you use). Of course one billion bytes is a 
gigabyte.


Same with the labeling of 1,024,000 BYTES = 1000kb = a megabyte, not a gig.

FWIW -
Phil Davis


On 2/10/17 6:57 PM, Bob Sneidar via use-livecode wrote:

isn't it kBytes not bits? So 32,000 * 32000 Bytes (a pixel takes up one Byte in 
8 bit color) which comes to 1,024,000,000 BYTES. That's 1.024 terabytes, unless 
my faculties have wholly abandoned me. Of course, a black and white image is 
1,024,000 BYTES, or 1.023 GIGS, but are we talking about black and white images?

That said, I am a couple strong ales in at this point, sooo...

Bob S



On Feb 10, 2017, at 10:33 , Mark Waddingham via use-livecode 
 wrote:

As you correctly point out 32k x 32k comes in at 1Gb pixels - which at 24-bit 
RGB comes out at 4Gb of data.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode



--
Phil Davis


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Windows and OSX 64-bit builds?

[Bob Sneidar via use-livecode]

Essentially, eat the elephant one byte at a time. (see what I did there??)

Bob S


> On Feb 10, 2017, at 15:41 , Tom Glod via use-livecode 
>  wrote:
> 
> can't  thank you enough for all the extra info markI'm going to read it
> over a few times to make sure I got everything I could out of it.   will
> re-engage this idea as I go forward ... I still need to lock down my
> maximum presets, so I will still have to play with this in a week or so.
> 
> Thanks


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Windows and OSX 64-bit builds?

[Bob Sneidar via use-livecode]

isn't it kBytes not bits? So 32,000 * 32000 Bytes (a pixel takes up one Byte in 
8 bit color) which comes to 1,024,000,000 BYTES. That's 1.024 terabytes, unless 
my faculties have wholly abandoned me. Of course, a black and white image is 
1,024,000 BYTES, or 1.023 GIGS, but are we talking about black and white images?

That said, I am a couple strong ales in at this point, sooo...

Bob S


> On Feb 10, 2017, at 10:33 , Mark Waddingham via use-livecode 
>  wrote:
> 
> As you correctly point out 32k x 32k comes in at 1Gb pixels - which at 24-bit 
> RGB comes out at 4Gb of data. 


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Script locals in library stack script

[Bob Sneidar via use-livecode]

I don't mean to oversimplify, but when customers call complaing that only one 
of several scan to SMB registrations is failing, I have to get them to see that 
if all the others are not failing ever, it cannot be a problem with the copier. 

If only one script local is getting reset, then it cannot be that LC is 
resetting script locals because they would ALL reset, not just one. 

It may be possible to set a breakpoint on the script local to trigger when it 
becomes empty. 

Bob S


> On Feb 10, 2017, at 12:22 , J. Landman Gay via use-livecode 
>  wrote:
> 
> The extremely odd thing was that the script had three script locals, and only 
> one of them lost its value. The other two were fine. It was impossible to 
> track down.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Windows and OSX 64-bit builds?

[Richard Gaskin via use-livecode]

I would second that, with an extension:  it would be most helpful to 
have some guidance on memory management overall.


Many see the total addressable space afforded by 64-bit systems as 
"Cool, I can use a 16-terabyte array!"


But as we've seen in bits and pieces here and elsewhere, total 
addressable memory is not what LC will necessarily use, or can use, for 
many tasks.  And it some cases it may not be what we really want to do.


OS APIs impose their own limits, and many other factors can come into 
play as well.


It would be useful to have at least some general guidance on what those 
limitations are, both in terms of LC as it is today and in terms where 
it bumps into system limits and general memory management challenges.


Often these implications aren't obvious.

For example, this morning I noted the difficulty with exporting an image 
of a 5000 X 5000 px button on Ubuntu.  Later I tried a set of much 
smaller objects but spread out much more broadly (10k px and more), and 
LC remained very responsive throughout - even exported the snapshot fine.


So I'm guessing from this that the difficulty with making unusually 
large standard controls was specific to how Linux' GDK handles them 
internally.  Indeed, making LC-handled objects, like graphics, 
apparently have no problem being rendered and buffered at such sizes.


Rather than make this an attempt at an exhaustive study of memory 
implications (though I'd gladly read it, it would take too long to 
write), it might be nice if Mark could draw from examples he's seen in 
the community over the years to outline some of the more commonly 
requested scenarios.


--
 Richard Gaskin


hh wrote:


Please post this "Split it!"- answer, as it is, in LC's blog.
This is good even for real beginners.

Large files or large data shouldn't be a reason for _incomplete_ 64Bit
implementations that would make once again LC Script slower.


Mark Waddingham wrote:
>
> Tom Glod wrote:
> I will... if u wanna replicate...put an image on a stack..make it
> 32k x 32k
> . and try and do a export snapshot of the image,  LC goes POOF...
> Trevor
> said tha last version of 8 (8.13)  had some memory issues solves, so i
> will try to test is there too.

Currently, the engine implements 'export snapshot' by allocating a
raster (32-bits per pixel) of the size of the snapshot you are making,
rendering into it and then compressing it.

So really the maximum size you could hope to snapshot is 16k x* 16k
pixels as that requires 2Gb - the engine in general uses signed integer
indicies, so the maximum memory buffer it can manipulate is 2Gb bytes. A
32-bit process would probably struggle to do that (due to only having
around 2-3Gb of user address space to use) - as there is overhead in
rasterization and then compression; but a 64-bit process should be fine.

There is a bug here as (at least in this specific case) the engine
should fail gracefully (as we know there is a hard limit in the size of
an image the engine can process).

As you correctly point out 32k x 32k comes in at 1Gb pixels - which at
24-bit RGB comes out at 4Gb of data. No 'normal' 32-bit application
which isn't explicitly designed for manipulating huge images will be
able to deal with something that size. I would expect applications such
as Photoshop to be able to deal with them though since I believe their
native raw storage format for images pages from disk as required (so you
never have the 'whole thing' in memory at once - just the bit you are
looking at / editing).

One important thing to remember is that the amount of memory required to
take a snapshot is (SOMECONSTANT * 4 * the number of pixels) in the rect
of the snapshot (I've not checked but I would estimate 0 < SOMECONSTANT
< 2) which means that you can get LiveCode to generate very large
images, but you have to break the problem down by splitting up the
snapshot into bands and probably use an external (command-line) tool to
compress the image into your format of choice (how big an image such a
tool can process, again, will be dependent on whether it needs to load
the entire image into memory to compress it or not).

Rough idea:

 repeat with i = 0 to pHeight / kBandSize
import snapshot from rect (0, pWidth, i * kBandSize, kBandSize)
write the imageData of the last image to file tOutputFile
delete the last image
 end repeat

After this you will have a very large file with the raw xRGB data in it,
so you need to find a tool which can take raw 32-bit xRGB data (with
specified order of the RGB), the width and height and process it into
jpg or png or whatever format you require (I'm hoping others who know
more about such things might be able to chime in here - ImageMagick has
an arsenal of command-line tools, for example).

Warmest Regards,

Mark.

P.S. There is a hard limit of co-ordinate magnitude in LC and thus the
size of any object - 32767 pixels on any side of anything.

Re: Windows and OSX 64-bit builds?

[Tom Glod via use-livecode]

can't  thank you enough for all the extra info markI'm going to read it
over a few times to make sure I got everything I could out of it.   will
re-engage this idea as I go forward ... I still need to lock down my
maximum presets, so I will still have to play with this in a week or so.

Thanks

On Fri, Feb 10, 2017 at 5:29 PM, hh via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Please post this "Split it!"- answer, as it is, in LC's blog.
> This is good even for real beginners.
>
> Large files or large data shouldn't be a reason for _incomplete_ 64Bit
> implementations that would make once again LC Script slower.
>
> > Mark Waddingham wrote:
> > >
> > > Tom Glod wrote:
> > > I will... if u wanna replicate...put an image on a stack..make it
> > > 32k x 32k
> > > . and try and do a export snapshot of the image,  LC goes POOF...
> > > Trevor
> > > said tha last version of 8 (8.13)  had some memory issues solves, so i
> > > will try to test is there too.
> >
> > Currently, the engine implements 'export snapshot' by allocating a
> > raster (32-bits per pixel) of the size of the snapshot you are making,
> > rendering into it and then compressing it.
> >
> > So really the maximum size you could hope to snapshot is 16k x* 16k
> > pixels as that requires 2Gb - the engine in general uses signed integer
> > indicies, so the maximum memory buffer it can manipulate is 2Gb bytes. A
> > 32-bit process would probably struggle to do that (due to only having
> > around 2-3Gb of user address space to use) - as there is overhead in
> > rasterization and then compression; but a 64-bit process should be fine.
> >
> > There is a bug here as (at least in this specific case) the engine
> > should fail gracefully (as we know there is a hard limit in the size of
> > an image the engine can process).
> >
> > As you correctly point out 32k x 32k comes in at 1Gb pixels - which at
> > 24-bit RGB comes out at 4Gb of data. No 'normal' 32-bit application
> > which isn't explicitly designed for manipulating huge images will be
> > able to deal with something that size. I would expect applications such
> > as Photoshop to be able to deal with them though since I believe their
> > native raw storage format for images pages from disk as required (so you
> > never have the 'whole thing' in memory at once - just the bit you are
> > looking at / editing).
> >
> > One important thing to remember is that the amount of memory required to
> > take a snapshot is (SOMECONSTANT * 4 * the number of pixels) in the rect
> > of the snapshot (I've not checked but I would estimate 0 < SOMECONSTANT
> > < 2) which means that you can get LiveCode to generate very large
> > images, but you have to break the problem down by splitting up the
> > snapshot into bands and probably use an external (command-line) tool to
> > compress the image into your format of choice (how big an image such a
> > tool can process, again, will be dependent on whether it needs to load
> > the entire image into memory to compress it or not).
> >
> > Rough idea:
> >
> >  repeat with i = 0 to pHeight / kBandSize
> > import snapshot from rect (0, pWidth, i * kBandSize, kBandSize)
> > write the imageData of the last image to file tOutputFile
> > delete the last image
> >  end repeat
> >
> > After this you will have a very large file with the raw xRGB data in it,
> > so you need to find a tool which can take raw 32-bit xRGB data (with
> > specified order of the RGB), the width and height and process it into
> > jpg or png or whatever format you require (I'm hoping others who know
> > more about such things might be able to chime in here - ImageMagick has
> > an arsenal of command-line tools, for example).
> >
> > Warmest Regards,
> >
> > Mark.
> >
> > P.S. There is a hard limit of co-ordinate magnitude in LC and thus the
> > size of any object - 32767 pixels on any side of anything.
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
*Tom Glod*

CEO @ *MakeShyft R.D.A* - www.makeshyft.com



Developer of *U.M.P* - www.IamUMP.com
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: [ ANN ] Release 8.1.3 RC-2

[Ali Lloyd via use-livecode]

Is it this bug?
http://quality.livecode.com/show_bug.cgi?id=18994

It would help if you posted a crash log too, we might be able to fix it
just from that.

On Fri, Feb 10, 2017 at 11:19 PM Dr. Hawkins via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I opened and tried to build my compilation amalgam of stacks.
>
> It promptly crashed "unexpectedly"
>
> This is consistent (and was the case with rc1, 8.1.1, etc.)
>
> Back to combining with 7.1 . . .
>
> 
>
>
>
> --
> Dr. Richard E. Hawkins, Esq.
> (702) 508-8462
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: [ ANN ] Release 8.1.3 RC-2

[Dr. Hawkins via use-livecode]

I opened and tried to build my compilation amalgam of stacks.

It promptly crashed "unexpectedly"

This is consistent (and was the case with rc1, 8.1.1, etc.)

Back to combining with 7.1 . . .





-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Windows and OSX 64-bit builds?

[hh via use-livecode]

Please post this "Split it!"- answer, as it is, in LC's blog.
This is good even for real beginners.

Large files or large data shouldn't be a reason for _incomplete_ 64Bit
implementations that would make once again LC Script slower.

> Mark Waddingham wrote:
> >
> > Tom Glod wrote:
> > I will... if u wanna replicate...put an image on a stack..make it
> > 32k x 32k
> > . and try and do a export snapshot of the image,  LC goes POOF... 
> > Trevor
> > said tha last version of 8 (8.13)  had some memory issues solves, so i 
> > will try to test is there too.
> 
> Currently, the engine implements 'export snapshot' by allocating a 
> raster (32-bits per pixel) of the size of the snapshot you are making, 
> rendering into it and then compressing it.
> 
> So really the maximum size you could hope to snapshot is 16k x* 16k 
> pixels as that requires 2Gb - the engine in general uses signed integer 
> indicies, so the maximum memory buffer it can manipulate is 2Gb bytes. A 
> 32-bit process would probably struggle to do that (due to only having 
> around 2-3Gb of user address space to use) - as there is overhead in 
> rasterization and then compression; but a 64-bit process should be fine.
> 
> There is a bug here as (at least in this specific case) the engine 
> should fail gracefully (as we know there is a hard limit in the size of 
> an image the engine can process).
> 
> As you correctly point out 32k x 32k comes in at 1Gb pixels - which at 
> 24-bit RGB comes out at 4Gb of data. No 'normal' 32-bit application 
> which isn't explicitly designed for manipulating huge images will be 
> able to deal with something that size. I would expect applications such 
> as Photoshop to be able to deal with them though since I believe their 
> native raw storage format for images pages from disk as required (so you 
> never have the 'whole thing' in memory at once - just the bit you are 
> looking at / editing).
> 
> One important thing to remember is that the amount of memory required to 
> take a snapshot is (SOMECONSTANT * 4 * the number of pixels) in the rect 
> of the snapshot (I've not checked but I would estimate 0 < SOMECONSTANT 
> < 2) which means that you can get LiveCode to generate very large 
> images, but you have to break the problem down by splitting up the 
> snapshot into bands and probably use an external (command-line) tool to 
> compress the image into your format of choice (how big an image such a 
> tool can process, again, will be dependent on whether it needs to load 
> the entire image into memory to compress it or not).
> 
> Rough idea:
> 
>  repeat with i = 0 to pHeight / kBandSize
> import snapshot from rect (0, pWidth, i * kBandSize, kBandSize)
> write the imageData of the last image to file tOutputFile
> delete the last image
>  end repeat
> 
> After this you will have a very large file with the raw xRGB data in it, 
> so you need to find a tool which can take raw 32-bit xRGB data (with 
> specified order of the RGB), the width and height and process it into 
> jpg or png or whatever format you require (I'm hoping others who know 
> more about such things might be able to chime in here - ImageMagick has 
> an arsenal of command-line tools, for example).
> 
> Warmest Regards,
> 
> Mark.
> 
> P.S. There is a hard limit of co-ordinate magnitude in LC and thus the 
> size of any object - 32767 pixels on any side of anything.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Script locals in library stack script

[Bob Hall via use-livecode]

 —>There used to be a way to do that but I can't remember how, or else I forgot 
it on purpose because it didn't work.

I think this is how you would do that…

in IDE, debug menu->Add variable watch

select the library stack and sVarA in the pop up.

What I haven’t tested is the Condition. Maybe "is empty"

You could also add "if sVarA is empty then breakpoint” at interesting points in 
the script. 

Bob Hall


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

automating enabling of plugin settings on new versions

[Dr. Hawkins via use-livecode]

WE went through parts of this a while ago, and being naturally lazy, I came
up with

chmod -R u+w `ls -rtd
/Applications/LiveCode*/Contents/Tools/Plugins/revapplicationoverview.rev |
tail -1`


as an invocation to write enable the plugin folder and its contents for the
most recent version (OS X; linux will be similar and depend upon variant)

This changes the mode (chmod) recursively; the ls finds the version with
the latter date stamp.

However, even though the mode changes, I still can't write, and have to
manually load the application browser.

Isn't that folder the only thing we used to need to changer am I missing
something?
-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Script locals in library stack script

[J. Landman Gay via use-livecode]

On 2/10/17 5:56 AM, Bob Hall via use-livecode wrote:

I’ve been wondering this myself. I’m going to try to create a recipe
but it looks like the TTL of script local variables is different than
what I thought I knew it to be. I “think” I started see this behavior
about 8.1.0-ish timeframe but not sure.

In the past few months I started to put everything into properties as
I found that my understanding of how script local variables behaved
was different then how they do.


I have set the LC preference to preserve variables. In the past I have 
rarely seen a script local lose its value, and never if there has been 
no script compile. I don't know exactly when it started but I was in 
8.1.3 rc 1 when I noticed it. I spent two days trying to fix the 
problem, eventually gave up and worked around it. The extremely odd 
thing was that the script had three script locals, and only one of them 
lost its value. The other two were fine. It was impossible to track down.


Here is what I was doing:

Stack Main has a substack "InternetLib" that contains all handlers that 
deal with server connections. It is put in use when Main opens. 
InternetLib handles server queries and returns the retrieved data. That 
all works fine. It also has a "setter" handler that can be used to store 
data in a script local variable in its own script, and a "getter" 
handler to return data from the script local.


What happened:

1. Stack Main calls InternetLib to do a query.
2. Stack Main manipulates the returned data, parses out what it needs, 
and calls the "setter" handler to store it in the script local "sVarA" 
in InternetLib.
3. Immediately after the handler ends, Stack Main calls InternetLib to 
do a second query.
4. Stack Main uses the returned data and calls the "setter" handler to 
store the value in InternetLib script local "sVarB".

5. Later, stack Main tries to retrieve a value from sVarA. sVarA is empty.
6. Retrieving data from sVarB is always available.

The third script local, sVarC, always retains its value. It is not 
involved with the above process, it is set earlier when Main is opened.


When tracing through the handlers, it appears that sVarA loses its value 
some time between the first query and the second. What I need to do is 
find a way to track sVarA to see when it changes. There used to be a way 
to do that but I can't remember how, or else I forgot it on purpose 
because it didn't work.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Windows and OSX 64-bit builds?

[Mark Waddingham via use-livecode]

On 2017-02-10 03:38, Tom Glod via use-livecode wrote:
I will... if u wanna replicate...put an image on a stack..make it 32k x 
32k
.and try and do a export snapshot of the image,  LC goes POOF... 
Trevor
said tha last version of 8 (8.13)  had some memory issues solves, so i 
will

try to test is there too.


Currently, the engine implements 'export snapshot' by allocating a 
raster (32-bits per pixel) of the size of the snapshot you are making, 
rendering into it and then compressing it.


So really the maximum size you could hope to snapshot is 16k x* 16k 
pixels as that requires 2Gb - the engine in general uses signed integer 
indicies, so the maximum memory buffer it can manipulate is 2Gb bytes. A 
32-bit process would probably struggle to do that (due to only having 
around 2-3Gb of user address space to use) - as there is overhead in 
rasterization and then compression; but a 64-bit process should be fine.


There is a bug here as (at least in this specific case) the engine 
should fail gracefully (as we know there is a hard limit in the size of 
an image the engine can process).


As you correctly point out 32k x 32k comes in at 1Gb pixels - which at 
24-bit RGB comes out at 4Gb of data. No 'normal' 32-bit application 
which isn't explicitly designed for manipulating huge images will be 
able to deal with something that size. I would expect applications such 
as Photoshop to be able to deal with them though since I believe their 
native raw storage format for images pages from disk as required (so you 
never have the 'whole thing' in memory at once - just the bit you are 
looking at / editing).


One important thing to remember is that the amount of memory required to 
take a snapshot is (SOMECONSTANT * 4 * the number of pixels) in the rect 
of the snapshot (I've not checked but I would estimate 0 < SOMECONSTANT 
< 2) which means that you can get LiveCode to generate very large 
images, but you have to break the problem down by splitting up the 
snapshot into bands and probably use an external (command-line) tool to 
compress the image into your format of choice (how big an image such a 
tool can process, again, will be dependent on whether it needs to load 
the entire image into memory to compress it or not).


Rough idea:

repeat with i = 0 to pHeight / kBandSize

  import snapshot from rect (0, pWidth, i * kBandSize, kBandSize)

  write the imageData of the last image to file tOutputFile

  delete the last image

   end repeat

After this you will have a very large file with the raw xRGB data in it, 
so you need to find a tool which can take raw 32-bit xRGB data (with 
specified order of the RGB), the width and height and process it into 
jpg or png or whatever format you require (I'm hoping others who know 
more about such things might be able to chime in here - ImageMagick has 
an arsenal of command-line tools, for example).


Warmest Regards,

Mark.

P.S. There is a hard limit of co-ordinate magnitude in LC and thus the 
size of any object - 32767 pixels on any side of anything.


--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: "Deleting" Stacks in Memory - What About Behaviors?

[J. Landman Gay via use-livecode]

How would the engine know whether that behavior is used elsewhere, or will 
be needed in the stack that opens next? The easiest way to get the behavior 
you want, without any scripting, is to put the script in a button in the 
stack. Then when the stack is deleted, the behavior is gone.


If you're using script only stacks, it's not difficult to remove the script 
stack when you no longer need it.



On February 10, 2017 10:45:01 AM Sannyasin Brahmanathaswami via 
use-livecode  wrote:


When we delete a main stack, the main stack and all its substacks are 
removed from memory.


But if we delete a stack that has behaviors set from external 
*_behavior.livecodescript  stacks for controls in the "main" (parent?) 
stack, those behaviors are still in memory.


Does it make sense to file an enhancement request, to at least allow the 
dev to set a preference


__ Delete behavior stacks from memory when stack using them are deleted 
[YES/NO]



--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Transition to and from Fullscreen

[David V Glasgow via use-livecode]

Sorry, should know better.

Mac Sierra with LC 7.1.3

Going fullscreen true first hides the entire window, then the backdrop appears, 
and then the window itself.  Just how ugly that is depends what is present in 
the background.  If the backdrop appeared first, things would look better.

In fact, if you preset the backdrop so that isn’t a change between states, two 
out of three or four transitions look OK, and then there will be one with a 
nasty flash.

Cheers,

David G

> On 10 Feb 2017, at 5:57 pm, Richard Gaskin via use-livecode 
>  wrote:
> 
> David V Glasgow wrote:
> 
> > Has anyone managed to script away the ugly spasm that happens when
> > using the fullscreen command?
> >
> > I have tried all sorts, with either no effect or making matters
> > uglier.
> 
> Which LC version on which OS version?
> 
> Testing with v9 on Ubuntu 14.04, when I toggle the fullScreen of a stack it 
> gets bigger, then returns to its previous size, without much in the way of 
> rendering anomalies.
> 
> Can you describe this "spasm"?
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: "Deleting" Stacks in Memory - What About Behaviors?

[Bob Sneidar via use-livecode]

I was thinking the same thing. I'm pretty sure that when an app for Windows 
uses DotNET Framework, it takes some time to initially load the framework, then 
the app can launch. Once the app is quit, I do not think it unloads DotNET 
Framework, because the next time I launch the app, the process is almost 
instantaneous. 

If more than one app is using your "framework" (behavior script only stack) 
then it doesn't make sense to purge it. Now if you want to maintain a system of 
registering and unregistering your apps with your framework, and purging the 
framework when the last app quits, that would make sense. 

I find that a lot of times in lieu of an enhancement request, the problem can 
really be handled by a little ingenuity on the part of the end developer. As I 
have said in the past, Livecode is less like raw materials and a full set of 
tools (C variants or Java) and more like a constructor set. All the different 
parts have been made, and we really put the parts together to make something 
useful, like a toy house for example. The logical conclusion to any approach to 
less granularity than necessary would result in opening the box of the 
constructor set and finding inside walls and a roof. But what if I didn't want 
to make a house?? 

I guess I'm saying that it's more beneficial to keep as much flexibility in the 
hands of the developer as possible. It's up to us to detemine how best to put 
the parts together in a way that suits us. 

Bob S


> On Feb 10, 2017, at 09:48 , Richard Gaskin via use-livecode 
>  wrote:
> 
> > __ Delete behavior stacks from memory when stack using them are
> > deleted [YES/NO]
> 
> My vote: No.
> 
> Different stack, different purge.
> 
> I want to remain in control of when things get purged.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Transition to and from Fullscreen

[Richard Gaskin via use-livecode]

David V Glasgow wrote:

> Has anyone managed to script away the ugly spasm that happens when
> using the fullscreen command?
>
> I have tried all sorts, with either no effect or making matters
> uglier.

Which LC version on which OS version?

Testing with v9 on Ubuntu 14.04, when I toggle the fullScreen of a stack 
it gets bigger, then returns to its previous size, without much in the 
way of rendering anomalies.


Can you describe this "spasm"?

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Transition to and from Fullscreen

[David V Glasgow via use-livecode]

Has anyone managed to script away the ugly spasm that happens when using the 
fullscreen command?  

I have tried all sorts, with either no effect or making matters uglier.


Best Wishes,
David Glasgow

 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: "Deleting" Stacks in Memory - What About Behaviors?

[Richard Gaskin via use-livecode]

Sannyasin Brahmanathaswami wrote:

> When we delete a main stack, the main stack and all its substacks are
> removed from memory.
>
> But if we delete a stack that has behaviors set from external
> *_behavior.livecodescript  stacks for controls in the "main"
> (parent?) stack, those behaviors are still in memory.
>
> Does it make sense to file an enhancement request, to at least allow
> the dev to set a preference
>
> __ Delete behavior stacks from memory when stack using them are
> deleted [YES/NO]

My vote: No.

Different stack, different purge.

I want to remain in control of when things get purged.

Imagine, for example, an app that uses multiple documents.  Once I've 
inited the stack containing behavior scripts, I'll want to allow the 
user to open and close any document stacks they like during the session. 
 If I lost control over then behaviors are purged, I'd have to add code 
to ensure the stack with the behaviors is properly set up each time a 
document is opened.


And as someone who does a lot of LiveCode training, I've come to 
appreciate that the fewer "sometimes" rules we have the better.


Right now we give the developer the freedom to manage their own stack 
purging (however wonky that syntax may currently be).


If we introduce a "sometimes" rule about if some other stack happens to 
have an object that had been used as a behavior, things get muddy quickly.




> This is in line with trying to manage memory usage on small devices.
>
> Yes, someone will no doubt respond "but they are so small why are you
> worried?"
>
> But small android phone with limited RAM, really do need help keeping
> the heap as low as possible.  I am just looking for all possible
> means to clear ram, then set a "policy" in app to do all possible
> house keeping along the way: set images to empty, delete stacks not
> in use are the main two "tricks" we need to have that are obvious;
>
> But that leaves libraries and behaviors that are not in use. So if we
> *could* clean them up… why not do it.  Some times 200K means the diff
> between running and crashing on these "weak" devices.
>
> Obviouslyl if one is using Libraries with Start Using, the intent is
> probably that these are serving as globally accessible handlers. But
> this is not the case with behaviors attached to controls in a stack
> that may be deleted. So does it not make sense they are treated the
> same way as sub-stacks when their "parent" stack is deleted?
>
> Before filing an enhancement request I want to check here with
> everyone. What do you think?

If you want to purge things, purge them.

But please don't purge my things. :)

And given the relatively low overhead of all but the longest of scripts, 
I wonder how much of a difference it'll make in your app.


Could there be something with images or other RAM-heavy elements that 
may benefit from reviewing first?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Remote debugger vs other issues in targeting

[Pyyhtiä Christer via use-livecode]

The forthcoming Remote Debugger will definitely be of value in targeting 
LiveCode apps to the devices.  However, there are areas, especially in catching 
issues taking place in (nearly) real time, which I - and don't know how many 
others - have met as the most problematic ones.  Not all of the apps won't meet 
these, if developed to be "contained", that means working without external or 
file communication.

The examples having caused excessive headache to me include the following.

-  what happens in communication with the apps library purchasing options like 
subscription;
-  what happens with user clicks - there is a place for an Application Note how 
to make it correctly, for example to avoid double clicks received;
-  user entry into the fields, including the use of del key;
-  where did your PC (Program Counter - I belong to those ancient machine code 
programmers) get lost with chained subroutine / handler calls or continuous 
wake-up's (send to handler after...) and what was done to your global variables 
in what order;
-  why does the exact same user behaviour, for example with Samsung SGS 4 or 6 
or Sony Experia Tablet produce different route of actions as entries are of 
different code, and
-  what is the correct way of handling character sets with different devices' 
I/O and setups (like kb automatic text correction). 

The list is not exhaustive.

The problem escalates if you build a system using back-end server software 
(which thanks to LiveCode On-Rev is very, very easy and efficient), and use the 
file services and external communications from within. There even seems to be 
slightly different behaviour between the selected target devices with exactly 
same source code, how it is sent and received forth and back.  Getting 
expertise in every version turn.

This is not a manifest against the Remote Debugger, vice versa. Unfortunately 
could not extract from the demo if the headaches above could be addressed by 
the new functionality.

I would be interested to hear of any experiences from the user community 
tackling problems like described above.

thx

Christer Pyyhtiä
MindCrea Ltd
chris...@mindcrea.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Windows and OSX 64-bit builds?

[Dr. Hawkins via use-livecode]

On Fri, Feb 10, 2017 at 8:54 AM, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Granted LC should never crash, it whould warn the end user that the data
> exceeds limits, but if I understand what you are doing, it's unreasonable
> to expect any application to do this.
>
>
An, err, long time ago, I found that I could consistently crash both
FreeBSD and Linux by loading a file larger than virtual memory into a
binary editor . . .  (I had had to make an image of a hard disk to search
for versions of a paper when ~ got deleted.  While an older machine, the
hard drive than even VM on the other machine.  I eventually got the paper
back [maybe I split the file?]   . . . just manipulating it was no small
task.  [maybe I finally filtered the disk through strings or tr to a file
on a zip disk for transport?])


-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: How big of a request can be sent with https?

[Dr. Hawkins via use-livecode]

On Fri, Feb 10, 2017 at 9:00 AM, Mark Talluto via use-livecode <
use-livecode@lists.runrev.com> wrote:

> The size of the request is determined by your PHP settings. Most default
> settings range from 5MB to 10MB. You can set it to a much higher value if
> you really need it. But, it would be better to control the sizes of the
> requests client side for performance/robustness reasons.
>

Mine should be well below a megabyte.

It's a single request, as I need the queries to succeed/fail together, or I
could get an inconsistent state.


-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: [ ANN ] Release 8.1.3 RC-2

[Devin Asay via use-livecode]

I had just barely encountered this bug, and was *thinking* about filing a bug 
report. And now it’s fixed already!

That’s some fast work!

On Feb 10, 2017, at 9:34 AM, panagiotis merakos via use-livecode 
> wrote:

19185 - dragdata["private"] has no value in dragMove

Or maybe Panagiotis got ahold of Jacque’s time warp stack.

Devin


Devin Asay
Director
Office of Digital Humanities
Brigham Young University

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: How big of a request can be sent with https?

[Mark Talluto via use-livecode]

> On Feb 8, 2017, at 2:52 PM, Dr. Hawkins via use-livecode 
>  wrote:
> 
> I am contemplating the changes to, instead of direct postgres
> communication, using an https wrapper.
> 
> How big of an inquiry can I send?  Most are small, but when opening the
> file, there are something like a thousand queries as a single transaction,
> 


The size of the request is determined by your PHP settings. Most default 
settings range from 5MB to 10MB. You can set it to a much higher value if you 
really need it. But, it would be better to control the sizes of the requests 
client side for performance/robustness reasons.


Best regards,

Mark Talluto
livecloud.io
canelasoftware.com




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Windows and OSX 64-bit builds?

[Bob Sneidar via use-livecode]

That is a 28 FOOT image!!! at 8 bits per pixel that's 8.2 terabytes. At 24 bits 
per pixel it's 24.5 terabytes! Am I missing something?? My math skills may 
not be the best:

32000*32000*24

Granted LC should never crash, it whould warn the end user that the data 
exceeds limits, but if I understand what you are doing, it's unreasonable to 
expect any application to do this. 

Bob S



> On Feb 9, 2017, at 18:38 , Tom Glod via use-livecode 
>  wrote:
> 
> I will... if u wanna replicate...put an image on a stack..make it 32k x 32k
> .and try and do a export snapshot of the image,  LC goes POOF... Trevor
> said tha last version of 8 (8.13)  had some memory issues solves, so i will
> try to test is there too.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: [ ANN ] Release 8.1.3 RC-2

[Bob Sneidar via use-livecode]

THAT'S the bugger (see what I did there) that was keeping me from creating 
standalones!

Bob S


On Feb 10, 2017, at 08:34 , panagiotis merakos via use-livecode 
> wrote:

19174 - Unable to save as standalone when a substack has cantDelete = true

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

"Deleting" Stacks in Memory - What About Behaviors?

[Sannyasin Brahmanathaswami via use-livecode]

When we delete a main stack, the main stack and all its substacks are removed 
from memory.

But if we delete a stack that has behaviors set from external 
*_behavior.livecodescript  stacks for controls in the "main" (parent?) stack, 
those behaviors are still in memory.

Does it make sense to file an enhancement request, to at least allow the dev to 
set a preference

__ Delete behavior stacks from memory when stack using them are deleted [YES/NO]

This is in line with trying to manage memory usage on small devices.

Yes, someone will no doubt respond "but they are so small why are you worried?"

But small android phone with limited RAM, really do need help keeping the heap 
as low as possible.  I am just looking for all possible means to clear ram, 
then set a "policy" in app to do all possible house keeping along the way: set 
images to empty, delete stacks not in use are the main two "tricks" we need to 
have that are obvious;

But that leaves libraries and behaviors that are not in use. So if we *could* 
clean them up… why not do it.  Some times 200K means the diff between running 
and crashing on these "weak" devices.

Obviouslyl if one is using Libraries with Start Using, the intent is probably 
that these are serving as globally accessible handlers. But this is not the 
case with behaviors attached to controls in a stack that may be deleted. So 
does it not make sense they are treated the same way as sub-stacks when their 
"parent" stack is deleted?

Before filing an enhancement request I want to check here with everyone. What 
do you think?

BR
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

[ ANN ] Release 8.1.3 RC-2

[panagiotis merakos via use-livecode]

Dear list members,

We are pleased to announce the release of LiveCode 8.1.3 RC-2.

Getting the Release
===
You can get the release at https://downloads.livecode.com/livecode/ or via
the automatic updater.

Release Contents

LiveCode 8.1.3 RC-2 contains bug fixes and stability improvements.

In total, 90 bugs have been fixed since the last stable release (LiveCode
8.1.2).

Thanks to the people who tried out LiveCode 8.1.3 RC-1, we have been able
to identify and fix the following issues in this release:

19185 - dragdata["private"] has no value in dragMove
19105 - Crash in MCObject::message when deleting stack
19120 - Error when loading plugins in 8.1.3 rc-1
19174 - Unable to save as standalone when a substack has cantDelete = true
19127 - itunes rejecting because of non-public symbols
19158 - Crash when deleting object and then pressing cmd+z (Undo)
19121 - Incorrect folder path passed to standaloneSaved


The full release notes are available from:

http://downloads.livecode.com/livecode/8_1_3/LiveCodeNotes-8_1_3_rc_2.pdf

Feedback

Please report any bugs encountered on our BugZilla at
http://quality.livecode.com/

We have a forum available for discussing LiveCode Builder at
http://forums.livecode.com/viewforum.php?f=93

Have fun!

The LiveCode Team
--
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: PUT method where is returned data?

[Trevor DeVore via use-livecode]

On Fri, Feb 10, 2017 at 9:43 AM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> Thank you, Trevor.  With that explanation I can rest easy, since my older
> code only uses GET and POST.
>
> So to summarize, please let me know if any of the following is incorrect:
>
> Both "it" and "urlResponse" can be used to get return values from:
> GET
> POST
>
> "urlResonse" can be used to get return values from:
> GET
> POST
> PUT
> DELETE


That is correct.

-- 
Trevor DeVore
Outcome & ScreenSteps
www.outcomeapp.io - www.screensteps.com
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: PUT method where is returned data?

[Trevor DeVore via use-livecode]

On Fri, Feb 10, 2017 at 9:10 AM, Dr. Hawkins via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On Fri, Feb 10, 2017 at 6:52 AM, Trevor DeVore via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > It’s been so long I don’t recall the exact reasons why ‘it’
> > wasn’t used but I much prefer reading ’the urlresopnse’ in my code than
> > dealing with ‘it’ which is meaningless until put into another variable.
> >
>
> I have been horrified by "it" since HyperCard 1.0 was released . . .
>

I recall seeing “it” used frequently in code I read when first learning
LiveCode. A variable named “it” was more of a barrier than anything as it
made no sense where it was coming from. It just appeared in the code out of
thin air.

-- 
Trevor DeVore
Outcome & ScreenSteps
www.outcomeapp.io - www.screensteps.com
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Windows and OSX 64-bit builds?

[Richard Gaskin via use-livecode]

Tom Glod wrote:

> 10 K in resolution
>
> I'm going to do more tests with the 2 cache settings . compositor
> cache and image cache. increasing these definately lets me export
> snapshots of larger groups...but I have not succeeded in going past
> 10 K I can display up to 32k. but snapshot export just hard
> crashes Livecode as soon as it is triggered.   32,000*32,000*4 is
> 4GB+ .. I would like my customers to be able to output their
> content as large images.  10 k is large enough for now.

Curious about this, I ran a test in LC 9 with a new stack with one 
button containing this script:


on mouseUp
   set the rect of me to 0,0,6000,6000
   put specialFolderPath("desktop")&"/TestBigImage.png" into tFile
   export snapshot from me to file tFile as PNG
end mouseUp

On Ubuntu 14.04 w/8GB RAM I get the image file generated within seconds, 
but then LC takes another several seconds (almost a full minute!) with 
one CPU core maxed until it goes back to a normal idle.


Worse, while writing this email I was switching back and forth between 
my email client and LC, and apparently resume also takes nearly a full 
minute of maxed CPU before I'm able to work.


I'll run strace with that and file a bug report later to see what could 
be done, but back to your app's need:


Is raster output the best option for your users?

Even at 10k px that'll be a pretty big file, unwieldy in many image apps 
(and apparently prohibitive to export in the Linux version of LC currently).


It would be tedious but not too difficult to write a CardToSVG function 
instead, giving your users a widely-supported vector format whose file 
will be only slightly larger than the stack it was generated from 
(relatively speaking; being a plain-text format I'd guess the output 
size would be a small multiple of the stack file size, but certainly far 
less than a raster representation of the same layout).


I know Alejandro had written some SVG importers some time ago - anyone 
here have at least the beginnings of an SVG exporter we could build upon 
as a community project?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: PUT method where is returned data?

[Richard Gaskin via use-livecode]

Trevor DeVore wrote:

> The urlresponse has been around for a number of years. It was added
> so that you can get the response sent back from the server for url
> calls. It doesn’t affect how it behaves in any way. Prior to adding
> the urlresponse one couldn’t get the server response for PUT … into
> URL tURL or DELETE URL tURL calls. It’s been so long I don’t recall
> the exact reasons why ‘it’ wasn’t used but I much prefer reading
> ’the urlresopnse’ in my code than dealing with ‘it’ which is
> meaningless until put into another variable.

Thank you, Trevor.  With that explanation I can rest easy, since my 
older code only uses GET and POST.


So to summarize, please let me know if any of the following is incorrect:

Both "it" and "urlResponse" can be used to get return values from:
GET
POST

"urlResonse" can be used to get return values from:
GET
POST
PUT
DELETE

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Cancelling a script??

[Tim Selander via use-livecode]

Mike, that did the trick. I'll get into the same coding habit.

Thanks!

Tim Selander
Tokyo, Japan

On 2017.02.11, 0:09, Mike Bonner via use-livecode wrote:

If the loop is tight enough, the keypress never gets through.  I've just
got into the habit of putting an escape hatch into loops that can go wrong.
Something like:
if the environment is "development" and the shiftkey is down then exit to
top
(or if you want the user to have access to the same exit, don't check for
the environment)

Then all you have to do is hold shift and the loop will exit.

On Fri, Feb 10, 2017 at 8:00 AM, Tim Selander via use-livecode <
use-livecode@lists.runrev.com> wrote:


The documentation says Cmd + . should stop a running script.

I haveset the allowinterrupts to true  in my openstack script. But if
I get into a long repeat loop, cmd + . does not stop anything.

Community v8.1, OSX 10.9.

Any advice appreciated.

Tim Selander
Tokyo, Japan

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: PUT method where is returned data?

[Dr. Hawkins via use-livecode]

On Fri, Feb 10, 2017 at 6:52 AM, Trevor DeVore via use-livecode <
use-livecode@lists.runrev.com> wrote:

> It’s been so long I don’t recall the exact reasons why ‘it’
> wasn’t used but I much prefer reading ’the urlresopnse’ in my code than
> dealing with ‘it’ which is meaningless until put into another variable.
>

I have been horrified by "it" since HyperCard 1.0 was released . . .


-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Cancelling a script??

[Mike Bonner via use-livecode]

If the loop is tight enough, the keypress never gets through.  I've just
got into the habit of putting an escape hatch into loops that can go wrong.
Something like:
if the environment is "development" and the shiftkey is down then exit to
top
(or if you want the user to have access to the same exit, don't check for
the environment)

Then all you have to do is hold shift and the loop will exit.

On Fri, Feb 10, 2017 at 8:00 AM, Tim Selander via use-livecode <
use-livecode@lists.runrev.com> wrote:

> The documentation says Cmd + . should stop a running script.
>
> I haveset the allowinterrupts to true  in my openstack script. But if
> I get into a long repeat loop, cmd + . does not stop anything.
>
> Community v8.1, OSX 10.9.
>
> Any advice appreciated.
>
> Tim Selander
> Tokyo, Japan
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Script locals in library stack script

[Richard Gaskin via use-livecode]

Bob Hall wrote:

> So I guess I need to understand what is the TTL definition of a
> script local variable?

In the engine, script-local variables will retain their values 
throughout the session.


If a script is edited, however, by default the recompilation of the 
script causes the script-local variables to be cleared.


This default can be overridden with the preserveVariables property. 
False by default, when set to true script-local variables will retain 
their values between compilations of the script they appear in.


I had previously thought that the preserveVariables was a global 
property, which would mean its value is preserved throughout the 
session, and that the "Variable Preservation" checkbox in the "Script 
Editor" section of Prefs reflected that value.


However, the Dictionary does not specify that the preserveVariables is a 
global property, and there appears to be no relationship between the 
seemingly-related Prefs checkbox and this property - recipe:


1. In the Message Box, run: put the preserveVariables
2. In the MB, set the preserveVariables to the opposite
3. Open the Prefs window, note the checkbox
4. Close the Prefs window
5. In the MB, set the preserveVariables to its opposite
6. Open the Prefs window, not that the checkbox retains the true/false 
state seen before, even though the property itself has changed.


The Dictionary does say:

   The preserveVariables property is provided as a background
   compatibility aid. It should not, in general, be used in
   user scripts as the IDE automatically handles preservation
   of variables via the Variable Preservation option in the
   preferences and Script Editor Script menu.

So while I once thought I'd understood both the property and the 
seemingly-related Prefs setting, apparently I do not.


Guidance from the IDE team would be welcome here.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Cancelling a script??

[Tim Selander via use-livecode]

The documentation says Cmd + . should stop a running script.

I haveset the allowinterrupts to true  in my openstack 
script. But if I get into a long repeat loop, cmd + . does not 
stop anything.


Community v8.1, OSX 10.9.

Any advice appreciated.

Tim Selander
Tokyo, Japan

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: PUT method where is returned data?

[Trevor DeVore via use-livecode]

On Fri, Feb 10, 2017 at 8:47 AM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Devin Asay wrote:
>
> > On Feb 8, 2017, at 2:02 PM, Richard Gaskin wrote:
> >
> >> "it" is not longer a valid container for URL responses?
> >>
> >> I missed that memo.  Which version did that change take place in?
> >>
> >> My understanding is that GET requests are simply submitted in a
> >> LiveCode ‘put URL tURL into ” statement, and the results
> >> go into the container you designate. POST requests are returned to
> >> ‘it’.
> >
> > As far as I know it’s always been like this.
> >
> > The PUT results going to the urlResponse is a new one on me. But I’m
> > happy to know it.
>
> If urlResponse is offered as an alternative that may be useful, but if
> "it" is no longer valid at all it'll break a lot of scripts.


The urlresponse has been around for a number of years. It was added so that
you can get the response sent back from the server for url calls. It
doesn’t affect how it behaves in any way. Prior to adding the urlresponse
one couldn’t get the server response for PUT … into URL tURL or DELETE URL
tURL calls. It’s been so long I don’t recall the exact reasons why ‘it’
wasn’t used but I much prefer reading ’the urlresopnse’ in my code than
dealing with ‘it’ which is meaningless until put into another variable.

-- 
Trevor DeVore
Outcome & ScreenSteps
www.outcomeapp.io - www.screensteps.com
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: PUT method where is returned data?

[Richard Gaskin via use-livecode]

Devin Asay wrote:

> On Feb 8, 2017, at 2:02 PM, Richard Gaskin wrote:
>
>> "it" is not longer a valid container for URL responses?
>>
>> I missed that memo.  Which version did that change take place in?
>>
>> My understanding is that GET requests are simply submitted in a
>> LiveCode ‘put URL tURL into ” statement, and the results
>> go into the container you designate. POST requests are returned to
>> ‘it’.
>
> As far as I know it’s always been like this.
>
> The PUT results going to the urlResponse is a new one on me. But I’m
> happy to know it.

If urlResponse is offered as an alternative that may be useful, but if 
"it" is no longer valid at all it'll break a lot of scripts.


Sometimes moving forward with changes, even those that require script 
changes, isn't a bad thing.


But this could use some clarification from the home team.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Script locals in library stack script

[Mike Kerner via use-livecode]

This might explain the bizarre bug I'm experiencing with one of Monte's
externals.  I manage the calls to the various routines for the external
from a library stack.  Periodically, I end up somewhere in the code that I
shouldn't be able to get to because of the values of various variables, and
the only way I could get there would be if the values were somehow wiped.
Hm.  Maybe it's not my code.  Time to go sleuthing...

On Fri, Feb 10, 2017 at 6:56 AM, Bob Hall via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I’ve been wondering this myself. I’m going to try to create a recipe but
> it looks like the TTL of script local variables is different than what I
> thought I knew it to be. I “think” I started see this behavior about
> 8.1.0-ish timeframe but not sure.
>
> In the past few months I started to put everything into properties as I
> found that my understanding of how script local variables behaved was
> different then how they do. I had chalked it up to getting old and just
> forgetting how things work.
>
> So I guess I need to understand what is the TTL definition of a script
> local variable? I was under the impression that if I have setters/getters
> for the variables and set their value, as long as that Script remains in
> memory, the script local variable retains it’s value. I do not see that for
> sure if I set the script local var in the libraryStack message in 8.1.2 or
> 8.1.3.
>
> Curious if you’ve figured out anything about this since the original note.
>
> Bob Hall
>
> >
> > Is this something others have seen? LC 8.1.3 rc 1.
> >
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Windows and OSX 64-bit builds?

[Paul Dupuis via use-livecode]

On 2/9/2017 9:19 PM, Monte Goulding via use-livecode wrote:
>> On 10 Feb 2017, at 1:03 pm, Tom Glod via use-livecode 
>>  wrote:
>>
>> trying to export snapshots of lage groups with many image controls. 
>> can't get past 10k
> 10k controls or 10k pixels. Control rect origins are 16 bit ints and sizes 
> are 16 bit unsigned ints so if you are trying to position a control at > 
> 32767 then it won’t work. That won’t change when we compile the engine as 64 
> bit.
>
>
This is one reason I asked what specific limits are being run into. Juts
making "64-bit" versions of LC for OSX or Window will not magically fix
all limits in LiveCode that exists. Many are based on a coded 16 bit or
32 bit bounds. When running into limits, it is better to report the
specific limit - as a bug report at http://quality.livecode.com/ -
rather than looking for 64 bit versions of the engine. It *may* be that
64 bit address spaces is needed to expand the limit, but the again, it
may not.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Script locals in library stack script

[Bob Hall via use-livecode]

I’ve been wondering this myself. I’m going to try to create a recipe but it 
looks like the TTL of script local variables is different than what I thought I 
knew it to be. I “think” I started see this behavior about 8.1.0-ish timeframe 
but not sure. 

In the past few months I started to put everything into properties as I found 
that my understanding of how script local variables behaved was different then 
how they do. I had chalked it up to getting old and just forgetting how things 
work.

So I guess I need to understand what is the TTL definition of a script local 
variable? I was under the impression that if I have setters/getters for the 
variables and set their value, as long as that Script remains in memory, the 
script local variable retains it’s value. I do not see that for sure if I set 
the script local var in the libraryStack message in 8.1.2 or 8.1.3.

Curious if you’ve figured out anything about this since the original note.

Bob Hall

> 
> Is this something others have seen? LC 8.1.3 rc 1.
> 


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode