Re: Because LC can't do two things at once.

[kee nethery]

What is PDF/A?

It’s a TLA I’m unfamiliar with.
Kee


> On Feb 19, 2015, at 6:21 PM, Dr. Hawkins  wrote:
> 
> Actually, put in PDF/A for #3--without it, I will have no choice but to use
> another platform, as it will be mandatory for ECF court filing in a couple
> of years.
> 


___
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: Because LC can't do two things at once.

[Dr. Hawkins]

On Thu, Feb 19, 2015 at 5:48 PM, Dr. Hawkins  wrote:

> On Thu, Feb 19, 2015 at 3:05 PM, Mike Kerner 
> wrote:
>
>> Wow, that's surprising.  So what does your list look like - say for the
>> top
>> 5?  Why is multithreading so important to you?
>>
>
> Secure Postgres support
> Multithreading or slave processes
>
> Fixing the (*#^%*(m show-stopping bugs in the IDE (shadow variables, not
> watching globals, wandering off)
>

Actually, put in PDF/A for #3--without it, I will have no choice but to use
another platform, as it will be mandatory for ECF court filing in a couple
of years.


-- 
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: Because LC can't do two things at once.

[Dr. Hawkins]

On Thu, Feb 19, 2015 at 3:05 PM, Mike Kerner 
wrote:

> Wow, that's surprising.  So what does your list look like - say for the top
> 5?  Why is multithreading so important to you?
>

Secure Postgres support
Multithreading or slave processes

Fixing the (*#^%*(m show-stopping bugs in the IDE (shadow variables, not
watching globals, wandering off)

Locally scoped variables (a la c)

c-type tokens or whatever they're called that globally map strings to
integers.
Integer indexed arrays (would be faster than comparing keys)

The ability to trade the ability to have evaluations for speed (if
something will have a known value, let it compile "all the way" at compile
time

Ability to display eps/ pdf output processing and manipulation





-- 
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: More Unicode STuff

[Kay C Lan]

On Sat, Feb 14, 2015 at 2:23 AM, Peter Haworth  wrote:

>
> My brain is too fried to figure out why this should be so my plan is to
> just always encode/decode stuff when importing/displaying.
>

Sorry for the slow reply, but I note your other post on your tentative move
to LC 7 and the gotchas along the way, so this additional information will
probably be timely and hopefully explanatory.

This additional Important Note in the LC 7 dictionary under
'uniEncode/uniDecode' will be of interest:
>>
As of LiveCode 7.0 the uniEncode function has been deprecated. It will
continue to work as in previous versions but shoud not be used in new code
as the existing behaviour is incompatible with the new, transparent Unicode
handling (the resulting value will be treated as binary data rather than
text). This functions is only useful in combination with the
also-deprecated uniDecode function and unicodeText field property.
>>

Also, as to why you need to do the two way encoding/decoding, it's better
explained in the LC 7 dictionary under the 'textEncoding/textDecoding'
entries:
>>
It is highly recommended that any time you interface with things outside
LiveCode (files, network sockets, processes, etc) that you explicitly
textEncode any text you send outside LiveCode and textDecode all text
received into LiveCode. If this doesn't happen, a platform-dependent
encoding will be used (which normally does not support Unicode text).

It is not, in general, possible to reliably auto-detect text encodings so
please check the documentation for the programme you are communicating with
to find out what it expects. If in doubt, try UTF-8.
>>
___
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: 7.0 Issues

[Richard Gaskin]

J. Landman Gay wrote:

 From what you've seen, it sounds like the default in 7.0 is to encode
the new way, and the dictionary is misleading. Richard G. mentioned on
the list that the default was the new encoding.


To clarify, the new method is used where it exists. :)

It works very much like stack file formats, where the default is the 
current format unless you specify otherwise.


And as with file formats, you can save in older formats from the newer 
version.


Also like file formats, apparently v6.7.x is at least somewhat aware of 
later array formats, even if it can't generate them.  It allows you to 
use the optional second argument with "arrayEncode" - it won't actually 
do anything since v6.7 doesn't understand later encoding formats, but it 
won't choke on a second param either.


This is rarely needed, for the few code bases that must run on both 6.7 
and 7.0 during the same development cycle.  It's much more common for 
development workflows to move forward, so this will be needed by very few.


I happened to be one of them, since I have a projects that has v6 
clients in the wild and uses v7 on the server, and I test my server code 
in a local ad hoc server emulator under v6.7.  Can't imagine many need 
to run the same code in both environments, but if you do it seems to 
work well provided you're using a reasonably recent v6.7 build.


--
 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: Vector Export?

[J. Landman Gay]

Right, I was talking about bitmaps. All screen exports are some kind of bitmap. 
If I need a higher resolution I open the file in Graphic Converter or Photoshop 
and increase the resolution. 

The PDF idea is interesting, I hadn't thought of that. 

On February 19, 2015 4:55:35 PM CST, Graham Samuel  wrote:
>Sorry Jacque, I don’t understand. Suppose I have say a filled rectangle
>(‘draw' not ‘paint', thus a vector image). When I export it, I think
>this ends up as a bitmap with the resolution of the screen it was
>displayed in while in LC. Is this what you’re seeing? What about a
>group containing say vector items and also text? In theory this could
>be exported as an image with no inherent resolution, so capable of
>being reproduced at different resolutions as required. I don’t seem to
>get anything other than bitmaps.
>
>Graham
>
>> On 19 Feb 2015, at 22:22, J. Landman Gay 
>wrote:
>> 
>> On 2/19/2015 10:50 AM, Graham Samuel wrote:
>>> Is there any way to export a vector image? What I’m actually trying
>>> to do is to export a screenshot that can have a higher resolution
>>> than that of the screen, for printing and so on. Other apps can do
>>> this, in effect (I mean they can have enlargement and/or
>>> resolution-changing features).
>>> 
>>> What do people do when they want a high-res output?
>> 
>> I usually just run images through an image processing app after
>export if I need to alter them. I'm not aware of any way to change the
>resolution from within LC.
>> 
>> -- 
>> 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
>
>
>___
>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: 7.0 Issues

[Peter Haworth]

Sorry, final word on this subject.

I loaded the stack, set the stackfileversion to 7.0 and saved the stack.
Quit LC 7 and run again.  Try to open the stack - spinning beachball of
death, have to force quit.

Done have any more time to waste on this so back to good old reliable 6.6.

On Thu Feb 19 2015 at 3:59:18 PM Peter Haworth  wrote:

> OK, well this is getting really frustrating.
>
> I changed my code to check the version and issue the 7 version of
> arrayencode with the extra parm with a "do" command.
>
> I made a copy of the stack for use in LC7 and opened it in LC7.  Now I get
> an error on the arrayencode because the stackfile version is 5.5 so it
> won't execute the command even though it's a perfectly valid in 7.0.
>
> I'd really like to use 7.0 for this project but I have to keep the pre 7
> code base available for bug fixes. All this because the 7.0 version of
> arrayencode was implemented without a thought for backward compatibility.
> All that was needed was a preference setting for the default encoding to be
> used for arrayencode in 7.0.
>
> I've wasted the best part of the day trying to make this work and the
> arrays in question don't even contain any unicode characters!  What really
> scares me is how many other gotchas I'll find if I go any further with this
> project.  I will have the think carefully if it's worth the effort and
> hassle to try converting existing stacks over to 7 or just use it for brand
> new projects.
>
> On Thu Feb 19 2015 at 2:50:09 PM Peter Haworth  wrote:
>
>> Thanks Eric.  I guess I'll have to go the "do" route.  Your bug report is
>> 13406, I just added a comment to it.
>>
>> On Thu Feb 19 2015 at 2:22:53 PM Eric Corbett 
>> wrote:
>>
>>> Hi Peter,
>>>
>>> I forgot about that fact. I just checked some code in a library we use
>>> and indeed the arrayEncode for version 7 is wrapped in a do statement.
>>>
>>> I agree about the behavior. Mark W. made some comments to a bug report I
>>> submitted explaining the current functionality but I can not find it.
>>>
>>> eric
>>>
>>>
>>> On Feb 19, 2015, at 2:15 PM, Peter Haworth  wrote:
>>>
>>> > Ho Eric,
>>> > Spoke too soon.  Your code wont compile in versions prior to 7 because
>>> of
>>> > the extra parameter.  I guess I could compile it in 7 but that would
>>> mean I
>>> > would have to compile that script in 7 every time I wanted to make a
>>> change
>>> > and there's a lot of handlers in it so high probability of changes.  I
>>> > suppose I could use a do statement (yuk).
>>> >
>>> > The more I think about this, the more it's a pretty bad backward
>>> > compatibility problem.  I'm wondering if the dictionary entry is in
>>> fact
>>> > the way it was supposed to be implemented, meaning if the new parm
>>> isn't
>>> > present the old encoding is used.
>>> >
>>> > You only care about the new encoding if you're storing unicode data in
>>> an
>>> > array and doesn't seem like any more of an imposition to use the new
>>> > parameter than having to use textEncode/Decode for other unicode
>>> operations.
>>> >
>>> > On Thu Feb 19 2015 at 1:03:05 PM Eric Corbett >> >
>>> > wrote:
>>> >
>>> >> I think what you will have to do is this:
>>> >>
>>> >> Check the LC version;
>>> >> if it’s >= 7 then
>>> >> arrayEncode(tData,6) — force the engine to use the old arrayEncoding
>>> >> else
>>> >> arrayEncode(tData) — older versions can not have the extra parameter
>>> >> end if
>>> >>
>>> >> LiveCode 7 will be smart enough to decode the array either way.
>>> >>
>>> >> Eric
>>> >>
>>> >> On Feb 19, 2015, at 12:49 PM, Peter Haworth  wrote:
>>> >>
>>> >>> Thanks Eric, yes that does indeed help.  However, I'm still confused.
>>> >> The
>>> >>> dictionary indicates that if the new parameter, version, is not
>>> present
>>> >>> then arrays are encoded the old way.  None of my calls include the
>>> new
>>> >>> parameter so not sure how they ended up being inaccessible in pre7
>>> >> versions.
>>> >>>
>>> >>> I guess the gist of my post was what else have I failed to account
>>> for?
>>> >> Is
>>> >>> there a document somewhere that details what code structures may need
>>> >>> attention when moving back and forth between LC7 and prior
>>> versions?  I'm
>>> >>> guessing that anything addressing char chunks or offset would need
>>> to be
>>> >>> changed.
>>> >>>
>>> >>> On Thu Feb 19 2015 at 12:31:24 PM Eric Corbett <
>>> e...@canelasoftware.com>
>>> >>> wrote:
>>> >>>
>>>  Not sure if this helps, but LiveCode 7 uses a different
>>> arrayEncoding
>>> >> than
>>>  previous version due to Unicode. Check the dictionary on how to use
>>>  arrayEncode in 7 to be able to decode in an earlier version.
>>> 
>>>  Eric
>>> 
>>> 
>>> 
>>> 
>>>  On Feb 19, 2015, at 12:16 PM, Peter Haworth  wrote:
>>> 
>>> > I've been careful to create separate versions of my stack files and
>>> > Livecode Preferences folder for use when running LC 7.  However, it
>>> >> seems
>>> > there other issues with compati

