Re: [ANN] Release 8.2.0 DP-2

[Sannyasin Brahmanathaswami via use-livecode]

Thanks for the update Mark… you have our app on Git, so if you can make it work 
on Android, sometime in November, that will be great! We will keep pushing on 
content. Getting a proper rendering on opening and closing stacks is the key 
missing factor on Android.


On 10/12/17, 8:45 AM, "use-livecode on behalf of Mark Waddingham via 
use-livecode"  wrote:

The most intensive part of this work is going through and updating 
around 150 or so places in the engine which flag where a redraw is 
needed - making sure they are doing so much more specifically (e.g. the 
border of this control has changed, so just update the border) - 
slightly tedious perhaps, but well worth it and I've been plugging away 
at it.

So, anyway, I can't yet give a date for when all the work will be 
complete - but at the moemnt, at least, we do appear to be on track for 
delivery in November... Although, famous last words and all that!

___
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: Query Input Form

[Stephen Barncard via use-livecode]

Using a data grid? Or a chain of pop-ups selectors?

On Thu, Oct 12, 2017 at 08:00 Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Has anyone put together a query input form, that can take simple input
> from a user, like:
> customers.customername is/is not/is greater than/is less than/is like
>  AND/OR
>  AND/OR
>  ...
>
> and then build an sql query for it?
>
> Bob S
> ___
> 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
>
-- 
--
Stephen Barncard - Sebastopol Ca. USA -
mixstream.org
___
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: Atkinson dither algorithm & 'for each' loop

[hh via use-livecode]

@Al.
For multiples of 1/8 (Atkinson) you need 8*256=2048 integers,
that is 11 Bit.
For multiples of 1/16 (Floyd-Steinberg) you need 16*256=4096
integers, that is 12 Bit.
In 2 chars = 16 Bit fit even multiples of 1/256.
No dither-algorithm uses such tiny diffusion-errors.

___
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.2.0 DP-2

[Richard Gaskin via use-livecode]

Mark Waddingham wrote:

> I've already sorted out selection handles based on some work Ali did a
> while back in 9 - all selection type handles are now rendered above
> everything else and the graphical artifacts which appeared in
> accelRender mode have been eliminated.

I certainly don't want to distract you from rendering performance, but 
as long as you have your head in the selection indication code I wonder 
if this might become possible in v9:


Selection Handles: Make selection border optional
http://quality.livecode.com/show_bug.cgi?id=17676

The dashed border around selected controls certainly makes their 
selected state clear, but it also obscures the object's own border, 
sometimes making it difficult to visualize placement or changes to 
border treatments until I deselect it.


I kinda liked how it used to be, where the only indicators added to a 
selected object were the interactive handles, leaving the rest of the 
object visibly the same so we could evaluate changes made to it as we 
were making them.


But I recognize the change to alter the border treatment on selection 
was probably made for a reason, so if that reason is still important 
maybe that could become optional?


--
 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

Atkinson dither algorithm & 'for each' loop

[Alejandro Tejada via use-livecode]

Hi Hermann,

Hermann Hoch wrote:
> So all considerations to improve the LCS script are,
> TMHO, of rather theoretical value. Here are some more:
> The Atkinson algorithm uses multiples of 1/8 = 0.125 for
> the diffusion-error, the Floyd-Steinberg algorithm uses
> multiples of 1/16 = 0.0625.
> And have this in mind:
> Whenever you use numToChar(Number) in your script you
> are wrong by Number - round(Number) of the accumulated
> pixel value ...

This is correct, for this reason, in the most recent version of
this handler, I am using 2 chars to store the new pixel value.
first char is a whole number from 0 to 255 and the second
char represent a decimal part from 0 to 99.

I will test if using 5 chars for storing the new pixel value.
In this way, the new pixel could store values of
.00 that should be enough for this task...

After reading Mark's answer, I learned that using a numerical
ordered array to store pixel values could be really fast too.
This is another path to explore.

Al
___
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: Atkinson dither algorithm & 'for each' loop

[hh via use-livecode]

> Al wrote:
> Please, check this new handler in the forum and suggest how to
> make this faster and more precise.

I already gave you a method that is, with a 500x500 image, at
least 1000 (thousand) times faster than your script.

Of course this is not due my special skills but the ability of
javascript (used via a browser widget) to let the GPU/graphic
card do the essential job of pixel manipulation.

So all considerations to improve the LCS script are, TMHO, of
rather theoretical value. Here are some more:

> Al wrote:
> ... the result STILL is not visually identical to that handler.
> My educated guess is that Atkinson dither algorithm requires
> numbers with more than 2 numbers after the decimal point.
> That is: 243.643578 instead of just 243.64

Conclude from the following:
The Atkinson algorithm uses multiples of 1/8 = 0.125 for the
diffusion-error, the Floyd-Steinberg algorithm uses multiples
of 1/16 = 0.0625. 

And have this in mind:
Whenever you use numToChar(Number) in your script you are wrong by
Number - round(Number) of the accumulated pixel value ...

___
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.2.0 DP-2

[Mark Waddingham via use-livecode]

On 2017-10-11 19:09, Dan Brown via use-livecode wrote:

Any news on the progress of datagrid v2 and enhanced graphics speed?


Just to embellish what Panos said...

There has been 2-3 of us working on the DG2 project over the last couple 
of sprints:


  1) Monte has been updating the DG to automatically take advantage of 
mobile scrollers


  2) Michael has been working on updating the DG to do the edit mode / 
swipe actions as described in the project


  3) I've been working on updating acceleratedRendering mode to allow 
child controls to have dynamic layers


