On 08/10/2018 05:36 PM, Geoff Canyon via use-livecode wrote:
Are you working with "LiveCode UI elements appear in lists of stacks"
enabled? I specifically named all the script behaviors for Navigator
starting with "rev" and they don't show up in the Project Browser for me.
Exactly. And It's
Or the ui stack is a substack which gets duplicated as another substack under
the same root, but empty, mainstack...
Mark.
Sent from my iPhone
> On 10 Aug 2018, at 19:48, Brian Milby via use-livecode
> wrote:
>
> In your case it may be a bit more complicated, but I would think still
>
In your case it may be a bit more complicated, but I would think still
attainable. The key would be for the scripts to live in a sub stack that
didn't get duplicated.
On Fri, Aug 10, 2018 at 7:41 PM, Geoff Canyon via use-livecode <
use-livecode@lists.runrev.com> wrote:
> On Sat, Aug 4, 2018 at
I do it both ways, the problem is that behavior scripts created for
maintaining a stack (version control) are inconvenient in the IDE. I've
thought about suggesting a multiple step scriptify for IDE tools. The
first step would be to create a card to house all behavior buttons. The
first round
On Sat, Aug 4, 2018 at 12:00 PM Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:
> Plugins should probably be de-scriptified for distribution for this
> reason.
>
This would be very bad for Navigator. Navigator shows multiple copies of
itself (as many as you like/can
Are you working with "LiveCode UI elements appear in lists of stacks"
enabled? I specifically named all the script behaviors for Navigator
starting with "rev" and they don't show up in the Project Browser for me.
Not that I had looked before this, I use Navigator for everything. ;-)
On Sat, Aug
On 08/08/2018 04:16 PM, Mark Waddingham via use-livecode wrote:
OK. Bug filed.
https://quality.livecode.com/show_bug.cgi?id=21476
--
Mark Wieder
ahsoftw...@gmail.com
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url
On 2018-08-08 23:19, Mark Wieder via use-livecode wrote:
On 08/08/2018 10:54 AM, Mark Waddingham via use-livecode wrote:
Yup - but isSequence would be correct - false.
The extents might be 1,10
But isSequence would check whether it was 1,9 ...
Ah. OK, but I was actually replying to Dick
On 08/08/2018 10:54 AM, Mark Waddingham via use-livecode wrote:
Yup - but isSequence would be correct - false.
The extents might be 1,10
But isSequence would check whether it was 1,9 ...
Ah. OK, but I was actually replying to Dick Kriesel's isSequence
function, which incorrectly would reply
Yup - but isSequence would be correct - false.
The extents might be 1,10
But isSequence would check whether it was 1,9 ...
Mark.
Sent from my iPhone
> On 8 Aug 2018, at 12:19, Mark Wieder via use-livecode
> wrote:
>
> On 08/08/2018 04:18 AM, Mark Waddingham via use-livecode wrote:
>
>>>
On 08/08/2018 04:18 AM, Mark Waddingham via use-livecode wrote:
"the extents" implements those rules, so "isSequence" doesn’t need to.
Or is there evidence "isSequence" fails?
on test
local i
repeat with i=1 to 10
put "true" into sArray[i]
end repeat
put "false" into
I'd suggest transplant is actually move - an idea which has been taken to the
level of obsession in modern c++ and new languages like Rust (which I want to
like - but it's highly technical demands just leave a bitter taste in my mouth
- impressive, yes; the right approach - definitely not, IMHO
I think you are right - I will double check.
There is actually an internal function (in C) - two in fact - IsSequence and
IsNumericSequence which we should plumb into 'is a' to make this clearer.
They basically use the extents internal impl (well an optimized form in one
case).
Warmest
> On 8 Aug 2018, at 7:52 pm, Monte Goulding via use-livecode
> wrote:
>
> map lines of tList as sum(item 2 to -1 of each) \
>grouping by item 1 of each \
>where item 1 of each begins with “b” into tArray
>
> Would create the array:
>
> “bar” -> 10, “baz” -> 24
Typo ^ sorry
So the difference between transplant and filter is that transplant mutates both
source and target by taking from source and adding to target while filter
copies from source to target? Oh and that transplant would mutate an existing
target rather than clobbering any existing value.
Hate the
> On Aug 7, 2018, at 9:29 PM, Jerry Jensen via use-livecode
> wrote:
>
>> On Aug 7, 2018, at 8:35 PM, Mark Wieder via use-livecode
>> wrote:
>>
>> On 08/07/2018 07:57 PM, Dick Kriesel via use-livecode wrote:
>>> On Aug 7, 2018, at 5:47 PM, Alex Tweedly via use-livecode
>>> wrote:
> On Aug 7, 2018, at 8:35 PM, Mark Wieder via use-livecode
> wrote:
>
> On 08/07/2018 07:57 PM, Dick Kriesel via use-livecode wrote:
>> On Aug 7, 2018, at 5:47 PM, Alex Tweedly via use-livecode
>> wrote:
>>>
>>> Is there an easy way to test whether an array is (currently) a sequence
>>>
On 08/07/2018 07:57 PM, Dick Kriesel via use-livecode wrote:
On Aug 7, 2018, at 5:47 PM, Alex Tweedly via use-livecode
wrote:
Is there an easy way to test whether an array is (currently) a sequence array ?
something easier than
put the extents of tArray into tmp
if item 1 of tmp =
On Aug 7, 2018, at 5:47 PM, Alex Tweedly via use-livecode
wrote:
>
> Is there an easy way to test whether an array is (currently) a sequence array
> ?
>
> something easier than
> put the extents of tArray into tmp
> if item 1 of tmp = 1 AND item 2 of tmp = the number of elements in
On 07/08/2018 23:45, Mark Waddingham via use-livecode wrote:
On 2018-08-07 23:31, Mark Wieder via use-livecode wrote:
does that take it out of the 'special' category?
Yes - unless the array's first key is 1, and it then has all integer
keys up to and including its number of elements then it
On 2018-08-08 00:20, Bob Sneidar via use-livecode wrote:
I do stand corrected however, as I got the dgdata of a grid with 6
records, in the order they were added to the sql database, and then
queried for. The keys are NOT in numerical order:
5
6
1
2
3
4
The keys function does the minimal work
On 2018-08-07 23:31, Mark Wieder via use-livecode wrote:
On 08/07/2018 02:21 PM, Mark Waddingham via use-livecode wrote:
However, the engine treats arrays which have all integer (string) keys
starting at one and are dense (i.e. the number of elements == max(all
keys)) from ones that aren't.
Suggestion for the language-token for this function: "transplant".
transplant [qualification] from [SourceArray] to [TargetArray]
[qualification] is a pattern/expression which describes exactly which bits you
want to move from SourceArray to TargetArray.
If TargetArray doesn't exist, it should
Bob Sneidar wrote:
> You can as I understand get the keys of an array, which returns a
> string, then sort the string. I am unaware of any function that can
> sort an array natively before it is returned.
The array itself is a collection of pointers, grouped into buckets
according to a hash
I do stand corrected however, as I got the dgdata of a grid with 6 records, in
the order they were added to the sql database, and then queried for. The keys
are NOT in numerical order:
5
6
1
2
3
4
I have never wrapped my head around why that is!
Bob S
> On Aug 7, 2018, at 15:12 , Bob
You can as I understand get the keys of an array, which returns a string, then
sort the string. I am unaware of any function that can sort an array natively
before it is returned.
Bob S
> On Aug 7, 2018, at 15:02 , Richard Gaskin via use-livecode
> wrote:
>
> Bob Sneidar wrote:
>
> >
Bob Sneidar wrote:
> Someone said, probably Mark, that numbered key arrays beginning with 1
> will always return their keys sorted numerically. I always wondered
> why almost every other array seemed to scramble to order of it's keys,
> but datagrid arrays never did.
Associative arrays are a
Someone said, probably Mark, that numbered key arrays beginning with 1 will
always return their keys sorted numerically. I always wondered why almost every
other array seemed to scramble to order of it's keys, but datagrid arrays never
did.
Bob S
> On Aug 7, 2018, at 14:31 , Mark Wieder via
On 08/07/2018 02:21 PM, Mark Waddingham via use-livecode wrote:
However, the engine treats arrays which have all integer (string) keys
starting at one and are dense (i.e. the number of elements == max(all
keys)) from ones that aren't.
Not sure how to interpret that. If I create
repeat with
On 2018-08-07 17:15, Mark Wieder via use-livecode wrote:
On 08/06/2018 08:18 PM, Mark Waddingham via use-livecode wrote:
I'd expect that for two reasons.
The first is that all array keys are interred strings (names) so
integers need to first be converted to strings and then hashed into a
On 08/06/2018 08:58 PM, Brian Milby via use-livecode wrote:
I've uploaded a stack with each version of the function. The last has some
comments added as well. Mark's version is pretty close to the original,
but did not return an ordered list (which is an implicit requirement). I
added a sort
On 08/06/2018 08:18 PM, Mark Waddingham via use-livecode wrote:
I'd expect that for two reasons.
The first is that all array keys are interred strings (names) so integers need
to first be converted to strings and then hashed into a name and then hashed to
the slot in the arrays hash table.
button "Array (original)"
Found 664579 primes in 51.543966 seconds
button "Array (bwm)"
Found 664579 primes in 49.139622 seconds
button "Array (mark)"
Found 664579 primes in 43.483821 seconds
button "Byte (alex)"
Found 664579 primes in 15.016109 seconds
button "Byte (bwm)"
Found 664579 primes in
I'd expect that for two reasons.
The first is that all array keys are interred strings (names) so integers need
to first be converted to strings and then hashed into a name and then hashed to
the slot in the arrays hash table.
The second is that byte based version is essentially using a byte
Interesting. I tried a variation using arrays, and it's three times
slower than yours.
function get_primes pN
local tMroot, tPrimes, tIsItPrime
if pN < 2 then return empty
if pN = 2 then return 2
put trunc(sqrt(pN)) - 1 into tMroot
repeat with i=1 to pN step 2
put 1 into
How embarrassing, again an error. I should go to sleep now.
repeat pn mod 1
put tYes after tIsItPrime <-- corrected line
end repeat
Here is the hopfully truly truly last correction.
---
function get_primes pN -- bn modified brian
local tMroot, tPrimes,
Nice improvement !
And I like the variable names much more ... though it could be argued
that "tYes", should be called"tMayYetBeAPrime" :-)
I now get this version consistently running in 25% of the original time.
There is another version which runs about twice as fast - i.e. 14% of
the
There was an error in the code I posted.
It should read "if pN >= 1 then" instead of "if pN > 1"
this is the corrected version
-
function get_primes pN
local tMroot, tPrimes, tIsItPrime, tYes, tNo
put numtobyte(66) into tYes
put numtobyte(65) into tNo
if pN < 2
2 should be included, but the original optimized version skipped it.
Thanks,
Brian
On Aug 6, 2018, 6:25 PM -0500, Niggemann, Bernd via use-livecode
, wrote:
> This also helps a bit. Where is Hermann?
>
> -
> function get_primes pN
> local tMroot, tPrimes, tIsItPrime, tYes,
This also helps a bit. Where is Hermann?
-
function get_primes pN
local tMroot, tPrimes, tIsItPrime, tYes, tNo
put numtobyte(66) into tYes
put numtobyte(65) into tNo
if pN < 2 then return empty
if pN = 2 then return 2
put 2 into tPrimes
put trunc(sqrt(pN))
Ah, that is what I was missing (numtobyte)... I knew that 4000 seconds
wasn't right :)
I was able to shave a bit more off by only calling numtobyte twice (17s to
12s for single pass):
function get_primes pN
local tMroot, tPrimes, tIsItPrime, tYes, tNo
put numtobyte(66) into tYes
put
On 2018-08-06 22:04, Alex Tweedly via use-livecode wrote:
On 06/08/2018 16:50, Mark Waddingham via use-livecode wrote:
Alex Tweedly didn't talk nonsense... Byte x [to y] of z is (truly)
constant time if z is strictly a binary string.
That's right - the basic principle wasn't nonsense - but
On 06/08/2018 16:50, Mark Waddingham via use-livecode wrote:
Alex Tweedly didn't talk nonsense... Byte x [to y] of z is (truly) constant
time if z is strictly a binary string.
That's right - the basic principle wasn't nonsense - but most everything
else in my email was :-)
I said you only
On 08/05/2018 08:26 PM, Monte Goulding via use-livecode wrote:
They are constants.. the point is in order to compare a boolean to a string you
need to convert it to a string and therefore you do string comparison on “” v
“false”.
Doh! Yes, I forgot again about this converting everything to
Alex Tweedly didn't talk nonsense... Byte x [to y] of z is (truly) constant
time if z is strictly a binary string.
tArray[x] is constant time if x is already a name - otherwise the string needs
turned into a name.
If x is coming from repeat for each key x - then it will already be a name.
Earlier, Alex Tweedly said some nonsense like:
arrays are hashed - even if quickly, while byte chunks are constant time.
So replace both uses of the array np with a byte chunk.
...
Takes about 40% off the time.
-- Alex.
Operator error !
Forget what I said, it was wrong.
I'll do the test
arrays are hashed - even if quickly, while byte chunks are constant time.
So replace both uses of the array np with a byte chunk.
i.e.
if byte i of np = "n" then next repeat
...
put "n" into byte j of np
Takes about 40% off the time.
-- Alex.
On 06/08/2018 03:36, Richard Gaskin via
> On 6 Aug 2018, at 1:57 pm, Brian Milby via use-livecode
> wrote:
>
> Just tried that and it adds .7 sec (returning the unsorted keys). The sort
> in the original takes around .7s. There are only 446 primes found at that
> point. Returning an array is about the same time as returning an
Just tried that and it adds .7 sec (returning the unsorted keys). The sort
in the original takes around .7s. There are only 446 primes found at that
point. Returning an array is about the same time as returning an unsorted
R.
On Sun, Aug 5, 2018 at 10:28 PM, Monte Goulding via use-livecode <
I’m fairly sure you could speed it up by continuing to add keys to p and
returning that instead of building the list R.
> On 6 Aug 2018, at 1:24 pm, Brian Milby via use-livecode
> wrote:
>
> I can speed it up by 10% just be replacing the "add 1 to" with "put true
> into". The first if would
> On 6 Aug 2018, at 1:15 pm, Mark Wieder via use-livecode
> wrote:
>
> Interesting. And here I was just assuming that true and false were boolean
> constants, like in any other language. So empty is a constant and one is a
> constant, but true and false are not. Wouldn't things be faster if
I can speed it up by 10% just be replacing the "add 1 to" with "put true
into". The first if would lose the ">0". A single pass went from 50s to
44s on my iMac.
On Sun, Aug 5, 2018 at 9:36 PM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:
> Mark Waddingham wrote:
>
>
On 08/05/2018 05:42 PM, Monte Goulding via use-livecode wrote:
I was describing a situation where you are forcing something that is not a boolean
to be one so true is true and everything else is false. You are describing comparing
something to a boolean in which case rightly or wrongly both
I posted a stack with the valueDiff code tests that I was doing if anyone
is interrested:
https://milby.us/lc/ValueDiff.livecode.zip
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage
Mark Waddingham wrote:
> On 2018-08-05 21:22, Richard Gaskin via use-livecode wrote:
>> Mark Waddingham wrote:
>>
>>> In your use-case for 'valueDiff' - do you need to tell the
>>> difference between a key value being the empty string and
>>> a key value not being present at all?
>>
>> In my own
Mark Waddingham wrote:
> Richard wrote:
>>
>> Thinking about performance, I wonder if there's anything from some of
>> the changes that have boosted PHP 7's performance so far above its
>> earlier versions which may be relevant for LC:
>>
> On 6 Aug 2018, at 9:55 am, Mark Wieder via use-livecode
> wrote:
>
> on something p1, p2, p3
> if p1 is false then
>-- fails if p1 is empty
> end if
> if p1 is true then
>-- also fails if p1 is empty
> end if
> end something
I was describing a situation where you are forcing
On 08/05/2018 04:37 PM, Monte Goulding via use-livecode wrote:
Actually you need to be careful to remember not to put not before a boolean
expression without putting parenthesis around the expression because anything
that is not “true” in LC evaluates to false. For example:
That's generally
> On 6 Aug 2018, at 8:03 am, Mark Wieder via use-livecode
> wrote:
>
> True, but syntacticly I like the idea of being able to place "not" in front
> of any boolean without having to remember where it's legal and where it's
> not. I also think it's harder on the engine (this off the top of
Earlier in this thread it was mentioned that LCS doing a loop once would
probably outpace the engine looping 2 times + a LCS loop at some point. I
decided to see if I could figure out a point where this might take place.
My test was pretty simple. I set a target number of elements for each
On 2018-08-06 00:07, Brian Milby via use-livecode wrote:
So this syntax:
filter filterSource by [keeping | discarding] [[the] {lines | items |
keys
| elements}] {matching [wildcard | regex] pattern filterPattern | where
filterExpression} [into targetContainer]
Would allow a shortened version:
On 2018-08-06 00:03, Mark Wieder via use-livecode wrote:
On 08/05/2018 02:48 PM, Monte Goulding via use-livecode wrote:
On 6 Aug 2018, at 7:07 am, Mark Waddingham via use-livecode
wrote:
filter X by keeping the lines not matching pattern "regex"
My point was this statement can be
On 8/5/18 4:07 PM, Mark Waddingham via use-livecode wrote:
But this isn't cooking - this is coding, so in this case you need to
read the docs to find out what the default mode of filter is. (Of
course, this might entirely be one of those things that my brain just
won't get, or ever get - so it
So this syntax:
filter filterSource by [keeping | discarding] [[the] {lines | items | keys
| elements}] {matching [wildcard | regex] pattern filterPattern | where
filterExpression} [into targetContainer]
Would allow a shortened version:
filter X by matching pattern "regex" into Z
Which would
On 08/05/2018 02:48 PM, Monte Goulding via use-livecode wrote:
On 6 Aug 2018, at 7:07 am, Mark Waddingham via use-livecode
wrote:
filter X by keeping the lines not matching pattern "regex"
My point was this statement can be written as both:
filter X by keeping the lines not matching
On 2018-08-05 23:48, Monte Goulding via use-livecode wrote:
On 6 Aug 2018, at 7:07 am, Mark Waddingham via use-livecode
wrote:
filter X by keeping the lines not matching pattern "regex"
My point was this statement can be written as both:
filter X by keeping the lines not matching pattern
> On 6 Aug 2018, at 7:07 am, Mark Waddingham via use-livecode
> wrote:
>
> filter X by keeping the lines not matching pattern "regex"
My point was this statement can be written as both:
filter X by keeping the lines not matching pattern “regex"
and
filter X by discarding the lines
On 2018-08-05 22:37, Monte Goulding via use-livecode wrote:
I think it’s nice sugar but it adds complexity when trying to
understand the statement. You need to comprehend the expression or
pattern then comprehend the relationship between discarding/keeping
and with | without | not matching |
> On 6 Aug 2018, at 12:38 am, Mark Waddingham via use-livecode
> wrote:
>
> keeping where P -> P
> keeping with P -> each matches wildcard P
> keeping without P -> not (each matches wildcard P)
> keeping matching P -> each matches pattern P
> keeping not matching P -> not (each matches
> On 5 Aug 2018, at 10:32 pm, Mark Waddingham via use-livecode
> wrote:
>
> Geez @Monte - you do like creating work for me don't you! ;)
Aha.. sorry but I have been threatening to implement this for 2 years ;-)
Cheers
Monte
___
use-livecode
Intersect is an engine implementation of something that can be done in pure
LCS. I wrote a version of the function you needed that only used LCS without
the engine optimized functions. My function only iterates over an array once
(instead of 3 times) yet takes twice as long. It deletes keys
On 2018-08-05 21:25, Richard Gaskin via use-livecode wrote:
Brian Milby wrote:
I think Mark's code had a typo (left returned too many keys), but even
when corrected it takes half the time as a pure LCS solution. Here's
my modification:
function bwmValueDiff pLeft, pRight
local tResult
On 2018-08-05 21:22, Richard Gaskin via use-livecode wrote:
Mark Waddingham wrote:
In your use-case for 'valueDiff' - do you need to tell the difference
between a key value being the empty string and a key value not being
present at all?
In my own head, any name-value pair, even one in which
Brian Milby wrote:
> I think Mark's code had a typo (left returned too many keys), but even
> when corrected it takes half the time as a pure LCS solution. Here's
> my modification:
>
> function bwmValueDiff pLeft, pRight
>local tResult
>intersect pLeft with pRight into tResult["1"]
>
Mark Waddingham wrote:
> In your use-case for 'valueDiff' - do you need to tell the difference
> between a key value being the empty string and a key value not being
> present at all?
In my own head, any name-value pair, even one in which the value is an
empty string, is worth taking into
It's just a case of refactoring but some further thought is required even about
the current filter improvement.
By creating a revised form of filter, for example, we have the option of making
'matches' take an RE and not a glob (shell wildcard expr). Yes REs are more
complicated but much more
On 08/05/2018 11:20 AM, Mark Waddingham via use-livecode wrote:
That isn't overloading put - that's introducing query expressions...
Which would (at least as far as filter currently goes - I have another as yet
unstated reason for suggesting a revised syntax beyond stopping my own mental
That isn't overloading put - that's introducing query expressions...
Which would (at least as far as filter currently goes - I have another as yet
unstated reason for suggesting a revised syntax beyond stopping my own mental
torture!) eliminate the need for filter into.
e.g
the lines of X
On 08/05/2018 07:38 AM, Mark Waddingham via use-livecode wrote:
keep lines of X [ where | matching | not matching ] Y into Z -- seems
contorted
That seems like a good argument for overloading the already-overworked
'put' command:
put lines of X [ where | matching | not matching ] Y into Z
I think "filter" is culinary enough. Coffee filters do the same thing, only
they filter without. :)
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On August 5, 2018 11:53:11 AM Mark Waddingham via use-livecode
wrote:
Well...
strain
Yes, yours is natural. Some of the others were stretching it a bit.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On August 5, 2018 11:10:47 AM Mark Waddingham via use-livecode
wrote:
On 2018-08-05 17:36, J. Landman Gay via
Well...
strain X through Y
Does kind of work - although it still doesn't explicitly relate what is to be
kept (which is implicit in context in a recipe) and that's the deficiency in
the current syntax.
We can make all parts optional in the new proposed form which would mean you
can still
Maybe 'strain' could be a culinary synonym?
;-)
Best wishes
David Glasgow
Sent from my iPad via iBrain & iFingers
LinkedIn
> On 5 Aug 2018, at 16:36, J. Landman Gay via use-livecode
> wrote:
>
> This is getting pretty contorted and is becoming less like natural language.
> For what it's
On 2018-08-05 17:36, J. Landman Gay via use-livecode wrote:
This is getting pretty contorted and is becoming less like natural
language. For what it's worth, I have never been confused by the
current use of filter. I think of it as pouring soup through a wire
strainer. Filtering "with" keeps the
This is getting pretty contorted and is becoming less like natural
language. For what it's worth, I have never been confused by the current
use of filter. I think of it as pouring soup through a wire strainer.
Filtering "with" keeps the solids. Filtering "without" dumps them and keeps
the
I like A. Here is my take on the actual dictionary syntax:
filter filterSource by {keeping | discarding} [{lines | items | keys |
elements}] {{with | without | [not] matching} {[{wildcard | regex} pattern]
filterPattern | where filterExpression} [into targetContainer]
Not sure about leaving
On 2018-08-05 16:00, Brian Milby wrote:
Or to include new modifiers:
{keeping | discarding | with | without | [not] matching}
Which if not using the “into” form the first two make the
statement much clearer as to the intent.
So, I figured out my 'cognitive dissonance' on filter. The issue
Probably better:
filter [{lines | items | keys | elements} of] filterSource {keeping |
discarding | with | without | [not] matching} {[{wildcard | regex} pattern]
filterPattern | where filterExpression} [into targetContainer]
So Monte’s example would be:
filter keys of tFoo keeping where
Or to include new modifiers:
{keeping | discarding | with | without | [not] matching}
Which if not using the “into” form the first two make the statement much
clearer as to the intent.
Thanks,
Brian
___
use-livecode mailing list
Current
filter [{lines | items | keys | elements} of] filterSource {with | without |
[not] matching} [{wildcard pattern | regex pattern}] filterPattern [into
targetContainer]
Possible Suggestion
filter [{lines | items | keys | elements} of] filterSource {{with | without |
[not] matching}
On 2018-08-05 07:31, Monte Goulding via use-livecode wrote:
Given I have been wanting to do ^ for a couple of years I decided to
just go ahead and do it… might be a while before we have time to
bikeshed the syntax though.
https://github.com/livecode/livecode/pull/6626
On 2018-08-05 03:59, Monte Goulding via use-livecode wrote:
Just to throw it out there I still want to add `each` to filter one
day. So in this case I think it would be:
filter keys of tArray1 with expression \
each is among the keys of tArray2 and \
tArray1[each] is not
> On 5 Aug 2018, at 11:59 am, Monte Goulding via use-livecode
> wrote:
>
> Just to throw it out there I still want to add `each` to filter one day. So
> in this case I think it would be:
>
> filter keys of tArray1 with expression \
> each is among the keys of tArray2 and \
>
I have not been able to locate the earlier conversation on pass by
reference vice value. I did a quick test and it took 100,000 loops to be
able to get a difference that was obvious. My test was to construct simple
functions that took 1 to 3 parameters. 3 functions used all pass by value,
3
On 08/04/2018 12:20 PM, J. Landman Gay via use-livecode wrote:
On 8/4/18 12:41 PM, Mark Waddingham via use-livecode wrote:
Can you immediately see the error?
Who, me? LOL. Well, I did find the line that was different. Brian and
others who can read this stuff did better. But I did get the
On 08/04/2018 07:11 PM, Brian Milby via use-livecode wrote:
I think Mark's code had a typo (left returned too many keys), but even when
corrected it takes half the time as a pure LCS solution. Here's my
modification:
Quite right. Good catch.
--
Mark Wieder
ahsoftw...@gmail.com
I think Mark's code had a typo (left returned too many keys), but even when
corrected it takes half the time as a pure LCS solution. Here's my
modification:
function bwmValueDiff pLeft, pRight
local tResult
intersect pLeft with pRight into tResult["1"]
repeat for each key tKey in
On 08/04/2018 04:45 PM, Mark Waddingham via use-livecode wrote:
The other place this could come to bear is making the S/B (or some
variant there-of) not only work to produce an application, but also a
'component/extension' - i.e. a distributable 'compiled' (in some sense)
form of a collection
Just to throw it out there I still want to add `each` to filter one day. So in
this case I think it would be:
filter keys of tArray1 with expression \
each is among the keys of tArray2 and \
tArray1[each] is not tArray2[each]
> On 5 Aug 2018, at 11:23 am, Brian Milby via
Here is code that only uses LCS to accomplish the goal (only returning the
keys where they exist in both arrays but the values are different). This
is made to be similar to the way the existing functions work (with the
option to mutate).
command valueDiff @pDestinationA, @pLeftA, pRightA
1 - 100 of 139 matches
Mail list logo