Re: 7.0 Issues

[Peter Haworth]

OK, well this is getting really frustrating.

I changed my code to check the version and issue the 7 version of
arrayencode with the extra parm with a "do" command.

I made a copy of the stack for use in LC7 and opened it in LC7.  Now I get
an error on the arrayencode because the stackfile version is 5.5 so it
won't execute the command even though it's a perfectly valid in 7.0.

I'd really like to use 7.0 for this project but I have to keep the pre 7
code base available for bug fixes. All this because the 7.0 version of
arrayencode was implemented without a thought for backward compatibility.
All that was needed was a preference setting for the default encoding to be
used for arrayencode in 7.0.

I've wasted the best part of the day trying to make this work and the
arrays in question don't even contain any unicode characters!  What really
scares me is how many other gotchas I'll find if I go any further with this
project.  I will have the think carefully if it's worth the effort and
hassle to try converting existing stacks over to 7 or just use it for brand
new projects.

On Thu Feb 19 2015 at 2:50:09 PM Peter Haworth  wrote:

> Thanks Eric.  I guess I'll have to go the "do" route.  Your bug report is
> 13406, I just added a comment to it.
>
> On Thu Feb 19 2015 at 2:22:53 PM Eric Corbett 
> wrote:
>
>> Hi Peter,
>>
>> I forgot about that fact. I just checked some code in a library we use
>> and indeed the arrayEncode for version 7 is wrapped in a do statement.
>>
>> I agree about the behavior. Mark W. made some comments to a bug report I
>> submitted explaining the current functionality but I can not find it.
>>
>> eric
>>
>>
>> On Feb 19, 2015, at 2:15 PM, Peter Haworth  wrote:
>>
>> > Ho Eric,
>> > Spoke too soon.  Your code wont compile in versions prior to 7 because
>> of
>> > the extra parameter.  I guess I could compile it in 7 but that would
>> mean I
>> > would have to compile that script in 7 every time I wanted to make a
>> change
>> > and there's a lot of handlers in it so high probability of changes.  I
>> > suppose I could use a do statement (yuk).
>> >
>> > The more I think about this, the more it's a pretty bad backward
>> > compatibility problem.  I'm wondering if the dictionary entry is in fact
>> > the way it was supposed to be implemented, meaning if the new parm isn't
>> > present the old encoding is used.
>> >
>> > You only care about the new encoding if you're storing unicode data in
>> an
>> > array and doesn't seem like any more of an imposition to use the new
>> > parameter than having to use textEncode/Decode for other unicode
>> operations.
>> >
>> > On Thu Feb 19 2015 at 1:03:05 PM Eric Corbett 
>> > wrote:
>> >
>> >> I think what you will have to do is this:
>> >>
>> >> Check the LC version;
>> >> if it’s >= 7 then
>> >> arrayEncode(tData,6) — force the engine to use the old arrayEncoding
>> >> else
>> >> arrayEncode(tData) — older versions can not have the extra parameter
>> >> end if
>> >>
>> >> LiveCode 7 will be smart enough to decode the array either way.
>> >>
>> >> Eric
>> >>
>> >> On Feb 19, 2015, at 12:49 PM, Peter Haworth  wrote:
>> >>
>> >>> Thanks Eric, yes that does indeed help.  However, I'm still confused.
>> >> The
>> >>> dictionary indicates that if the new parameter, version, is not
>> present
>> >>> then arrays are encoded the old way.  None of my calls include the new
>> >>> parameter so not sure how they ended up being inaccessible in pre7
>> >> versions.
>> >>>
>> >>> I guess the gist of my post was what else have I failed to account
>> for?
>> >> Is
>> >>> there a document somewhere that details what code structures may need
>> >>> attention when moving back and forth between LC7 and prior versions?
>> I'm
>> >>> guessing that anything addressing char chunks or offset would need to
>> be
>> >>> changed.
>> >>>
>> >>> On Thu Feb 19 2015 at 12:31:24 PM Eric Corbett <
>> e...@canelasoftware.com>
>> >>> wrote:
>> >>>
>>  Not sure if this helps, but LiveCode 7 uses a different arrayEncoding
>> >> than
>>  previous version due to Unicode. Check the dictionary on how to use
>>  arrayEncode in 7 to be able to decode in an earlier version.
>> 
>>  Eric
>> 
>> 
>> 
>> 
>>  On Feb 19, 2015, at 12:16 PM, Peter Haworth  wrote:
>> 
>> > I've been careful to create separate versions of my stack files and
>> > Livecode Preferences folder for use when running LC 7.  However, it
>> >> seems
>> > there other issues with compatibility.
>> >
>> > I save the preferences for my application in a file in the
>> > /Library/Application Support folder with the following statement:
>> >
>> > *write* base64Encode(arrayEncode(gSettings)) to file "
>> >
>> > These are then read in at startup with:
>> >
>> > read from file myPath until EOF
>> > if it is empty then
>> >put empty into gSettings
>> > else
>> >put arrayDecode(base64Decode(it)) into gSettings
>> > end if
>>

Re: Vector export?

[Terry Judd]

David¹s right - PDF export is definitely the way to go. It¹s even good for
bitmaps if you use high res images that have been sized down and locked
within LC.

Terry...

On 20/02/2015 9:56 am, "Graham Samuel"  wrote:

>Ha! Sounds promising. Midnight here, I¹ll investigate tomorrow. Thanks
>
>Graham
>
>> On 19 Feb 2015, at 23:33, dfepst...@comcast.net wrote:
>> 
>> For high resolution export of vectors:  open printing to pdf
>>   
>> David Epstein 
>
>
>___
>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: Because LC can't do two things at once.

[Mike Kerner]

Wow, that's surprising.  So what does your list look like - say for the top
5?  Why is multithreading so important to you?

On Thu, Feb 19, 2015 at 5:25 PM, Dr. Hawkins  wrote:

> On Thu, Feb 19, 2015 at 10:32 AM, Mike Kerner 
> wrote:
>
> > If you were prioritizing features for LC, would this be one of your top
> 5?
> > It might make my top 10, but I don't know if it would be in my top 5.
> >
>
> I can't see it any lower than my top 2 (the other of which would be
> postgres ssl support).
>
>
> --
> 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
>



-- 
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: Vector export?

[Graham Samuel]

Ha! Sounds promising. Midnight here, I’ll investigate tomorrow. Thanks

Graham

> On 19 Feb 2015, at 23:33, dfepst...@comcast.net wrote:
> 
> For high resolution export of vectors:  open printing to pdf 
>   
> David Epstein 


___
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: Vector Export?

[Graham Samuel]