I believe (1) is complete and should appear in the next 9 DP (although 
don't hold me to that, it might be the one after the next one!).


The script level DG changes (2) is making good progress - Michael is on 
the second sprint worth of work on it.


The engine level accelRender changes (3) is not going too badly either.

I've already sorted out selection handles based on some work Ali did a 
while back in 9 - all selection type handles are now rendered above 
everything else and the graphical artifacts which appeared in 
accelRender mode have been eliminated.


I've also done an initial refactor of the way the underlying 'TileCache' 
mechanism (which is the core of accelRender mode) is used from the main 
engine code - the goal being that each control type controls how it is 
rendered in that mode; rather than it happening in one place which is 
the case currently. This is the crux of allowing child controls (of 
groups) to be dynamic layers but it has some other nice benefits too...


In particular, it means that we should be able to eliminate the rules 
about when controls can use accelRender (something I wasn't sure would 
be possible when we specified the DG2 project) - e.g. you should, after 
this work is complete, be able to set a group to 'dynamic' and then it 
will automatically make itself scrolling if it is a scrolling group, and 
also retain other things like its border and label should they be set 
(similarly fields can get the same treatment).


The most intensive part of this work is going through and updating 
around 150 or so places in the engine which flag where a redraw is 
needed - making sure they are doing so much more specifically (e.g. the 
border of this control has changed, so just update the border) - 
slightly tedious perhaps, but well worth it and I've been plugging away 
at it.


So, anyway, I can't yet give a date for when all the work will be 
complete - but at the moemnt, at least, we do appear to be on track for 
delivery in November... Although, famous last words and all that!


Warmest Regards,

Mark.

--
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: Atkinson dither algorithm & 'for each' loop

[Mark Waddingham via use-livecode]

On 2017-10-12 19:35, Alejandro Tejada via use-livecode wrote:

Peter Read wrote:

One note of caution regarding the use of the "repeat for each" loop,
whilst you will get a loop iteration for every value in the collection
(fldhexa3 in your example), you are not guaranteed the order in
which they will occur. This doesn't matter in a lot of cases but
does matter when the sequence is significant.  In the case of your
example I believe sequence is critical, otherwise the pixels might
appear to be scrambled!


Prior to 7, you had to be careful not to modify either the container 
being iterated over *or* the var holding the chunk for the current 
iteration as it could cause issues as described (actually, it was 
fundamentally unsafe to do that, as it could result in a crash). i.e.


  repeat for each item tItem in tContainer
replace "Foo" with "B" in tContainer -- BAD - MIGHT CAUSE PROBLEMS
put "a' into char 2 of tItem -- BAD - MIGHT CAUSE PROBLEMS
  end repeat

From 7 onwards, this is no longer the case. You can do whatever you want 
with either the container. Indeed, in 7, the engine essentially operates 
as if it was iterating over a copy of the container and with a copy of 
the chunk (i.e. tItem and tContainer in the above snippet).


Upshot - you can do whatever you want with your variables - the engine 
ensures that what you do won't affect what you asked for to begin with 
(in particular, if you asked to iterate over tContainer, then it will 
iterate over tContainer as it was at the point you first asked - any 
changes to tContainer after the initial repeat for each line will have 
no effect on the repeat for each clause).


Warmest Regards,

Mark.

--
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

Atkinson dither algorithm & 'for each' loop

[Alejandro Tejada via use-livecode]

A few hours ago, I send a message to the mail list, a message that vanish
without trace. Now I am resending parts of that message. The rest of the
message is in the forum...

Peter Read wrote:
> One note of caution regarding the use of the "repeat for each" loop,
> whilst you will get a loop iteration for every value in the collection
> (fldhexa3 in your example), you are not guaranteed the order in
> which they will occur. This doesn't matter in a lot of cases but
> does matter when the sequence is significant.  In the case of your
> example I believe sequence is critical, otherwise the pixels might
> appear to be scrambled!

In my own setup, the control structure "repeat for each" is caching
the content of the working variable. This means that we could not
modify the content of this variable while the control structure is
working with it.

After reading your message, now I understand why this happens.
If developers are allowed to modify a variable used by a control
structure like "repeat for  each" then we could get unexpected
result as you describe: elements are processed in an out of order
sequence.

Ben Rubinstein wrote in response to Peter Reid:
> Are you sure? My understanding has always been that
> chunk items, e.g.
> repeat for each [ byte | char | word | item | line]  in 
> will always be sequential (indeed that's why this structure is fast)
> - it's only when dealing with hashed arrays that the sequence is
> not reliable, i.e.
> repeat for each key  in 
> repeat for each element  in 
> Do you have experience to the contrary?

As I wrote earlier in this same message, Peter could have found
some way to change the working variable in a repeat for each
control structure and the result is that elements are processed
with an out of order sequence.

By the way, after reading all comments and recommendations
about the atkinson dither algorithm, I wrote a new handler that
is a lot faster that my first handler, but the result STILL is not
visually identical to that handler.

My educated guess is that Atkinson dither algorithm requires
numbers with more than 2 numbers after the decimal point.
That is: 243.643578 instead of just 243.64
Later this week, I will try to discover the minimal number of
decimal numbers that this algorithm requires.

Please, check this new handler in the forum and suggest how to make
this faster and more precise:

https://forums.livecode.com/viewtopic.php?f=10&p=159078&sid=b46bc56428cb5b0f48d2c6520c107c47#p159078

Have a nice week!

Al
___
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

Repeat For Each Iteration Order (was Re: use-livecode Digest, Vol 169, Issue 18)

[Mark Waddingham via use-livecode]

On 2017-10-12 18:38, Peter Reid via use-livecode wrote:

I agree that the redundant indexing is an expensive approach, however
I have found that this abnormal structure of a repeat for each loop
can be a lot faster than the other loop forms in some circumstances.

I can't find the reference that first highlighted to me the lack of
guaranteed sequence of chunks, but I've assumed this was a restriction
for some time. It would be great if this is incorrect as I've got some
heavyweight looping in several of my apps that would benefit from
this!

Can anyone from LiveCode give a definitive answer to this please?


Yes - the previous posts are correct.

If you are using 'repeat for each' to iterate over something which has 
an order, then the iteration will follow that order.


Specifically:

   - string chunks (char, item, line, word, trueWord, sentence, 
paragraph, token, codepoint, codeunit) are all ordered


   - byte chunks are ordered

   - key chunks are unordered (they use the hash-order of the array, 
which can change arbitrarily even within a session)


   - element chunks are ordered for arrays which are sequences*, 
unordered for all other arrays


* An array is a sequence if: it has only integer keys, and keys range 
from 1 up to the number of elements in the array.
  e.g. If the keys are 1, 2, 3, 4 - then that is a sequence; 0, 1, 2, 3 
is not; 1, 3, 4 is not.


Just to reiterate something Richard mentioned - the performance 
advantage of a 'repeat for each' loop is completely lost if you use a 
normal chunk within the loop to fetch another part (or the same part!) 
of the container:


  put 0 into tIndex
  repeat for each word tWord in tString
add 1 to tIndex
put word somefunc(tIndex) of tString into tSameWord
...
  end repeat

This is because the chunk evaluation must step through somefunc(tIndex) 
words in the string *again*. (It takes N steps to access the N'th 
string/byte chunk in a container - repeat for each gets its performance 
advantage because it remembers where it got the previous chunk from so 
it can fetch the next, so it is just 1 step each iteration).


The only types of access which are guaranteed not to have this N step 
behavior are codeunit, byte and array accesses:


  - a LiveCode string is (internally) an array of codeunits; which means 
that it takes only one step to get any codeunit in it.


  - a LiveCode binary string is (internally) an array of bytes; so it 
only takes one step to get any byte from it


  - LiveCode arrays are hash-tables, so you can look up any key in one 
step


Note: If you are using the 'byte' chunk, make sure that the thing they 
are accessing *is* actually a binary string before using it on them. The 
conversion from string -> binary string (which exists for compatibility 
with pre-7 scripts) will cause a performance bump.


In terms of the codeunit/codepoint/character chunks - the engine *tries* 
to ensure it does as little work as possible when accessing these. 
Internally, the engine sets flags on a string so that it can optimize 
these lookups. In particular:


  1) If a string contains only Unicode codepoints from the first 64k 
Unicode codes *without* surrogates (they give access to everything above 
64k) then codepoint access on that string will be 1 step.


  2) If a string contains characters which are only composed of single 