Sorry Jacque, I don’t understand. Suppose I have say a filled rectangle (‘draw' 
not ‘paint', thus a vector image). When I export it, I think this ends up as a 
bitmap with the resolution of the screen it was displayed in while in LC. Is 
this what you’re seeing? What about a group containing say vector items and 
also text? In theory this could be exported as an image with no inherent 
resolution, so capable of being reproduced at different resolutions as 
required. I don’t seem to get anything other than bitmaps.

Graham

> On 19 Feb 2015, at 22:22, J. Landman Gay  wrote:
> 
> On 2/19/2015 10:50 AM, Graham Samuel wrote:
>> Is there any way to export a vector image? What I’m actually trying
>> to do is to export a screenshot that can have a higher resolution
>> than that of the screen, for printing and so on. Other apps can do
>> this, in effect (I mean they can have enlargement and/or
>> resolution-changing features).
>> 
>> What do people do when they want a high-res output?
> 
> I usually just run images through an image processing app after export if I 
> need to alter them. I'm not aware of any way to change the resolution from 
> within LC.
> 
> -- 
> 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


___
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: 7.0 Issues

[Peter Haworth]

Thanks Eric.  I guess I'll have to go the "do" route.  Your bug report is
13406, I just added a comment to it.

On Thu Feb 19 2015 at 2:22:53 PM Eric Corbett 
wrote:

> Hi Peter,
>
> I forgot about that fact. I just checked some code in a library we use and
> indeed the arrayEncode for version 7 is wrapped in a do statement.
>
> I agree about the behavior. Mark W. made some comments to a bug report I
> submitted explaining the current functionality but I can not find it.
>
> eric
>
>
> On Feb 19, 2015, at 2:15 PM, Peter Haworth  wrote:
>
> > Ho Eric,
> > Spoke too soon.  Your code wont compile in versions prior to 7 because of
> > the extra parameter.  I guess I could compile it in 7 but that would
> mean I
> > would have to compile that script in 7 every time I wanted to make a
> change
> > and there's a lot of handlers in it so high probability of changes.  I
> > suppose I could use a do statement (yuk).
> >
> > The more I think about this, the more it's a pretty bad backward
> > compatibility problem.  I'm wondering if the dictionary entry is in fact
> > the way it was supposed to be implemented, meaning if the new parm isn't
> > present the old encoding is used.
> >
> > You only care about the new encoding if you're storing unicode data in an
> > array and doesn't seem like any more of an imposition to use the new
> > parameter than having to use textEncode/Decode for other unicode
> operations.
> >
> > On Thu Feb 19 2015 at 1:03:05 PM Eric Corbett 
> > wrote:
> >
> >> I think what you will have to do is this:
> >>
> >> Check the LC version;
> >> if it’s >= 7 then
> >> arrayEncode(tData,6) — force the engine to use the old arrayEncoding
> >> else
> >> arrayEncode(tData) — older versions can not have the extra parameter
> >> end if
> >>
> >> LiveCode 7 will be smart enough to decode the array either way.
> >>
> >> Eric
> >>
> >> On Feb 19, 2015, at 12:49 PM, Peter Haworth  wrote:
> >>
> >>> Thanks Eric, yes that does indeed help.  However, I'm still confused.
> >> The
> >>> dictionary indicates that if the new parameter, version, is not present
> >>> then arrays are encoded the old way.  None of my calls include the new
> >>> parameter so not sure how they ended up being inaccessible in pre7
> >> versions.
> >>>
> >>> I guess the gist of my post was what else have I failed to account for?
> >> Is
> >>> there a document somewhere that details what code structures may need
> >>> attention when moving back and forth between LC7 and prior versions?
> I'm
> >>> guessing that anything addressing char chunks or offset would need to
> be
> >>> changed.
> >>>
> >>> On Thu Feb 19 2015 at 12:31:24 PM Eric Corbett <
> e...@canelasoftware.com>
> >>> wrote:
> >>>
>  Not sure if this helps, but LiveCode 7 uses a different arrayEncoding
> >> than
>  previous version due to Unicode. Check the dictionary on how to use
>  arrayEncode in 7 to be able to decode in an earlier version.
> 
>  Eric
> 
> 
> 
> 
>  On Feb 19, 2015, at 12:16 PM, Peter Haworth  wrote:
> 
> > I've been careful to create separate versions of my stack files and
> > Livecode Preferences folder for use when running LC 7.  However, it
> >> seems
> > there other issues with compatibility.
> >
> > I save the preferences for my application in a file in the
> > /Library/Application Support folder with the following statement:
> >
> > *write* base64Encode(arrayEncode(gSettings)) to file "
> >
> > These are then read in at startup with:
> >
> > read from file myPath until EOF
> > if it is empty then
> >put empty into gSettings
> > else
> >put arrayDecode(base64Decode(it)) into gSettings
> > end if
> >
> > Yesterday, I started working on this stack with LC7 and the prefs
> file
>  was
> > saved by the LC7 version of the stack.
> > Today, I needed to go back to the non LC7 version of the stack.  To
> my
> > surprise, a runtime error was thrown on the "put arrayDecode..."
>  statement
> > above.  The  it variable looked  like it contained base64 encoded
> data.
> >
> > I ran the LC7 version of the stack again and the runtime error did
> not
> > occur.
> >
> > I restored the preferences file from a Time Machine backup that I
> know
> > preceded my use of LC7, ran the application again with LC 6.6.2, and
> >> all
> > worked fine.
> >
> > So it seems that something in either the array/base64 encode/decode
> > functions changed between v6.6.2 and 7.0.1.
> >
> > I really want to use LC7 but stuff like this makes me very nervous.
> >> How
> > many other inconsistencies like this are lurking out there.
> > ___
> > 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

Re: Vector export?

[dfepstein]

For high resolution export of vectors:  open printing to pdf 
  
David Epstein 
___
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: Because LC can't do two things at once.

[Dr. Hawkins]

On Thu, Feb 19, 2015 at 10:32 AM, Mike Kerner 
wrote:

> If you were prioritizing features for LC, would this be one of your top 5?
> It might make my top 10, but I don't know if it would be in my top 5.
>

I can't see it any lower than my top 2 (the other of which would be
postgres ssl support).


-- 
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: 7.0 Issues

[Eric Corbett]

Hi Peter,

I forgot about that fact. I just checked some code in a library we use and 
indeed the arrayEncode for version 7 is wrapped in a do statement.

I agree about the behavior. Mark W. made some comments to a bug report I 
submitted explaining the current functionality but I can not find it.

eric


On Feb 19, 2015, at 2:15 PM, Peter Haworth  wrote:

> Ho Eric,
> Spoke too soon.  Your code wont compile in versions prior to 7 because of
> the extra parameter.  I guess I could compile it in 7 but that would mean I
> would have to compile that script in 7 every time I wanted to make a change
> and there's a lot of handlers in it so high probability of changes.  I
> suppose I could use a do statement (yuk).
> 
> The more I think about this, the more it's a pretty bad backward
> compatibility problem.  I'm wondering if the dictionary entry is in fact
> the way it was supposed to be implemented, meaning if the new parm isn't
> present the old encoding is used.
> 
> You only care about the new encoding if you're storing unicode data in an
> array and doesn't seem like any more of an imposition to use the new
> parameter than having to use textEncode/Decode for other unicode operations.
> 
> On Thu Feb 19 2015 at 1:03:05 PM Eric Corbett 
> wrote:
> 
>> I think what you will have to do is this:
>> 
>> Check the LC version;
>> if it’s >= 7 then
>> arrayEncode(tData,6) — force the engine to use the old arrayEncoding
>> else
>> arrayEncode(tData) — older versions can not have the extra parameter
>> end if
>> 
>> LiveCode 7 will be smart enough to decode the array either way.
>> 
>> Eric
>> 
>> On Feb 19, 2015, at 12:49 PM, Peter Haworth  wrote:
>> 
>>> Thanks Eric, yes that does indeed help.  However, I'm still confused.
>> The
>>> dictionary indicates that if the new parameter, version, is not present
>>> then arrays are encoded the old way.  None of my calls include the new
>>> parameter so not sure how they ended up being inaccessible in pre7
>> versions.
>>> 
>>> I guess the gist of my post was what else have I failed to account for?
>> Is
>>> there a document somewhere that details what code structures may need
>>> attention when moving back and forth between LC7 and prior versions?  I'm
>>> guessing that anything addressing char chunks or offset would need to be
>>> changed.
>>> 
>>> On Thu Feb 19 2015 at 12:31:24 PM Eric Corbett 
>>> wrote:
>>> 
 Not sure if this helps, but LiveCode 7 uses a different arrayEncoding
>> than
 previous version due to Unicode. Check the dictionary on how to use
 arrayEncode in 7 to be able to decode in an earlier version.
 
 Eric
 
 
 
 
 On Feb 19, 2015, at 12:16 PM, Peter Haworth  wrote:
 
> I've been careful to create separate versions of my stack files and
> Livecode Preferences folder for use when running LC 7.  However, it
>> seems
> there other issues with compatibility.
> 
> I save the preferences for my application in a file in the
> /Library/Application Support folder with the following statement:
> 
> *write* base64Encode(arrayEncode(gSettings)) to file "
> 
> These are then read in at startup with:
> 
> read from file myPath until EOF
> if it is empty then
>put empty into gSettings
> else
>put arrayDecode(base64Decode(it)) into gSettings
> end if
> 
> Yesterday, I started working on this stack with LC7 and the prefs file
 was
> saved by the LC7 version of the stack.
> Today, I needed to go back to the non LC7 version of the stack.  To my
> surprise, a runtime error was thrown on the "put arrayDecode..."
 statement
> above.  The  it variable looked  like it contained base64 encoded data.
> 
> I ran the LC7 version of the stack again and the runtime error did not
> occur.
> 
> I restored the preferences file from a Time Machine backup that I know
> preceded my use of LC7, ran the application again with LC 6.6.2, and
>> all
> worked fine.
> 
> So it seems that something in either the array/base64 encode/decode
> functions changed between v6.6.2 and 7.0.1.
> 
> I really want to use LC7 but stuff like this makes me very nervous.
>> How
> many other inconsistencies like this are lurking out there.
> ___
> 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.r

Re: 7.0 Issues

[Peter Haworth]

Ho Eric,
Spoke too soon.  Your code wont compile in versions prior to 7 because of
the extra parameter.  I guess I could compile it in 7 but that would mean I
would have to compile that script in 7 every time I wanted to make a change
and there's a lot of handlers in it so high probability of changes.  I
suppose I could use a do statement (yuk).

The more I think about this, the more it's a pretty bad backward
compatibility problem.  I'm wondering if the dictionary entry is in fact
the way it was supposed to be implemented, meaning if the new parm isn't
present the old encoding is used.

You only care about the new encoding if you're storing unicode data in an
array and doesn't seem like any more of an imposition to use the new
parameter than having to use textEncode/Decode for other unicode operations.

On Thu Feb 19 2015 at 1:03:05 PM Eric Corbett 
wrote:

> I think what you will have to do is this:
>
> Check the LC version;
> if it’s >= 7 then
> arrayEncode(tData,6) — force the engine to use the old arrayEncoding
> else
> arrayEncode(tData) — older versions can not have the extra parameter
> end if
>
> LiveCode 7 will be smart enough to decode the array either way.
>
> Eric
>
> On Feb 19, 2015, at 12:49 PM, Peter Haworth  wrote:
>
> > Thanks Eric, yes that does indeed help.  However, I'm still confused.
> The
> > dictionary indicates that if the new parameter, version, is not present
> > then arrays are encoded the old way.  None of my calls include the new
> > parameter so not sure how they ended up being inaccessible in pre7
> versions.
> >
> > I guess the gist of my post was what else have I failed to account for?
> Is
> > there a document somewhere that details what code structures may need
> > attention when moving back and forth between LC7 and prior versions?  I'm
> > guessing that anything addressing char chunks or offset would need to be
> > changed.
> >
> > On Thu Feb 19 2015 at 12:31:24 PM Eric Corbett 
> > wrote:
> >
> >> Not sure if this helps, but LiveCode 7 uses a different arrayEncoding
> than
> >> previous version due to Unicode. Check the dictionary on how to use
> >> arrayEncode in 7 to be able to decode in an earlier version.
> >>
> >> Eric
> >>
> >>
> >>
> >>
> >> On Feb 19, 2015, at 12:16 PM, Peter Haworth  wrote:
> >>
> >>> I've been careful to create separate versions of my stack files and
> >>> Livecode Preferences folder for use when running LC 7.  However, it
> seems
> >>> there other issues with compatibility.
> >>>
> >>> I save the preferences for my application in a file in the
> >>> /Library/Application Support folder with the following statement:
> >>>
> >>> *write* base64Encode(arrayEncode(gSettings)) to file "
> >>>
> >>> These are then read in at startup with:
> >>>
> >>> read from file myPath until EOF
> >>>  if it is empty then
> >>> put empty into gSettings
> >>>  else
> >>> put arrayDecode(base64Decode(it)) into gSettings
> >>>  end if
> >>>
> >>> Yesterday, I started working on this stack with LC7 and the prefs file
> >> was
> >>> saved by the LC7 version of the stack.
> >>> Today, I needed to go back to the non LC7 version of the stack.  To my
> >>> surprise, a runtime error was thrown on the "put arrayDecode..."
> >> statement
> >>> above.  The  it variable looked  like it contained base64 encoded data.
> >>>
> >>> I ran the LC7 version of the stack again and the runtime error did not
> >>> occur.
> >>>
> >>> I restored the preferences file from a Time Machine backup that I know
> >>> preceded my use of LC7, ran the application again with LC 6.6.2, and
> all
> >>> worked fine.
> >>>
> >>> So it seems that something in either the array/base64 encode/decode
> >>> functions changed between v6.6.2 and 7.0.1.
> >>>
> >>> I really want to use LC7 but stuff like this makes me very nervous.
> How
> >>> many other inconsistencies like this are lurking out there.
> >>> ___
> >>> 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
>
>
> ___
> 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: 7.0 Issues

[Peter Haworth]

Thanks Eric and Jacque.  I entered QCC report 14639.  I altered my code to
do as you suggest Eric.

I wonder how this affects how an array variable is stored in a custom
property?  As I understand it, the variable is automatically array encoded
if you do something like "set the cArray of me to tArray" and decoded when
you get it back out of the cProp.  Personally I only use cProps for stuff
that doesn't need to survive across runs of LC so wouldn't be affected by
any changes in that area but others may not be so lucky.

On Thu Feb 19 2015 at 1:18:58 PM J. Landman Gay 
wrote:

> On 2/19/2015 2:49 PM, Peter Haworth wrote:
> > The
> > dictionary indicates that if the new parameter, version, is not present
> > then arrays are encoded the old way.  None of my calls include the new
> > parameter so not sure how they ended up being inaccessible in pre7
> versions.
>
>  From what you've seen, it sounds like the default in 7.0 is to encode
> the new way, and the dictionary is misleading. Richard G. mentioned on
> the list that the default was the new encoding. We should clear that up,
> it's going to affect me too eventually.
>
> --
> 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
>
___
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: Because LC can't do two things at once.

[Mike Bonner]

One of the "work arounds" isn't really, its kind of a standard thing. A
game loop.  Loop, do these things, do those things, update the screen, loop
again.  For your "trek to earth" game, this would probably be sufficient.
Rather than waiting for an arrow key event, one of the loop steps would be
to check the keysdown and act appropriately.  Having said that, being able
to turn some of this over to separate threads on separate cores would be
awesome.  As it is, you can only reach a certain amount of complexity
before running into trouble.  Too many objects to move, intersects to
check, etc for each loop makes it impossible to get a reliable frame rate.
This is where more "work arounds" would come in.

My hope is that box2d will offset most of its stuff to a separate core (or
more if they're available) but time will tell. Also, if I recall correctly,
the IDE will be broken out to a thread some way so that even if you repeat
forever end repeat, shouldn't bring the IDE to its knees. (benefits for
standalones too must likely? ) Alas, as usual, I read way way too much but
can't recall where I saw this, and if it was a suggestion, or an actual
goal.

On Thu, Feb 19, 2015 at 12:00 PM, Richard Gaskin  wrote:

> Richmond wrote:
>
> > I wonder WHY Livecode cannot do two things at once . . .
>
> There is a difference between concurrency and parallelism which is useful
> here because LC currently provides a limited form of concurrency for some
> operations but delivers true parallelism only in the most recent version of
> 7 and only with regard to GPUs (and not AFAIK something we can use in our
> scripts, but something done in the engine to optimize rendering).
>
> Long but excellent distinction between the two:
>
> Rob Pike - 'Concurrency Is Not Parallelism'
> 
>
> TL/DR version:  Concurrency is a logical framework for handling tasks
> independently, while parallelism is the actual simultaneous execution of
> code across multiple processors.
>
> This distinction is also useful here when comparing LC to other languages,
> since Python is one of the world's most popular languages and offers
> concurrency but not parallelism (at least not in the main distribution,
> though I believe there are now forks that provide parallelism).
>
> Within LC, network I/O is concurrent (but not parallel) when you use
> callbacks, e.g.:
>
>accept connections on port  with "SomeCallbackMessage"
>
> In those cases the network I/O is non-blocking, and whatever handler is
> accepting connections can be triggered again even before
> SomeCallbackMessage has completed.
>
> This is very limited, however, since most non-network-I/O tasks are
> blocking, so chances are that SomeCallbackMessage will prevent anything
> meaningful from taking place in any re-entrant network I/O handlers.
>
> Other forms of non-parallel concurrency can be had in LC as it is today
> using timers or "wait 0 with messages" - here's a simple stack to
> illustrate some of those options:
>
> 
>
> While a very simple demo, the ideas shown there can be expanded to make
> good use of idle processing time to handle background tasks independently
> of other operations.*
>
> And then there are other ways we can use LC as it is today to achieve not
> only concurrency but even parallelism, using multiprocessing as an
> alternative to multithreading: faceless standalones launched with "open
> process for neither", which can work completely independently of the UI the
> user is interacting with, and exchange data with that UI app either through
> local sockets or even just the file system (tmp is good for this).
>
>
> But all that's just tiny baby steps compared to what could be possible, so
> I like this question:
>
> > AND, could it be revamped so that it could do two things at once?
>
> Given:
> - Python's success with non-parallel concurrency
> - the overhead of threads
> - the complexity of managing threads to avoid race conditions
>   which (libURL aside) we've largely never had to even think about
>
> ...I would suggest we think carefully about what exactly we want.
>
> Forking is absolutely essential for the Server engine to be able to
> support FastCGI implementations for more scalable systems.
>
> But forking is a very specific form of concurrency.
>
> Threading is another, one which requires syntax for managing queues and
> priorities.
>
> Probably not as difficult to implement as it is to design the syntax for.
>
>
> > Let the debate RAGE :)
>
> All for it.  We already know we need some form of parallelism for
> large-scale server work, so it's probably useful to begin thinking about an
> approach for these sorts of things that could benefit the desktop as well.
>
>
>
> * If we want to max out the CPU by taking full advantage of idle time for
> background processing, it would be ideal to do this only when powered by
> wall socket, so laptops running from battery wouldn