codepoints in the first 64k Unicode code *without* surrogates, then char 
access on that string will be 1 step.


In particular, if the string you are processing actually came from a 
native string; then (1) and (2) are guaranteed to be the case. However, 
if you have arbitrary Unicode strings, then it won't generally be the 
case:


  a) any characters which have a Unicode code > 64k must be represented 
by two codes < 64k (surrogate pairs); this means that the engine has to 
step through the string codeunit by codeunit to count the codepoints so 
it can find the one you asked for (N step again)


  b) any characters which are composed of multiple codepoints are in the 
same boat


Case (b) can arise quite often even in Roman script languages. For 
example, in Unicode you can write e-acute as EITHER e,combining-acute 
(two codepoints) OR as e-with-acute (one codepoint). For some languages, 
most characters will be multiple codepoints - e.g. the Indic languages. 
There are also a lot of esoteric languages (for scholarly / academic 
purposes) which are entirely defined by Unicode codepoints > 64k.


Upshot is that if you are doing char by char string processing of 
general Unicode strings, then try and use repeat for each char; and if 
you *can't* do that for some reason, then try and work out how you can 
do the processing by using the codeunit chunk.


However, as Knuth is famed for saying - "Premature optimization is the 
root of all evil" - don't spend time trying to optimize an algorithm 
until you have a working version and can intimately analyse where the 
slow parts are. Trying to optimize ahead o

Re: use-livecode Digest, Vol 169, Issue 18

[Mark Wieder via use-livecode]

On 10/12/2017 09:38 AM, Peter Reid via use-livecode wrote:


I can't find the reference that first highlighted to me the lack of guaranteed 
sequence of chunks, but I've assumed this was a restriction for some time. It 
would be great if this is incorrect as I've got some heavyweight looping in 
several of my apps that would benefit from this!


I have quite a lot of code that would fail miserably if the 'repeat for 
each' construct would get things out of sequence. But if you're 
referring to the 'repeat for each element' or 'repeat for each key' 
constructs, then there's no ordered sequence in the array to begin with.


--
 Mark Wieder
 ahsoftw...@gmail.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: use-livecode Digest, Vol 169, Issue 18

[Peter Reid via use-livecode]

I agree that the redundant indexing is an expensive approach, however I have 
found that this abnormal structure of a repeat for each loop can be a lot 
faster than the other loop forms in some circumstances.

I can't find the reference that first highlighted to me the lack of guaranteed 
sequence of chunks, but I've assumed this was a restriction for some time. It 
would be great if this is incorrect as I've got some heavyweight looping in 
several of my apps that would benefit from this!

Can anyone from LiveCode give a definitive answer to this please?

Peter
--
Peter Reid
Loughborough, UK

> On 12 Oct 2017, at 4:36pm, use-livecode-requ...@lists.runrev.com wrote:
> 
> Message: 17
> Date: Thu, 12 Oct 2017 08:35:50 -0700
> From: Richard Gaskin 
> To: use-livecode@lists.runrev.com
> Subject: Re: Atkinson dither algorithm & 'for each' loop
> Message-ID: 
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Peter Reid wrote:
> 
>> One note of caution regarding the use of the "repeat for each" loop,
>> whilst you will get a loop iteration for every value in the collection
>> (fldhexa3 in your example), you are not guaranteed the order in which
>> they will occur.
> 
> Maybe I misunderstand, but are you thinking of arrays there?
> 
> With string containers a "repeat for each" expression should parse from 
> beginning to end, sequentially.
> 
> Any exception to that would be prohibitively unpredictable, and should 
> be reported as a bug.
> 
> 
>> The following adjusted loop guarantees the sequence at the expense of
>> speed:
>> 
>>  put 1 into i
>>  repeat for each word theWord in fldhexa3
>> put word i of fldhexa3 into theWord
> 
> The speed lost there appears to be the result of a redundancy, and a 
> particularly expensive one:
> 
> We love the convenience of chunk expressions, but in loops we want to 
> remain mindful of "  of " because satisfying 
> such expressions will require the engine to start from the beginning of 
> the container, examine every character and counting delimiters, until it 
> reaches the number of such delimiters specified in "".
> 
> So the "repeat" line above parses the chunk value into theWord, but then 
> the next line ignores that that's already happened and reassigns the 
> same theWord value using an expression that requires then engine to 
> count words from the beginning of fldhexa3 each time through the loop.
> 
> 
> With this specific algo I believe there may be further benefits in using 
> a chunk type other than word (based on a a hunch derived from word 
> chunks being parsed more flexibly than items or lines), and perhaps not 
> converting the binary data to hex at all, instead parsing bytes directly 
> with a "step 4" option in the loop to keep track of the four components 
> that define each pixel.
> 
> -- 
>  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: Atkinson dither algorithm & 'for each' loop