Re: 7.0 Issues

[J. Landman Gay]

On 2/19/2015 2:49 PM, Peter Haworth wrote:

The
dictionary indicates that if the new parameter, version, is not present
then arrays are encoded the old way.  None of my calls include the new
parameter so not sure how they ended up being inaccessible in pre7 versions.


From what you've seen, it sounds like the default in 7.0 is to encode 
the new way, and the dictionary is misleading. Richard G. mentioned on 
the list that the default was the new encoding. We should clear that up, 
it's going to affect me too eventually.


--
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: Vector Export?

[J. Landman Gay]

On 2/19/2015 10:50 AM, Graham Samuel wrote:

Is there any way to export a vector image? What I’m actually trying
to do is to export a screenshot that can have a higher resolution
than that of the screen, for printing and so on. Other apps can do
this, in effect (I mean they can have enlargement and/or
resolution-changing features).

What do people do when they want a high-res output?


I usually just run images through an image processing app after export 
if I need to alter them. I'm not aware of any way to change the 
resolution from within LC.


--
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: 7.0 Issues

[Eric Corbett]

Additionally,

The dictionary may be a bit inaccurate. In LC 7, if there is no version, 
arrayEncode uses the encoding for the version you are on, LC 7 encoding. So, if 
LC 8 has different encoding than 7, LC 8 will use LC 8 encoding when no version 
is specified.

Eric

On Feb 19, 2015, at 12:49 PM, Peter Haworth  wrote:

> Thanks Eric, yes that does indeed help.  However, I'm still confused.  The
> dictionary indicates that if the new parameter, version, is not present
> then arrays are encoded the old way.  None of my calls include the new
> parameter so not sure how they ended up being inaccessible in pre7 versions.
> 
> I guess the gist of my post was what else have I failed to account for?  Is
> there a document somewhere that details what code structures may need
> attention when moving back and forth between LC7 and prior versions?  I'm
> guessing that anything addressing char chunks or offset would need to be
> changed.
> 
> On Thu Feb 19 2015 at 12:31:24 PM Eric Corbett 
> wrote:
> 
>> Not sure if this helps, but LiveCode 7 uses a different arrayEncoding than
>> previous version due to Unicode. Check the dictionary on how to use
>> arrayEncode in 7 to be able to decode in an earlier version.
>> 
>> Eric
>> 
>> 
>> 
>> 
>> On Feb 19, 2015, at 12:16 PM, Peter Haworth  wrote:
>> 
>>> I've been careful to create separate versions of my stack files and
>>> Livecode Preferences folder for use when running LC 7.  However, it seems
>>> there other issues with compatibility.
>>> 
>>> I save the preferences for my application in a file in the
>>> /Library/Application Support folder with the following statement:
>>> 
>>> *write* base64Encode(arrayEncode(gSettings)) to file "
>>> 
>>> These are then read in at startup with:
>>> 
>>> read from file myPath until EOF
>>>  if it is empty then
>>> put empty into gSettings
>>>  else
>>> put arrayDecode(base64Decode(it)) into gSettings
>>>  end if
>>> 
>>> Yesterday, I started working on this stack with LC7 and the prefs file
>> was
>>> saved by the LC7 version of the stack.
>>> Today, I needed to go back to the non LC7 version of the stack.  To my
>>> surprise, a runtime error was thrown on the "put arrayDecode..."
>> statement
>>> above.  The  it variable looked  like it contained base64 encoded data.
>>> 
>>> I ran the LC7 version of the stack again and the runtime error did not
>>> occur.
>>> 
>>> I restored the preferences file from a Time Machine backup that I know
>>> preceded my use of LC7, ran the application again with LC 6.6.2, and all
>>> worked fine.
>>> 
>>> So it seems that something in either the array/base64 encode/decode
>>> functions changed between v6.6.2 and 7.0.1.
>>> 
>>> I really want to use LC7 but stuff like this makes me very nervous.  How
>>> many other inconsistencies like this are lurking out there.
>>> ___
>>> 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


___
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: 7.0 Issues

[Eric Corbett]

I think what you will have to do is this:

Check the LC version;
if it’s >= 7 then
arrayEncode(tData,6) — force the engine to use the old arrayEncoding
else
arrayEncode(tData) — older versions can not have the extra parameter
end if

LiveCode 7 will be smart enough to decode the array either way.

Eric

On Feb 19, 2015, at 12:49 PM, Peter Haworth  wrote:

> Thanks Eric, yes that does indeed help.  However, I'm still confused.  The
> dictionary indicates that if the new parameter, version, is not present
> then arrays are encoded the old way.  None of my calls include the new
> parameter so not sure how they ended up being inaccessible in pre7 versions.
> 
> I guess the gist of my post was what else have I failed to account for?  Is
> there a document somewhere that details what code structures may need
> attention when moving back and forth between LC7 and prior versions?  I'm
> guessing that anything addressing char chunks or offset would need to be
> changed.
> 
> On Thu Feb 19 2015 at 12:31:24 PM Eric Corbett 
> wrote:
> 
>> Not sure if this helps, but LiveCode 7 uses a different arrayEncoding than
>> previous version due to Unicode. Check the dictionary on how to use
>> arrayEncode in 7 to be able to decode in an earlier version.
>> 
>> Eric
>> 
>> 
>> 
>> 
>> On Feb 19, 2015, at 12:16 PM, Peter Haworth  wrote:
>> 
>>> I've been careful to create separate versions of my stack files and
>>> Livecode Preferences folder for use when running LC 7.  However, it seems
>>> there other issues with compatibility.
>>> 
>>> I save the preferences for my application in a file in the
>>> /Library/Application Support folder with the following statement:
>>> 
>>> *write* base64Encode(arrayEncode(gSettings)) to file "
>>> 
>>> These are then read in at startup with:
>>> 
>>> read from file myPath until EOF
>>>  if it is empty then
>>> put empty into gSettings
>>>  else
>>> put arrayDecode(base64Decode(it)) into gSettings
>>>  end if
>>> 
>>> Yesterday, I started working on this stack with LC7 and the prefs file
>> was
>>> saved by the LC7 version of the stack.
>>> Today, I needed to go back to the non LC7 version of the stack.  To my
>>> surprise, a runtime error was thrown on the "put arrayDecode..."
>> statement
>>> above.  The  it variable looked  like it contained base64 encoded data.
>>> 
>>> I ran the LC7 version of the stack again and the runtime error did not
>>> occur.
>>> 
>>> I restored the preferences file from a Time Machine backup that I know
>>> preceded my use of LC7, ran the application again with LC 6.6.2, and all
>>> worked fine.
>>> 
>>> So it seems that something in either the array/base64 encode/decode
>>> functions changed between v6.6.2 and 7.0.1.
>>> 
>>> I really want to use LC7 but stuff like this makes me very nervous.  How
>>> many other inconsistencies like this are lurking out there.
>>> ___
>>> 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


___
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: 7.0 Issues

[Peter Haworth]

Thanks Eric, yes that does indeed help.  However, I'm still confused.  The
dictionary indicates that if the new parameter, version, is not present
then arrays are encoded the old way.  None of my calls include the new
parameter so not sure how they ended up being inaccessible in pre7 versions.

I guess the gist of my post was what else have I failed to account for?  Is
there a document somewhere that details what code structures may need
attention when moving back and forth between LC7 and prior versions?  I'm
guessing that anything addressing char chunks or offset would need to be
changed.

On Thu Feb 19 2015 at 12:31:24 PM Eric Corbett 
wrote:

> Not sure if this helps, but LiveCode 7 uses a different arrayEncoding than
> previous version due to Unicode. Check the dictionary on how to use
> arrayEncode in 7 to be able to decode in an earlier version.
>
> Eric
>
>
>
>
> On Feb 19, 2015, at 12:16 PM, Peter Haworth  wrote:
>
> > I've been careful to create separate versions of my stack files and
> > Livecode Preferences folder for use when running LC 7.  However, it seems
> > there other issues with compatibility.
> >
> > I save the preferences for my application in a file in the
> > /Library/Application Support folder with the following statement:
> >
> > *write* base64Encode(arrayEncode(gSettings)) to file "
> >
> > These are then read in at startup with:
> >
> > read from file myPath until EOF
> >   if it is empty then
> >  put empty into gSettings
> >   else
> >  put arrayDecode(base64Decode(it)) into gSettings
> >   end if
> >
> > Yesterday, I started working on this stack with LC7 and the prefs file
> was
> > saved by the LC7 version of the stack.
> > Today, I needed to go back to the non LC7 version of the stack.  To my
> > surprise, a runtime error was thrown on the "put arrayDecode..."
> statement
> > above.  The  it variable looked  like it contained base64 encoded data.
> >
> > I ran the LC7 version of the stack again and the runtime error did not
> > occur.
> >
> > I restored the preferences file from a Time Machine backup that I know
> > preceded my use of LC7, ran the application again with LC 6.6.2, and all
> > worked fine.
> >
> > So it seems that something in either the array/base64 encode/decode
> > functions changed between v6.6.2 and 7.0.1.
> >
> > I really want to use LC7 but stuff like this makes me very nervous.  How
> > many other inconsistencies like this are lurking out there.
> > ___
> > 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: 7.0 Issues

[Eric Corbett]

Not sure if this helps, but LiveCode 7 uses a different arrayEncoding than 
previous version due to Unicode. Check the dictionary on how to use arrayEncode 
in 7 to be able to decode in an earlier version.

Eric




On Feb 19, 2015, at 12:16 PM, Peter Haworth  wrote:

> I've been careful to create separate versions of my stack files and
> Livecode Preferences folder for use when running LC 7.  However, it seems
> there other issues with compatibility.
> 
> I save the preferences for my application in a file in the
> /Library/Application Support folder with the following statement:
> 
> *write* base64Encode(arrayEncode(gSettings)) to file "
> 
> These are then read in at startup with:
> 
> read from file myPath until EOF
>   if it is empty then
>  put empty into gSettings
>   else
>  put arrayDecode(base64Decode(it)) into gSettings
>   end if
> 
> Yesterday, I started working on this stack with LC7 and the prefs file was
> saved by the LC7 version of the stack.
> Today, I needed to go back to the non LC7 version of the stack.  To my
> surprise, a runtime error was thrown on the "put arrayDecode..." statement
> above.  The  it variable looked  like it contained base64 encoded data.
> 
> I ran the LC7 version of the stack again and the runtime error did not
> occur.
> 
> I restored the preferences file from a Time Machine backup that I know
> preceded my use of LC7, ran the application again with LC 6.6.2, and all
> worked fine.
> 
> So it seems that something in either the array/base64 encode/decode
> functions changed between v6.6.2 and 7.0.1.
> 
> I really want to use LC7 but stuff like this makes me very nervous.  How
> many other inconsistencies like this are lurking out there.
> ___
> 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: Problems in On-Rev??

[Matthias Rebbe | M-R-D]

Joseba,

on which on-rev server is your account hosted? Diesel, Tio, Pancake or Jasmine?
My accounts on the servers canary, pancake and jasmine are working.

The on-rev status page at http://on-rev.com/support/server-status/  does not 
show any malfunction.

But if your website is not working then you should definitely send an emergency 
support request
using the web form at http://on-rev.com/support/contact-us/

Regards,

Matthias



> Am 19.02.2015 um 20:44 schrieb Joseba Aguayo :
> 
> Is there problems in On-Rev
> Our website does not work since yesterday!!!
> Someone else??
> 
> Un saludo.
> 
> Joseba
> (jagu...@telur.es)
> 
> 
> ___
> 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

7.0 Issues

[Peter Haworth]

I've been careful to create separate versions of my stack files and
Livecode Preferences folder for use when running LC 7.  However, it seems
there other issues with compatibility.

I save the preferences for my application in a file in the
/Library/Application Support folder with the following statement:

*write* base64Encode(arrayEncode(gSettings)) to file "

These are then read in at startup with:

read from file myPath until EOF
   if it is empty then
  put empty into gSettings
   else
  put arrayDecode(base64Decode(it)) into gSettings
   end if

Yesterday, I started working on this stack with LC7 and the prefs file was
saved by the LC7 version of the stack.
Today, I needed to go back to the non LC7 version of the stack.  To my
surprise, a runtime error was thrown on the "put arrayDecode..." statement
above.  The  it variable looked  like it contained base64 encoded data.

I ran the LC7 version of the stack again and the runtime error did not
occur.

I restored the preferences file from a Time Machine backup that I know
preceded my use of LC7, ran the application again with LC 6.6.2, and all
worked fine.

So it seems that something in either the array/base64 encode/decode
 functions changed between v6.6.2 and 7.0.1.

I really want to use LC7 but stuff like this makes me very nervous.  How
many other inconsistencies like this are lurking out there.
___
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

Problems in On-Rev??

[Joseba Aguayo]

Is there problems in On-Rev
Our website does not work since yesterday!!!
Someone else??

Un saludo.

Joseba
(jagu...@telur.es)


___
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

iOS 64-bit support and 1st Gen iPad

[Chris Sheffield]

Got a question I’m hoping someone can answer. I’ve done some research, but 
can’t find what I’m looking for.

With LC 6.7.2, we gained 64-bit support for iOS apps. It seems to include 
32-bit support as well, since I can install and run an app on my 1st Gen iPad 
mini running iOS 8.1.3. However, we are also in need of still supporting the 
1st Gen iPad (if at all possible), running iOS 5.1.1. I can’t seem to get my 
app to install on that device, no matter what I try (Xcode, iTunes, TestFlight, 
other testing service, etc.). From Xcode, I get a message that apps that 
include 64-bit architecture cannot be installed with Xcode on devices running 
anything older than iOS 6.0. But the message also suggests that installing on a 
1st Gen iPad will still be supported through the App Store, although it’s a 
little vague. But if that’s the case, how in the world do we test our apps 
before going live with them!?

So, is anyone out there still trying to support the iPad 1? If so, have you 
been able to get an app installed after building it with LC 6.7.2? *Should* 
this work? Is there perhaps a bug of some kind in LC? Just trying to figure out 
what’s going on exactly. If we have to, we can probably drop iPad 1 support, 
since users would still be able to download the older version of the app 
through the app store, but that means no more updates for that device…

Thanks,
Chris

--
Chris Sheffield
Read Naturally, Inc.
www.readnaturally.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: Because LC can't do two things at once.

[Richard Gaskin]

Richmond wrote:

> I wonder WHY Livecode cannot do two things at once . . .

There is a difference between concurrency and parallelism which is 
useful here because LC currently provides a limited form of concurrency 
for some operations but delivers true parallelism only in the most 
recent version of 7 and only with regard to GPUs (and not AFAIK 
something we can use in our scripts, but something done in the engine to 
optimize rendering).


Long but excellent distinction between the two:

Rob Pike - 'Concurrency Is Not Parallelism'


TL/DR version:  Concurrency is a logical framework for handling tasks 
independently, while parallelism is the actual simultaneous execution of 
code across multiple processors.


This distinction is also useful here when comparing LC to other 
languages, since Python is one of the world's most popular languages and 
offers concurrency but not parallelism (at least not in the main 
distribution, though I believe there are now forks that provide 
parallelism).


Within LC, network I/O is concurrent (but not parallel) when you use 
callbacks, e.g.:


   accept connections on port  with "SomeCallbackMessage"

In those cases the network I/O is non-blocking, and whatever handler is 
accepting connections can be triggered again even before 
SomeCallbackMessage has completed.


This is very limited, however, since most non-network-I/O tasks are 
blocking, so chances are that SomeCallbackMessage will prevent anything 
meaningful from taking place in any re-entrant network I/O handlers.


Other forms of non-parallel concurrency can be had in LC as it is today 
using timers or "wait 0 with messages" - here's a simple stack to 
illustrate some of those options:




While a very simple demo, the ideas shown there can be expanded to make 
good use of idle processing time to handle background tasks 
independently of other operations.*


And then there are other ways we can use LC as it is today to achieve 
not only concurrency but even parallelism, using multiprocessing as an 
alternative to multithreading: faceless standalones launched with "open 
process for neither", which can work completely independently of the UI 
the user is interacting with, and exchange data with that UI app either 
through local sockets or even just the file system (tmp is good for this).



But all that's just tiny baby steps compared to what could be possible, 
so I like this question:


> AND, could it be revamped so that it could do two things at once?

Given:
- Python's success with non-parallel concurrency
- the overhead of threads
- the complexity of managing threads to avoid race conditions
  which (libURL aside) we've largely never had to even think about

...I would suggest we think carefully about what exactly we want.

Forking is absolutely essential for the Server engine to be able to 
support FastCGI implementations for more scalable systems.


But forking is a very specific form of concurrency.

Threading is another, one which requires syntax for managing queues and 
priorities.


Probably not as difficult to implement as it is to design the syntax for.


> Let the debate RAGE :)