[Richard Gaskin via use-livecode]

Peter Reid wrote:

> One note of caution regarding the use of the "repeat for each" loop,
> whilst you will get a loop iteration for every value in the collection
> (fldhexa3 in your example), you are not guaranteed the order in which
> they will occur.

Maybe I misunderstand, but are you thinking of arrays there?

With string containers a "repeat for each" expression should parse from 
beginning to end, sequentially.


Any exception to that would be prohibitively unpredictable, and should 
be reported as a bug.



> The following adjusted loop guarantees the sequence at the expense of
> speed:
>
>   put 1 into i
>   repeat for each word theWord in fldhexa3
>  put word i of fldhexa3 into theWord

The speed lost there appears to be the result of a redundancy, and a 
particularly expensive one:


We love the convenience of chunk expressions, but in loops we want to 
remain mindful of "  of " because satisfying 
such expressions will require the engine to start from the beginning of 
the container, examine every character and counting delimiters, until it 
reaches the number of such delimiters specified in "".


So the "repeat" line above parses the chunk value into theWord, but then 
the next line ignores that that's already happened and reassigns the 
same theWord value using an expression that requires then engine to 
count words from the beginning of fldhexa3 each time through the loop.



With this specific algo I believe there may be further benefits in using 
a chunk type other than word (based on a a hunch derived from word 
chunks being parsed more flexibly than items or lines), and perhaps not 
converting the binary data to hex at all, instead parsing bytes directly 
with a "step 4" option in the loop to keep track of the four components 
that define each pixel.


--
 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

Query Input Form

[Bob Sneidar via use-livecode]

Has anyone put together a query input form, that can take simple input from a 
user, like:
customers.customername is/is not/is greater than/is less than/is like  
AND/OR
 AND/OR
 ... 

and then build an sql query for it? 

Bob S
___
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: Atkinson dither algorithm & 'for each' loop

[Bob Sneidar via use-livecode]

That is correct Ben. It's not the repeat for each that is unreliable (probably 
a bad word to use here) but it is arrays which do not retain the sequence of 
key/values in the order they were put in. 

To get around this, when possible use numbered keys, then:

put  the keys of aMyArray into tKeyList
sort the lines of tKeyList numeric ascending
repeat for each line tKey in tKeyList
...

Bob S


> On Oct 12, 2017, at 04:48 , Ben Rubinstein via use-livecode 
>  wrote:
> 
> Hi Peter,
> 
>> One note of caution regarding the use of the "repeat for each" loop, whilst 
>> you will get a loop iteration for every value in the collection
>> (fldhexa3 in your example), you are not guaranteed the order in which they
>> will occur.
> 
> Are you sure? My understanding has always been that chunk items, e.g.
>   repeat for each [ byte | char | word | item | line]  in 
> 
> will always be sequential (indeed that's why this structure is fast) - it's 
> only when dealing with hashed arrays that the sequence is not reliable, i.e.
>   repeat for each key  in 
>   repeat for each element  in 
> 
> Do you have experience to the contrary?
> 
> best regards,
> 
> Ben


___
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: Autocompletion of quotes on LC 8.2,0 DP-1

[Bob Sneidar via use-livecode]

I've run into that in the past, and that issue was that the window shrinks each 
time a stack is opened. I think that was addressed a long time ago, but what I 
have done because I have multiple windows and I am finding my windows off 
screen so often, is I save the rect and loc in a property of the stack when I 
close it, then on openStack I check to make sure all the coordinates are within 
the screen rect, and if not I center the window. 

Bob S


> On Oct 11, 2017, at 18:35 , Monte Goulding via use-livecode 
>  wrote:
> 
> I haven’t noticed this myself but dod spend some time trying to replicate it. 
> A few people have complained about it. Has it been reported? My suspicion if 
> it is just a Mac issue would be the menubar height is somehow not being taken 
> into account.
> 
> Cheers
> 
> Monte

___
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: Microsoft 365 Rest API

[Skip Kimpel via use-livecode]

Amen to that...

SKIP

On Thu, Oct 12, 2017 at 9:54 AM, Roger Eller via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Skip, we are piloting the same starship in alternate universes, I do
> believe.  ;)
>
> ~Roger
>
>
> On Thu, Oct 12, 2017 at 9:47 AM, Skip Kimpel via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > Roger... why is it that you and I are ALWAYS on the same page and
> > interested in the same things?
> >
> > Love it!
> >
> > SKIP
> >
> > On Thu, Oct 12, 2017 at 9:43 AM, Roger Eller via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> > > VERY interested!  Will this be shared, or become a add-on product for
> the
> > > LC community?
> > >
> > > ~Roger
> > >
> > >
> > > On Thu, Oct 12, 2017 at 8:54 AM, Pi Digital via use-livecode <
> > > use-livecode@lists.runrev.com> wrote:
> > >
> > > > I’ve been currently working on a project with another Livecoder
> making
> > a
> > > > library to work with MS Dynamics365. It turns out that the best way
> for
> > > LC
> > > > to work with it is via their webAPI (as are most things) until v9 is
> > > ready.
> > > > But this still means a lot of stuff being put together outside of LC.
> > You
> > > > first need an Azure account setup to enable authentication. You then
> > need
> > > > someone conversant with c#, Visual Basic and .net to write the APIs
> > based
> > > > on the MS SDK. This then needs putting onto a .net server. From there
> > it
> > > is
> > > > really straight forward to set up a http header in LC and all of the
> > Post
> > > > and http calls to send and receive data.
> > > >
> > > > To be honest, the LC side of things is really simple, and our API guy
> > has
> > > > been really good at setting the whole thing up for us. We found him
> via
> > > > PeoplePerHour and is clearly one of the best in his field.
> > > >
> > > > It’s been a long process working out how to get it all to work
> together
> > > so
> > > > I’m happy I can now make it easier for members like you, saving you
> the
> > > > effort of fumbling around (like we did) to find a solution.
> > > >
> > > > PM me if and when you need more guidance and we can set up a Skype,
> > > > FaceTime or whatever.
> > > >
> > > > All the best
> > > >
> > > > Sean Cole
> > > > Pi Digital
> > > > s...@pidigital.co.uk
> > > >
> > > > > On 12 Oct 2017, at 12:52, Colin Kelly via use-livecode <
> > > > use-livecode@lists.runrev.com> wrote:
> > > > >
> > > > > Does anyone have any working livecode scripts/libraries to use with
> > the
> > > > Microsoft 365 Rest API for accessing Calendar entries?
> > > > >
> > > > >
> > > > >
> > > > > Any help much appreciated.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Colin Kelly
> > > > >
> > > > >
> > > > >
> > > > > ___
> > > > > 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
> >
> ___
> 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: Microsoft 365 Rest API