All for it.  We already know we need some form of parallelism for 
large-scale server work, so it's probably useful to begin thinking about 
an approach for these sorts of things that could benefit the desktop as 
well.




* If we want to max out the CPU by taking full advantage of idle time 
for background processing, it would be ideal to do this only when 
powered by wall socket, so laptops running from battery wouldn't be 
drained unnecessarily by what could be optional workloads.   To do that 
we'd need to be able to know when a computer us running on battery, so I 
requested a powerStatus function:



--
 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: Because LC can't do two things at once.

[Mike Kerner]

Well, for anyone who's ever made an application
multitasking/multithreading, they'll tell you that there is all sorts of
extra complication involved in making it work, and if you've ever written
anything for a multithreading environment, it is definitely a lot of extra
work (it's worth it, IMHO, but it is not easy and straightforward).

You actually can make LC multithreaded-ish, and there have been discussions
about doing that, especially in server setups.

If you were prioritizing features for LC, would this be one of your top 5?
It might make my top 10, but I don't know if it would be in my top 5.

On Thu, Feb 19, 2015 at 1:06 PM, Richmond 
wrote:

> That's a quote from another posting . . .
>
> this might be the rock on which Livecode founders.
>
> Other languages can do two, or more, things at once . . . I am either too
> out of touch
> with other computer languages, or I don't know enough about how computer
> languages
> talk to computers (which, de facto, is pretty much the same thing), but I
> wonder WHY
> Livecode cannot do two things at once . . .
>
> AND, could it be revamped so that it could do two things at once?
>
> Java can manage multi-threaded programming . . .
>
> I assume [] that more and more computer languages are in the process
> of becoming
> capable of multi-threading . . .
>
> A while back, just for fun, I ran up a silly little game where the
> end-user had to steer a rocket past some static
> planets to get to Earth. The reason the planets were static is just
> because I could think of no way of them precessing
> in their orbits while the end-user was pressing arrow keys.
>
> Before I look a complete, steaming nit, I am sure there is a "work
> around"; but, to be quite honest, I wonder how many "work arounds"
> are necessary before the bell rings.
>
> In the great scheme of things my silly little game is neither here nor
> there: what it did do for me was NOT demonstrate
> the super capabilities of Livecode [ after 14 years of messing around with
> Livecode I am pretty well aware of those ],
> BUT demonstrate some of its limitations . . .
>
> Now, I know that the initial idea of Livecode was this:
>
> Kevin designing a front-end for a UNIX clone of Hypercard that he felt was
> more user-friendly than the Metacard one.
>
> However, like the Rary, it grew out of control . . .
>
> ---
> Side line; extreme tangentialism coming up: skip down to next load of
> dotted lines if you have a problem drifting
> off-off-off-topic with Richmond.
> 
>
> There was a Scotsman down to University in England, who was walking down
> the road and saw a matchbox lying in the road.
>
> Picking up the matchbox and opening it he found, inside, a small note
> written on a piece of paper and a small, black, spherical
> object that pulsated.
>
> The paper said; "This matchbox contains a Rary; feed it and care for it
> and it will bring you good fortune."
>
> The Scotsman took the matchbox back to his student room and started to
> feed the Rary; after his 3 years (short degree courses in England)
> the Rary was about the size of a tennis ball; black and hairy with no
> obvious eyes, mouth or other orifices.
>
> The man went away back to his butt-and-ben in the hills to look after his
> ageing parents, and continued to feed the Rary; by the time his
> parents were gathered the thing was about the size of a large medicine
> ball.
>
> Over the years our man continued to care for the Rary until it became the
> size of a small tractor and the man was beggared with
> the feeding bills.
>
> He decide to get rid of the Rary; so he got the thing into a boat and
> rowed it all the way south down the West Coast and past France and Spain;
> left into the Mediterranean, through the Suez canal, all the way across
> the Indian ocean until he came to Japan.
>
> Arriving at Japan he rolled the Rary, at great personal expense to himself
> and his health, up to the top of a very high cliff.
>
> He was just about to push the Rary over the cliff when it turned to him
> and said:
>
> "It's a long way to tip a Rary."
>
> >
> Should this story really annoy you; I take no credit whatsoever for it; my
> father, Donald Mathewson, told it to me when I was about 7,
> and, at the risk of sounding incredibly juvenile, I haven't stopped
> laughing since.
> ---
>
> NOW, Livecode is no longer a UNIX clone of Hypercard with Kevin's GUI
> strapped on the front.
>
> Nor is it anything like what it was 10 years ago.
>
> So, it has to keep growing AND evolving to compete [ THAT is the magic
> word ] . . .
>
> -
> After all; if it ONLY grows, then it is going to get pushed
> off the cliff soon enough.
> -
>
> Possibly the next reasonable step is multi-threading ?
>
> Let the debate RAGE :)
>
> Richmond.
>
>
>
>
> 

Because LC can't do two things at once.

[Richmond]

That's a quote from another posting . . .

this might be the rock on which Livecode founders.

Other languages can do two, or more, things at once . . . I am either 
too out of touch
with other computer languages, or I don't know enough about how computer 
languages
talk to computers (which, de facto, is pretty much the same thing), but 
I wonder WHY

Livecode cannot do two things at once . . .

AND, could it be revamped so that it could do two things at once?

Java can manage multi-threaded programming . . .

I assume [] that more and more computer languages are in the process 
of becoming

capable of multi-threading . . .

A while back, just for fun, I ran up a silly little game where the 
end-user had to steer a rocket past some static
planets to get to Earth. The reason the planets were static is just 
because I could think of no way of them precessing

in their orbits while the end-user was pressing arrow keys.

Before I look a complete, steaming nit, I am sure there is a "work 
around"; but, to be quite honest, I wonder how many "work arounds"

are necessary before the bell rings.

In the great scheme of things my silly little game is neither here nor 
there: what it did do for me was NOT demonstrate
the super capabilities of Livecode [ after 14 years of messing around 
with Livecode I am pretty well aware of those ],

BUT demonstrate some of its limitations . . .

Now, I know that the initial idea of Livecode was this:

Kevin designing a front-end for a UNIX clone of Hypercard that he felt 
was more user-friendly than the Metacard one.


However, like the Rary, it grew out of control . . .

---
Side line; extreme tangentialism coming up: skip down to next load of 
dotted lines if you have a problem drifting

off-off-off-topic with Richmond.


There was a Scotsman down to University in England, who was walking down 
the road and saw a matchbox lying in the road.


Picking up the matchbox and opening it he found, inside, a small note 
written on a piece of paper and a small, black, spherical

object that pulsated.

The paper said; "This matchbox contains a Rary; feed it and care for it 
and it will bring you good fortune."


The Scotsman took the matchbox back to his student room and started to 
feed the Rary; after his 3 years (short degree courses in England)
the Rary was about the size of a tennis ball; black and hairy with no 
obvious eyes, mouth or other orifices.


The man went away back to his butt-and-ben in the hills to look after 
his ageing parents, and continued to feed the Rary; by the time his

parents were gathered the thing was about the size of a large medicine ball.

Over the years our man continued to care for the Rary until it became 
the size of a small tractor and the man was beggared with

the feeding bills.

He decide to get rid of the Rary; so he got the thing into a boat and 
rowed it all the way south down the West Coast and past France and Spain;
left into the Mediterranean, through the Suez canal, all the way across 
the Indian ocean until he came to Japan.


Arriving at Japan he rolled the Rary, at great personal expense to 
himself and his health, up to the top of a very high cliff.


He was just about to push the Rary over the cliff when it turned to him 
and said:


"It's a long way to tip a Rary."

>
Should this story really annoy you; I take no credit whatsoever for it; 
my father, Donald Mathewson, told it to me when I was about 7,
and, at the risk of sounding incredibly juvenile, I haven't stopped 
laughing since.

---

NOW, Livecode is no longer a UNIX clone of Hypercard with Kevin's GUI 
strapped on the front.


Nor is it anything like what it was 10 years ago.

So, it has to keep growing AND evolving to compete [ THAT is the magic 
word ] . . .


-
After all; if it ONLY grows, then it is going to get pushed
off the cliff soon enough.
-

Possibly the next reasonable step is multi-threading ?

Let the debate RAGE :)

Richmond.




___
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

Vector Export?

[Graham Samuel]

AFAICS when one does ‘export snapshot’, the result is a bitmap even though the 
original object or group may have been a vector image or made up of vector 
images. At least that’s what I’ve seen from experimenting with the ‘export’ 
features of LC

Is there any way to export a vector image? What I’m actually trying to do is to 
export a screenshot that can have a higher resolution than that of the screen, 
for printing and so on. Other apps can do this, in effect (I mean they can have 
enlargement and/or resolution-changing features).

What do people do when they want a high-res output?

TIA

Graham
___
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: Faster way to get tabStops?

[Bob Sneidar]

Datagrids… GOOD!

Bob S


> On Feb 19, 2015, at 24:47 , BNig  wrote:
> 
> Hi Dan,
> 
> I ran into the same problem and figured that acessing the field and ask for
> formattedWidth is slow.
> 
> So I tried to minimize that.
> 
> I took each tab delimited item an stuffed it into an array. For each column
> one key.
> 
> You end up with each key holding the data of one column worth of data
> 
> Then I put that column into a field that has the same properties as the
> original field and get the formattedWidth. This tells me the space I need to
> set the tabstops.
> 
> That way I only access the field column times. This speeds up the whole
> process tremendously.
> 
> 
> 
> To see it in action you can have a look:
> ---
> http://runtime-revolution.278305.n4.nabble.com/ANN-modified-Table-Field-0-2-9-td4683338.html#a4683384
> --
> watch for line breaks.
> 
> look at the script of field "fData" handler mtfAdjustToWidthOfContent.
> 
> Kind regards
> 
> Bernd
> 
> 
> 
> 
> --
> View this message in context: 
> http://runtime-revolution.278305.n4.nabble.com/Faster-way-to-get-tabStops-tp4689049p4689064.html
> Sent from the Revolution - User mailing list archive at Nabble.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: The Future of Animation in LiveCode

[Bjoernke von Gierke]

> On 18 Feb 2015, at 01:52, Alex Tweedly  wrote:
> 
> If the problem is that LC is just too slow, and the required calculations 
> continuously or consistently take more time than is elapsed (i.e. we just 
> keep getting further and further behind), then the problem is performance, 
> not how/when we can trigger redraws.
> 
> But if the issue is "simply" that timers can't be relied upon to trigger 
> while calculations proceed, then we can (at considerable effort) minimize the 
> impact of that.

The problem is none of those. It's a problem that many games have, and that is 
not solvable with LC, because of the way it is always sequential.

An extreme example would be a real time game, which does auto-saves every 5 or 
30 minutes to hard disk, of non-trivial data amounts. The game would update 
it's screen timely as expected, until it saves, at which point it stalls for 
1-5 seconds, to write to the hard disk. Note that many games actually do it 
like that (ie. Factorio, all Paradox developed games, etc.).

Because LC can't do two things at once, and because it's screen redraw is so 
slow, one will run into these problems far more often, and with less intensive 
tasks then file access. Sometimes with just the screen updates alone (with the 
non-laggy amount of participants being well below 30 pieces, and without any 
user input or AI/maintenance stuff running). Even worse, there is simply no 
workaround. Now if there'd be a way to do screen redraws in parallel to doing 
calculations by script, that'd be a different thing. But because LC _depends_ 
on sequentiality for things like the message path and how send in time works, 
that is probably not going to happen very soon, and even long term (ie. in the 
next 5 years) it's doubtful.

 So in a sense it's both of your examples at once. 


--

Chat with other LC people:
http://bjoernke.com/chatrev

Use a better dictionary in the IDE:
http://www.bjoernke.com/bvgdocu

Try chartsEngine:
https://livecode.com/store/marketplace/charts-engine-1-2-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

Re: Faster way to get tabStops?

[BNig]

Thanks Mike,

you can load the field with 5000 lines worth of data via the Helper stack ->
Examples -> choose 5000 -> click button "fill with n lines of random data",
then move the lines by moving the dividers and then control-click into the
field.
This triggers the recalculation of the column widths via
"mtfAdjustToWidthOfContent"

It is quite fast.

Kind regards
Bernd


Mike Bonner wrote
> Wow. Nice Bernd.
> 
> On Thu, Feb 19, 2015 at 1:47 AM, BNig <

> bernd.niggemann@

> > wrote:
> 
>> Hi Dan,
>>
>> I ran into the same problem and figured that acessing the field and ask
>> for
>> formattedWidth is slow.
>>
>> So I tried to minimize that.
>>
>> I took each tab delimited item an stuffed it into an array. For each
>> column
>> one key.
>>
>> You end up with each key holding the data of one column worth of data
>>
>> Then I put that column into a field that has the same properties as the
>> original field and get the formattedWidth. This tells me the space I need
>> to
>> set the tabstops.
>>
>> That way I only access the field column times. This speeds up the whole
>> process tremendously.
>>
>>
>>
>> To see it in action you can have a look:
>> ---
>>
>> http://runtime-revolution.278305.n4.nabble.com/ANN-modified-Table-Field-0-2-9-td4683338.html#a4683384
>> --
>> watch for line breaks.
>>
>> look at the script of field "fData" handler mtfAdjustToWidthOfContent.
>>
>> Kind regards
>>
>> Bernd





--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Faster-way-to-get-tabStops-tp4689049p4689067.html
Sent from the Revolution - User mailing list archive at Nabble.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] R.I.P. Mac Mini

[Richmond]

On 19/02/15 03:31, Bob Warren wrote:
A few days back I finished doing a few minor corrections to my Unicode 
"File/Folder/Picture Choosers" for Windows and Linux, and declared 
them "stable". If you download them, please test them well before 
distributing them in any way, to make absolutely sure they are as 
"stable" as I think they are.


I then had an idea. I had had a first-generation Mac Mini sitting in 
the corner of my computer room for a long time, and I hadn't done much 
with it. (One reason is that it had a broken DVD drive.) It occurred 
to me that since the Mac file system is not so different to that of 
Linux, it might not be too difficult to produce some chooser widgets 
for Mac as well. Of course, they would need to be "legacy" (English 
only) widgets, because the machine had OS X Tiger 10.4 that was not 
supported by LiveCode/Unicode. So I had a bash at it. I rolled the 
Linux and Windows widgets together, and soon came up with a new set of 
MAC chooser widgets that had reached what I might fairly call the 
"beta" stage. However, the very day after, my Mini started going a bit 
crazy, and like a drip I didn't realize immediately that the cooling 
system had failed and that it was overheating. The end result is that 
now I have a "fried" Mac Mini. I do not intend to buy another one. In 
Brazil (my country of residence), Macs are impossibly expensive. If I 
replaced my simple Mini with an equivalent modern one, it would cost 
me $1,500 (which you might find difficult to believe). You now know 
why Macs are extremely rare in Brazil!


Luckily, I had not only finished the programs, I had taken a few 
screenshots. I was therefore able to put the widgets up at my site:


GENERAL INFO:
http://www.howsoft.com/runrev/runrev_stacks_index.htm

MAC CHOOSERS PAGE:
http://www.howsoft.com/runrev/macchoosers/

DOWNLOADS:
http://www.howsoft.com/runrev/downloads/

Under the circumstances (of my now being "Macless"), I'd be grateful 
if any of you could tell me:


a) whether these widgets work on a "real" MAC;
b) whether they are stable enough for usage in your opinion;
b) whether they detect DVD drives correctly as well as other USB 
devices such as pendrives and external HDs.


Thanks!

Regards to all.



Well; I'll try them on my PPC G5 running both 10.4 and 10.5

as to "Real" Macs (by 'real' I assume to mean 'reasonably comtemporary) 
I will try them on my

'unreal' 10.8 (VMware) . . .

I will, also, just to be bloody-minded, see how they behave on my Linux 
box :)


Richmond.

___
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: Faster way to get tabStops?

[Mike Bonner]

Wow. Nice Bernd.

On Thu, Feb 19, 2015 at 1:47 AM, BNig  wrote:

> Hi Dan,
>
> I ran into the same problem and figured that acessing the field and ask for
> formattedWidth is slow.
>
> So I tried to minimize that.
>
> I took each tab delimited item an stuffed it into an array. For each column
> one key.
>
> You end up with each key holding the data of one column worth of data
>
> Then I put that column into a field that has the same properties as the
> original field and get the formattedWidth. This tells me the space I need
> to
> set the tabstops.
>
> That way I only access the field column times. This speeds up the whole
> process tremendously.
>
>
>
> To see it in action you can have a look:
> ---
>
> http://runtime-revolution.278305.n4.nabble.com/ANN-modified-Table-Field-0-2-9-td4683338.html#a4683384
> --
> watch for line breaks.
>
> look at the script of field "fData" handler mtfAdjustToWidthOfContent.
>
> Kind regards
>
> Bernd
>
>
>
>
> --
> View this message in context:
> http://runtime-revolution.278305.n4.nabble.com/Faster-way-to-get-tabStops-tp4689049p4689064.html
> Sent from the Revolution - User mailing list archive at Nabble.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: Faster way to get tabStops?

[BNig]

Hi Dan,

I ran into the same problem and figured that acessing the field and ask for
formattedWidth is slow.

So I tried to minimize that.

I took each tab delimited item an stuffed it into an array. For each column
one key.

You end up with each key holding the data of one column worth of data

Then I put that column into a field that has the same properties as the
original field and get the formattedWidth. This tells me the space I need to
set the tabstops.

That way I only access the field column times. This speeds up the whole
process tremendously.



To see it in action you can have a look:
---
http://runtime-revolution.278305.n4.nabble.com/ANN-modified-Table-Field-0-2-9-td4683338.html#a4683384
--
watch for line breaks.

look at the script of field "fData" handler mtfAdjustToWidthOfContent.

Kind regards

Bernd




--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Faster-way-to-get-tabStops-tp4689049p4689064.html
Sent from the Revolution - User mailing list archive at Nabble.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