[Roger Eller via use-livecode]

Skip, we are piloting the same starship in alternate universes, I do
believe.  ;)

~Roger


On Thu, Oct 12, 2017 at 9:47 AM, Skip Kimpel via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Roger... why is it that you and I are ALWAYS on the same page and
> interested in the same things?
>
> Love it!
>
> SKIP
>
> On Thu, Oct 12, 2017 at 9:43 AM, Roger Eller via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > VERY interested!  Will this be shared, or become a add-on product for the
> > LC community?
> >
> > ~Roger
> >
> >
> > On Thu, Oct 12, 2017 at 8:54 AM, Pi Digital via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> > > I’ve been currently working on a project with another Livecoder making
> a
> > > library to work with MS Dynamics365. It turns out that the best way for
> > LC
> > > to work with it is via their webAPI (as are most things) until v9 is
> > ready.
> > > But this still means a lot of stuff being put together outside of LC.
> You
> > > first need an Azure account setup to enable authentication. You then
> need
> > > someone conversant with c#, Visual Basic and .net to write the APIs
> based
> > > on the MS SDK. This then needs putting onto a .net server. From there
> it
> > is
> > > really straight forward to set up a http header in LC and all of the
> Post
> > > and http calls to send and receive data.
> > >
> > > To be honest, the LC side of things is really simple, and our API guy
> has
> > > been really good at setting the whole thing up for us. We found him via
> > > PeoplePerHour and is clearly one of the best in his field.
> > >
> > > It’s been a long process working out how to get it all to work together
> > so
> > > I’m happy I can now make it easier for members like you, saving you the
> > > effort of fumbling around (like we did) to find a solution.
> > >
> > > PM me if and when you need more guidance and we can set up a Skype,
> > > FaceTime or whatever.
> > >
> > > All the best
> > >
> > > Sean Cole
> > > Pi Digital
> > > s...@pidigital.co.uk
> > >
> > > > On 12 Oct 2017, at 12:52, Colin Kelly via use-livecode <
> > > use-livecode@lists.runrev.com> wrote:
> > > >
> > > > Does anyone have any working livecode scripts/libraries to use with
> the
> > > Microsoft 365 Rest API for accessing Calendar entries?
> > > >
> > > >
> > > >
> > > > Any help much appreciated.
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Colin Kelly
> > > >
> > > >
> > > >
> > > > ___
> > > > 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
>
___
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: Microsoft 365 Rest API

[Skip Kimpel via use-livecode]

Roger... why is it that you and I are ALWAYS on the same page and
interested in the same things?

Love it!

SKIP

On Thu, Oct 12, 2017 at 9:43 AM, Roger Eller via use-livecode <
use-livecode@lists.runrev.com> wrote:

> VERY interested!  Will this be shared, or become a add-on product for the
> LC community?
>
> ~Roger
>
>
> On Thu, Oct 12, 2017 at 8:54 AM, Pi Digital via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > I’ve been currently working on a project with another Livecoder making a
> > library to work with MS Dynamics365. It turns out that the best way for
> LC
> > to work with it is via their webAPI (as are most things) until v9 is
> ready.
> > But this still means a lot of stuff being put together outside of LC. You
> > first need an Azure account setup to enable authentication. You then need
> > someone conversant with c#, Visual Basic and .net to write the APIs based
> > on the MS SDK. This then needs putting onto a .net server. From there it
> is
> > really straight forward to set up a http header in LC and all of the Post
> > and http calls to send and receive data.
> >
> > To be honest, the LC side of things is really simple, and our API guy has
> > been really good at setting the whole thing up for us. We found him via
> > PeoplePerHour and is clearly one of the best in his field.
> >
> > It’s been a long process working out how to get it all to work together
> so
> > I’m happy I can now make it easier for members like you, saving you the
> > effort of fumbling around (like we did) to find a solution.
> >
> > PM me if and when you need more guidance and we can set up a Skype,
> > FaceTime or whatever.
> >
> > All the best
> >
> > Sean Cole
> > Pi Digital
> > s...@pidigital.co.uk
> >
> > > On 12 Oct 2017, at 12:52, Colin Kelly via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> > >
> > > Does anyone have any working livecode scripts/libraries to use with the
> > Microsoft 365 Rest API for accessing Calendar entries?
> > >
> > >
> > >
> > > Any help much appreciated.
> > >
> > >
> > >
> > > --
> > >
> > > Colin Kelly
> > >
> > >
> > >
> > > ___
> > > 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: Microsoft 365 Rest API

[Roger Eller via use-livecode]

VERY interested!  Will this be shared, or become a add-on product for the
LC community?

~Roger


On Thu, Oct 12, 2017 at 8:54 AM, Pi Digital via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I’ve been currently working on a project with another Livecoder making a
> library to work with MS Dynamics365. It turns out that the best way for LC
> to work with it is via their webAPI (as are most things) until v9 is ready.
> But this still means a lot of stuff being put together outside of LC. You
> first need an Azure account setup to enable authentication. You then need
> someone conversant with c#, Visual Basic and .net to write the APIs based
> on the MS SDK. This then needs putting onto a .net server. From there it is
> really straight forward to set up a http header in LC and all of the Post
> and http calls to send and receive data.
>
> To be honest, the LC side of things is really simple, and our API guy has
> been really good at setting the whole thing up for us. We found him via
> PeoplePerHour and is clearly one of the best in his field.
>
> It’s been a long process working out how to get it all to work together so
> I’m happy I can now make it easier for members like you, saving you the
> effort of fumbling around (like we did) to find a solution.
>
> PM me if and when you need more guidance and we can set up a Skype,
> FaceTime or whatever.
>
> All the best
>
> Sean Cole
> Pi Digital
> s...@pidigital.co.uk
>
> > On 12 Oct 2017, at 12:52, Colin Kelly via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Does anyone have any working livecode scripts/libraries to use with the
> Microsoft 365 Rest API for accessing Calendar entries?
> >
> >
> >
> > Any help much appreciated.
> >
> >
> >
> > --
> >
> > Colin Kelly
> >
> >
> >
> > ___
> > 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: Microsoft 365 Rest API

[Skip Kimpel via use-livecode]

I am very interested in this functionality as well.

SKIP

On Thu, Oct 12, 2017 at 8:54 AM, Pi Digital via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I’ve been currently working on a project with another Livecoder making a
> library to work with MS Dynamics365. It turns out that the best way for LC
> to work with it is via their webAPI (as are most things) until v9 is ready.
> But this still means a lot of stuff being put together outside of LC. You
> first need an Azure account setup to enable authentication. You then need
> someone conversant with c#, Visual Basic and .net to write the APIs based
> on the MS SDK. This then needs putting onto a .net server. From there it is
> really straight forward to set up a http header in LC and all of the Post
> and http calls to send and receive data.
>
> To be honest, the LC side of things is really simple, and our API guy has
> been really good at setting the whole thing up for us. We found him via
> PeoplePerHour and is clearly one of the best in his field.
>
> It’s been a long process working out how to get it all to work together so
> I’m happy I can now make it easier for members like you, saving you the
> effort of fumbling around (like we did) to find a solution.
>
> PM me if and when you need more guidance and we can set up a Skype,
> FaceTime or whatever.
>
> All the best
>
> Sean Cole
> Pi Digital
> s...@pidigital.co.uk
>
> > On 12 Oct 2017, at 12:52, Colin Kelly via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Does anyone have any working livecode scripts/libraries to use with the
> Microsoft 365 Rest API for accessing Calendar entries?
> >
> >
> >
> > Any help much appreciated.
> >
> >
> >
> > --
> >
> > Colin Kelly
> >
> >
> >
> > ___
> > 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: Microsoft 365 Rest API

[Pi Digital via use-livecode]

I’ve been currently working on a project with another Livecoder making a 
library to work with MS Dynamics365. It turns out that the best way for LC to 
work with it is via their webAPI (as are most things) until v9 is ready. But 
this still means a lot of stuff being put together outside of LC. You first 
need an Azure account setup to enable authentication. You then need someone 
conversant with c#, Visual Basic and .net to write the APIs based on the MS 
SDK. This then needs putting onto a .net server. From there it is really 
straight forward to set up a http header in LC and all of the Post and http 
calls to send and receive data. 

To be honest, the LC side of things is really simple, and our API guy has been 
really good at setting the whole thing up for us. We found him via 
PeoplePerHour and is clearly one of the best in his field. 

It’s been a long process working out how to get it all to work together so I’m 
happy I can now make it easier for members like you, saving you the effort of 
fumbling around (like we did) to find a solution. 

PM me if and when you need more guidance and we can set up a Skype, FaceTime or 
whatever. 

All the best

Sean Cole
Pi Digital
s...@pidigital.co.uk

> On 12 Oct 2017, at 12:52, Colin Kelly via use-livecode 
>  wrote:
> 
> Does anyone have any working livecode scripts/libraries to use with the 
> Microsoft 365 Rest API for accessing Calendar entries?
> 
> 
> 
> Any help much appreciated.
> 
> 
> 
> -- 
> 
> Colin Kelly
> 
> 
> 
> ___
> 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: OAuth2 Status?

[panagiotis merakos via use-livecode]

Hi all,

I have tested using the stack from LQCC and used the credentials Greg sent
me privately. I get a sheet stack with the error:

OAuth Error: invalid_team_for_non_distributed_app

So I assume that something is wrong with these credentials.

@Ben

If you want to close the sheet stack, if no "Cancel" or "Close" btn is
present on the stack, you can do it easily like this:

1. type in the msg box (but do NOT press enter yet):

close the mousestack

2. place the cursor on the sheet stack

3. now press enter


Best,

Panos

--





On Thu, Oct 12, 2017 at 1:12 PM, Ben Rubinstein via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I downloaded your stack from LQCC, substituted my slack client id and
> secret, and port. I then got a sheet with error because the 'scope'
> parameter wasn't specified. When I specified that, I got a nice Slack login
> window... which complained that my free account was up to its limit of
> integrations! But at least the oauth stuff seemed to be working.
>
> This might be an Indy v Business thing?
>
> (One thing I've noticed is that if there are problems, you can be stuck
> with a (modal) sheet dialog, and no way to close it. By the time I got to
> the polite Slack refusal, it had the decency to offer a "go back" button
> which had the effect of closing the sheet. But when there were problems
> (the scope, and before that I'd forgotten to change the port) I was seeing
> a useful error report (from Slack) in the window, but with no way to close
> it.
>
> Fortunately I had the message box open, was able to list windows to get
> the UUID for the sheet window and close it from there. Otherwise you might
> find yourself in a force-quit situation - so proceed with care!)
>
>
>
>
> On 12/10/2017 12:21, pink via use-livecode wrote:
>
>> LC9DP9 Indy on Mac
>>
>> Right now, I've only tested in the IDE without success. I tried one Mac
>> standalone just for the heck of it (didn't work). Haven't tried iOS or any
>> other platform.
>>
>>
>> btw, submitted ticket:
>> http://quality.livecode.com/show_bug.cgi?id=20559
>> 
>>
>>
>>
>> -
>> ---
>> Greg (pink) Miller
>> mad, pink and dangerous to code
>> --
>> Sent from: http://runtime-revolution.278305.n4.nabble.com/Revolution-
>> User-f278306.html
>>
>> ___
>> 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
>



-- 
Panagiotis Merakos 
LiveCode Software Developer

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: OAuth2 Status?

[Ben Rubinstein via use-livecode]

I downloaded your stack from LQCC, substituted my slack client id and secret, 
and port. I then got a sheet with error because the 'scope' parameter wasn't 
specified. When I specified that, I got a nice Slack login window... which 
complained that my free account was up to its limit of integrations! But at 
least the oauth stuff seemed to be working.


This might be an Indy v Business thing?

(One thing I've noticed is that if there are problems, you can be stuck with a 
(modal) sheet dialog, and no way to close it. By the time I got to the polite 
Slack refusal, it had the decency to offer a "go back" button which had the 
effect of closing the sheet. But when there were problems (the scope, and 
before that I'd forgotten to change the port) I was seeing a useful error 
report (from Slack) in the window, but with no way to close it.


Fortunately I had the message box open, was able to list windows to get the 
UUID for the sheet window and close it from there. Otherwise you might find 
yourself in a force-quit situation - so proceed with care!)




On 12/10/2017 12:21, pink via use-livecode wrote:

LC9DP9 Indy on Mac

Right now, I've only tested in the IDE without success. I tried one Mac
standalone just for the heck of it (didn't work). Haven't tried iOS or any
other platform.


btw, submitted ticket:
http://quality.livecode.com/show_bug.cgi?id=20559




-
---
Greg (pink) Miller
mad, pink and dangerous to code
--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
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

Microsoft 365 Rest API

[Colin Kelly via use-livecode]

Does anyone have any working livecode scripts/libraries to use with the 
Microsoft 365 Rest API for accessing Calendar entries?

 

Any help much appreciated.

 

-- 

Colin Kelly

 

___
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: Atkinson dither algorithm & 'for each' loop

[Ben Rubinstein via use-livecode]

Hi Peter,

One note of caution regarding the use of the "repeat for each" loop, 
whilst you will get a loop iteration for every value in the collection

(fldhexa3 in your example), you are not guaranteed the order in which they
will occur.


Are you sure? My understanding has always been that chunk items, e.g.
repeat for each [ byte | char | word | item | line]  in 

will always be sequential (indeed that's why this structure is fast) - it's 
only when dealing with hashed arrays that the sequence is not reliable, i.e.

repeat for each key  in 
repeat for each element  in 

Do you have experience to the contrary?

best regards,

Ben

On 12/10/2017 12:05, Peter Reid via use-livecode wrote:

One note of caution regarding the use of the "repeat for each" loop, whilst you 
will get a loop iteration for every value in the collection (fldhexa3 in your example), 
you are not guaranteed the order in which they will occur.  This doesn't matter in a lot 
of cases but does matter when the sequence is significant.  In the case of your example I 
believe sequence is critical, otherwise the pixels might appear to be scrambled!

The following adjusted loop guarantees the sequence at the expense of speed:

   put 1 into i
   repeat for each word theWord in fldhexa3
  put word i of fldhexa3 into theWord
  put 00 & theword & theword & theword after tVar2
  add 1 to i
   end repeat

The original "improved" loop reduces the run-time to 25%.  However, the "modified 
improved" loop only manages to reduce the original run-time to 50%.

The suggested loop above takes advantage of the "for each" mechanism to produce a set of 
iterations very rapidly but gets slowed by the need to guarantee sequence. I wonder whether the LC 
engine could impose strict sequence more effectively with a variant of the "for each" 
loop such as

   repeat for each sequenced word x in theCollection
  ...
   end repeat

My own tests, comparing the speed of the 4 common repeat loops, imply that the current "for each" form is hugely faster than the 
others.  I tested "repeat for each...", "repeat while...", "repeat until...", "repeat with..." and 
a simulated "repeat for each sequenced..." forms using a simple loop body that added lines of text one after another, e.g.

   put empty into tData
   repeat with i = 1 to tMaxI
 put line i of tList & return after tData
   end repeat

I ran this test for 250,000 iterations for each type of loop, which produced 
the following timings:

   Starting test for 250,000 iterations...
   repeat for each... 0 mins 0 secs 111 millisecs
   repeat while... 0 mins 30 secs 569 millisecs
   repeat until... 0 mins 30 secs 379 millisecs
   repeat with... 0 mins 30 secs 341 millisecs
   repeat for each seq... 0 mins 30 secs 524 millisecs

As you can see, in this test the "repeat for each..." form was approx. 275 times faster than the 
other forms.  Also the simulated "repeat for each sequenced..." form was no faster than the other 
forms.  This shows how variable the speed will be with the simulated "repeat for each 
sequenced...", depending on the details of the loop body.

If there was a "repeat for each sequenced..." form of loop in LC, any speed-up 
could be very beneficial even if the amount of speed-up was only 10 times faster!

Cheers

Peter
--
Peter Reid
Loughborough, UK


On 9 Oct 2017, at 10:18am, use-livecode-requ...@lists.runrev.com wrote:

Message: 12
Date: Sat, 7 Oct 2017 15:53:44 +0200
From: Malte Pfaff-Brill 
To: use-livecode@lists.runrev.com
Subject: Re: Atkinson dither algorithm
Message-ID: <42023b36-0a4e-4251-bb0c-9cd46de55...@derbrill.de>
Content-Type: text/plain; charset=us-ascii

Hi Al,

I already posted on the forums, but for completeness also here:

a lot can be done by replacing repeat with with repeat for each where you can.

--repeat with i = 1 to the number of words of fldhexa3
   --   put 00 & word i of fldhexa3 & word i of fldhexa3 & word i of 
fldhexa3 after tVar2
   --end repeat

   repeat for each word theWord in fldhexa3
  put 00 & theword & theword & theword after tVar2
   end repeat


A sidenode:

I always use strict compile mode, therefore I added the needed variable 
declarations and noticed you use startTime as a variablename, which is a 
reserved keyword. That is not a good idea.  (I noticed, because I managed to 
freeze liveCode where I fixed only half of the use of startTime. Booom.)

Cheers,

malte



___
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: OAuth2 Status?

[pink via use-livecode]

LC9DP9 Indy on Mac

Right now, I've only tested in the IDE without success. I tried one Mac
standalone just for the heck of it (didn't work). Haven't tried iOS or any
other platform.


btw, submitted ticket:
http://quality.livecode.com/show_bug.cgi?id=20559
  



-
---
Greg (pink) Miller
mad, pink and dangerous to code
--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
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: Atkinson dither algorithm & 'for each' loop

[Peter Reid via use-livecode]

One note of caution regarding the use of the "repeat for each" loop, whilst you 
will get a loop iteration for every value in the collection (fldhexa3 in your 
example), you are not guaranteed the order in which they will occur.  This 
doesn't matter in a lot of cases but does matter when the sequence is 
significant.  In the case of your example I believe sequence is critical, 
otherwise the pixels might appear to be scrambled!

The following adjusted loop guarantees the sequence at the expense of speed:

  put 1 into i
  repeat for each word theWord in fldhexa3
 put word i of fldhexa3 into theWord
 put 00 & theword & theword & theword after tVar2
 add 1 to i
  end repeat

The original "improved" loop reduces the run-time to 25%.  However, the 
"modified improved" loop only manages to reduce the original run-time to 50%.

The suggested loop above takes advantage of the "for each" mechanism to produce 
a set of iterations very rapidly but gets slowed by the need to guarantee 
sequence. I wonder whether the LC engine could impose strict sequence more 
effectively with a variant of the "for each" loop such as

  repeat for each sequenced word x in theCollection
 ...
  end repeat

My own tests, comparing the speed of the 4 common repeat loops, imply that the 
current "for each" form is hugely faster than the others.  I tested "repeat for 
each...", "repeat while...", "repeat until...", "repeat with..." and a 
simulated "repeat for each sequenced..." forms using a simple loop body that 
added lines of text one after another, e.g.

  put empty into tData
  repeat with i = 1 to tMaxI
put line i of tList & return after tData
  end repeat

I ran this test for 250,000 iterations for each type of loop, which produced 
the following timings:

  Starting test for 250,000 iterations...
  repeat for each... 0 mins 0 secs 111 millisecs
  repeat while... 0 mins 30 secs 569 millisecs
  repeat until... 0 mins 30 secs 379 millisecs
  repeat with... 0 mins 30 secs 341 millisecs
  repeat for each seq... 0 mins 30 secs 524 millisecs

As you can see, in this test the "repeat for each..." form was approx. 275 
times faster than the other forms.  Also the simulated "repeat for each 
sequenced..." form was no faster than the other forms.  This shows how variable 
the speed will be with the simulated "repeat for each sequenced...", depending 
on the details of the loop body.

If there was a "repeat for each sequenced..." form of loop in LC, any speed-up 
could be very beneficial even if the amount of speed-up was only 10 times 
faster!

Cheers

Peter
--
Peter Reid
Loughborough, UK

> On 9 Oct 2017, at 10:18am, use-livecode-requ...@lists.runrev.com wrote:
> 
> Message: 12
> Date: Sat, 7 Oct 2017 15:53:44 +0200
> From: Malte Pfaff-Brill 
> To: use-livecode@lists.runrev.com
> Subject: Re: Atkinson dither algorithm  
> Message-ID: <42023b36-0a4e-4251-bb0c-9cd46de55...@derbrill.de>
> Content-Type: text/plain; charset=us-ascii
> 
> Hi Al,
> 
> I already posted on the forums, but for completeness also here:
> 
> a lot can be done by replacing repeat with with repeat for each where you can.
> 
> --repeat with i = 1 to the number of words of fldhexa3
>   --   put 00 & word i of fldhexa3 & word i of fldhexa3 & word i of 
> fldhexa3 after tVar2
>   --end repeat
> 
>   repeat for each word theWord in fldhexa3
>  put 00 & theword & theword & theword after tVar2
>   end repeat
> 
> 
> A sidenode:
> 
> I always use strict compile mode, therefore I added the needed variable 
> declarations and noticed you use startTime as a variablename, which is a 
> reserved keyword. That is not a good idea.  (I noticed, because I managed to 
> freeze liveCode where I fixed only half of the use of startTime. Booom.)
> 
> Cheers,
> 
> malte


___
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: OAuth2 Status?

[Ben Rubinstein via use-livecode]

Hi Greg,

What platform are you doing this on? I've found Oauth2 in LC9dp9 (Business) is 
working okay for me with both Dropbox and Slack - on Mac.


On iOS however I've had no luck. I'd be interested to hear if anyone has got 
it working on iOS or Android.


Ben


On 09/10/2017 18:58, pink via use-livecode wrote:

Does OAuth2 currently work?  I’m using LC 9 Indy DP9, I tried 3 different
APIs (Toodledo, Todoist, and Slack)

In all 3 cases, an empty window pops up briefly and then closes.

For Slack, I literally copied the example from the dictionary and
substituted my app’s values.

Has anyone been able to use it yet?



-
---
Greg (pink) Miller
mad, pink and dangerous to code
--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
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