Re: Getting Started with DataGrid and another datagrid form

[Sannyasin Brahmanathaswami via use-livecode]

Duh!

http://lessons.livecode.com/m/datagrid/l/7305-example-creating-a-list-of-people

on LayoutControl does seem to be required.

So the row template is not WSIWYG?

Sannyasin Brahmanathaswami via use-livecode wrote:
> Doug
>
>WSIWYG:  I was referring to the row temple "build" screen.
>
> ... layout handler. I want to understand it...
>
> maybe studying the on-line lessons *before* asking questions
>
> Someone should do a graphic or schema diagram of the DG message hierarchy.
>
> BR


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

Re: valueDiff for arrays?

[Monte Goulding via use-livecode]

> 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 unsorted
> R.

Hmm… could be the overhead of hashing the array keys. Would be interesting to 
see the results of just incrementing a counter rather than listing the primes.

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: valueDiff for arrays?

[Brian Milby via use-livecode]

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 <
use-livecode@lists.runrev.com> wrote:

> 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 <
> use-livecode@lists.runrev.com> wrote:
> >
> > 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.
>
> ___
> 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: Getting Started with DataGrid and another datagrid form

[Sannyasin Brahmanathaswami via use-livecode]

Doug

   WSIWYG:  I was referring to the row temple "build" screen.

... layout handler. I want to understand it...

maybe studying the on-line lessons *before* asking questions

Someone should do a graphic or schema diagram of the DG message hierarchy.

BR



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

Re: Getting Started with DataGrid and another datagrid form

[Sannyasin Brahmanathaswami via use-livecode]

Aloha zryip

I finally figured out that a row has the behavior script that "requires 
attention"

I have yet to try in dghelper.

FillInData etc. obviously need controls named according to your grid

But I still have the question:

The WSIWYG template has the control "where we want them"

But is the LayOutControl handler doing? Is it needed?

Oh by the way. you need to have a button that

set the relayerGroupedControls to true

In the form builder, otherwise you can't push an object "back"




On 8/5/18 7:26 AM, zryip theSlug via use-livecode wrote:

The code you have in the default behavior is the one installed by the
inspector located in one of the behavior button (stack only script now,
since the dg2)

It contains the minimal example code to help the developer starting;
FillinData, preFillinData, LayoutControl, etc

If you are modifying the template for the datagrid (adding a control,
deleting a control, etc) you have to change the code for your datagrid row
manually.








___
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: Start using stack - Loading stack libraries

[Stephen MacLean via use-livecode]

Hi Paul and Monte,

Thanks for the input!

@ Monte, I might be able to order the initial query so that they are grouped 
together by builder type. Then I could process those together with doing one 
load and unload for that group

@ Paul, they are different, based upon the type of build that needs to happen 
for the source that is being looked at. The code has one handler name that is 
the same (The init code in the builder), but after that the code is different.

All input welcome:)

Thanks,

Steve

> On Aug 5, 2018, at 9:21 PM, Paul Dupuis via use-livecode 
>  wrote:
> 
> On 8/5/2018 8:51 PM, Stephen MacLean via use-livecode wrote:
>> Any insight is appreciated!
>> 
> 
> I use a lot of library stacks, but our model is to load them on startup
> and unload on shutdown (not really necessary singe the engine does this
> on quit). Unless you have zillions of lines of code, I am not sure what
> the value is of unloading and reloading the same library?
> 
> ___
> 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: valueDiff for arrays?

[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 lose the ">0".  A single pass went from 50s to
> 44s on my iMac.

___
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: valueDiff for arrays?

[Monte Goulding via use-livecode]

> 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 we made 
> them constants?

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

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: valueDiff for arrays?

[Brian Milby via use-livecode]

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:
>
> > 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:
> >> https://www.reddit.com/r/PHP/comments/3q2brz/how_is_php_7_tw
> ice_as_fast/
> >
> > I'd actually be really interested in a direct speed comparison between
> > exactly equivalent operations in PHP7 and LC.
>
> Geoff Canyon and I corresponded on this back in March.  I don't think
> he'll mind me sharing some of the relevant parts of his test:
>
> ---  from GC 
>
> on mouseUp
>put the long seconds into T
>repeat with c = 1 to 10
>   get get_primes(1000)
>end repeat
>put "Found" && the number of lines in it && "primes in" && the long
> seconds - T && "seconds"
> end mouseUp
>
> function get_primes n
>if n < 2 then return empty
>if n = 2 then return 2
>put trunc(sqrt(n)) - 1 into mroot
>repeat with i = 3 to mroot step 2
>   if np[i] > 0 then next repeat
>   add 1 to p[i]
>   repeat with j = i^2 to n step i
>  add 1 to np[j]
>   end repeat
>end repeat
>put 2 & cr & the keys of p into R
>sort lines of R numeric
>repeat with i = mroot + (mroot + 1) mod 2 to n - 1 step 2
>   if np[i] is empty then put cr & i after R
>end repeat
>return R
> end get_primes
>
> And that takes about fifteen minutes to run on my 2013 MacBook Pro, where
> the slowest performer he's working with takes less than 30 seconds, and PHP
> 7 runs in under 7 seconds. Any ideas where I'm deviating in my
> implementation compared to his? Here's the latest version of his test that
> I found:
>
> https://blog.famzah.net/2016/09/10/cpp-vs-python-vs-php-vs-j
> ava-vs-others-performance-benchmark-2016-q3/
>
> -
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Wieder via use-livecode]

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 sides are converted to 
strings so you end up comparing “” to “false"


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 we made them constants?


--
 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: valueDiff for arrays?

[Brian Milby via use-livecode]

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 your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Richard Gaskin via use-livecode]

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 head, any name-value pair, even one in which the value
>> is an empty string, is worth taking into account.
>
> In the general case it depends on what data you are modelling with an
> array.
>
> If an array key-value is modelling a field which is not optional, then
> there is no need to distinguish between an array key being there, and
> one not being there - i.e. all field accesses can be tRecord[tKey],
> and your key value can be empty.
>
> If a field's value has to be non-empty to be valid, then you can test
> for existence of a field by doing tRecord[tKey] is not empty. So,
> again, presence or not presence of an array key is immaterial.

Consider an array of object properties. There, a label or name property 
can be empty, and it's useful to know that.


In most of my own work, if a key is present it's meaningful, even if its 
value is empty.


If a key is not meaningful it probably isn't in an array I'm using.

--
 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: valueDiff for arrays?

[Richard Gaskin via use-livecode]

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:
>> https://www.reddit.com/r/PHP/comments/3q2brz/how_is_php_7_twice_as_fast/
>
> I'd actually be really interested in a direct speed comparison between
> exactly equivalent operations in PHP7 and LC.

Geoff Canyon and I corresponded on this back in March.  I don't think 
he'll mind me sharing some of the relevant parts of his test:


---  from GC 

on mouseUp
   put the long seconds into T
   repeat with c = 1 to 10
  get get_primes(1000)
   end repeat
   put "Found" && the number of lines in it && "primes in" && the long 
seconds - T && "seconds"

end mouseUp

function get_primes n
   if n < 2 then return empty
   if n = 2 then return 2
   put trunc(sqrt(n)) - 1 into mroot
   repeat with i = 3 to mroot step 2
  if np[i] > 0 then next repeat
  add 1 to p[i]
  repeat with j = i^2 to n step i
 add 1 to np[j]
  end repeat
   end repeat
   put 2 & cr & the keys of p into R
   sort lines of R numeric
   repeat with i = mroot + (mroot + 1) mod 2 to n - 1 step 2
  if np[i] is empty then put cr & i after R
   end repeat
   return R
end get_primes

And that takes about fifteen minutes to run on my 2013 MacBook Pro, 
where the slowest performer he's working with takes less than 30 
seconds, and PHP 7 runs in under 7 seconds. Any ideas where I'm 
deviating in my implementation compared to his? Here's the latest 
version of his test that I found:


https://blog.famzah.net/2016/09/10/cpp-vs-python-vs-php-vs-java-vs-others-performance-benchmark-2016-q3/

-

--
 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: Start using stack - Loading stack libraries

[Paul Dupuis via use-livecode]

On 8/5/2018 8:51 PM, Stephen MacLean via use-livecode wrote:
> Any insight is appreciated!
>

I use a lot of library stacks, but our model is to load them on startup
and unload on shutdown (not really necessary singe the engine does this
on quit). Unless you have zillions of lines of code, I am not sure what
the value is of unloading and reloading the same library?

___
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: Start using stack - Loading stack libraries

[Monte Goulding via use-livecode]

My main thought is if we are talking about loading and unloading thousands of 
times then script parsing may become costly. How costly I’m not sure… script 
parsing is pretty fast.

> On 6 Aug 2018, at 10:51 am, Stephen MacLean via use-livecode 
>  wrote:
> 
> Hi All,
> 
> I am currently using library stacks that contain what I call custom builders, 
> that are livecode script libraries. These stacks have code for specific 
> instances and when done, I currently unload them. I like that I can use 
> these, and build them, on the fly, bringing that code in without having to 
> “disturb” the main app.
> 
> As I’m about to start loading and unloading them hundreds if not thousands of 
> times, and very rapidly, I started thinking about how this would effect 
> performance, memory issues, etc.
> 
> Does anyone have experience doing this and doing it rapidly? Anyone come 
> across any memory issues, leakage, etc.? Anything else I should look for in 
> doing this? Different ways to accomplish the same thing?
> 
> Any insight is appreciated!
> 
> Thanks,
> 
> Steve MacLean
> 
> ___
> 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

Start using stack - Loading stack libraries

[Stephen MacLean via use-livecode]

Hi All,

I am currently using library stacks that contain what I call custom builders, 
that are livecode script libraries. These stacks have code for specific 
instances and when done, I currently unload them. I like that I can use these, 
and build them, on the fly, bringing that code in without having to “disturb” 
the main app.

As I’m about to start loading and unloading them hundreds if not thousands of 
times, and very rapidly, I started thinking about how this would effect 
performance, memory issues, etc.

Does anyone have experience doing this and doing it rapidly? Anyone come across 
any memory issues, leakage, etc.? Anything else I should look for in doing 
this? Different ways to accomplish the same thing?

Any insight is appreciated!

Thanks,

Steve MacLean

___
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: valueDiff for arrays?

[Monte Goulding via use-livecode]

> 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 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 sides are converted to strings so you end up comparing “” to “false"

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: valueDiff for arrays?

[Mark Wieder via use-livecode]

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 the case, but it falls apart for empty function arguments.

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

--
 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: valueDiff for arrays?

[Monte Goulding via use-livecode]

> 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 my head 
> without looking at the code ) to specify where "not" is legal.

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:


not “foo” is “bar” -> (not “foo”) is “bar” -> (not “false”) is “bar” -> “true" 
is “bar” -> “false”

not (“foo” is “bar”) -> not “false” -> “true"

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: valueDiff for arrays?

[Brian Milby via use-livecode]

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
array.  1/3 have the same key and value, 1/3 have the same key but
different values, 1/3 are non-matching keys.  Somewhere just over 50,000
keys the quickest version switches.  Here's the code:

function bwmValueDiffPut pLeft, pRight
   local tResult, tLeft, tRight
   repeat for each key tKey in pLeft
  if tKey is among the keys of pRight and \
pLeft[tKey] is not pRight[tKey] then
 put pLeft[tKey] into tLeft[tKey]
 put pRight[tKey] into tRight[tKey]
  end if
   end repeat
   put tLeft into tResult["1"]
   put tRight into tResult["2"]
   return tResult
end bwmValueDiffPut

As anything, the real data set would impact the results significantly.  For
example, the above code does the "among" test for every key.  It does the
"is not" test for 2/3 of the keys.  It does the pair of put statements for
1/3 of the keys.  As that mix changed, the results would too - changing the
point at which this method would be the fastest.  But to put it into
perspective, the 50,000 key test took around 75ms for both methods.
100,000 keys came in around 150ms on my machine.

I will also note that the dual loop delete method for LCS always lost and
by a significant margin (deleted from left first, deleted from right
second).  The combination delete/put loop was slightly slower than the
above code (deleted from left, created new right as above).  Also, Mark's
version was faster than my revision.  I'm thinking that was due to the way
I was going into a second level array (tResult["2"][tKey] vice
tRight[tKey]).
___
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: [OT] The problem with programming and how to fix it

[Alejandro Tejada via use-livecode]

Mark Wieder wrote:
> Dang. And I was *so* waiting around for LC11.

We already have revSpeak, so I could wait a few years
for the command revListen  :-D

http://docs.runrev.com/Command/revSpeak

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: [OT] The problem with programming and how to fix it

[Mark Wieder via use-livecode]

On 08/05/2018 01:48 PM, Mark Waddingham via use-livecode wrote:

How are all these artifical intelligence assistants, and various drivers 
needed for the various forms of input you suggest built?


I don't think there are any magic beans around you can plant to have 
them appear...


Dang. And I was *so* waiting around for LC11.

--
 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: [OT] The problem with programming and how to fix it

[Alejandro Tejada via use-livecode]

Hi Mark,

> H - I think that is missing the point about what the
> current 'AI' technologies that exist actually do (as far as
> I can see anyway - I'd be more than happy to be
> proved wrong!)...

Well, the point is that all current AI technologies requires
an internet connection to work and AI software that run
in servers is learning thousands of new interactions
everyday from millions active users.

If a thousand small tasks and user interactions prove to be
useful (based in user feedback) and successful (based in
repeated use) for many, many users, then the operating
system will offer these tasks, make them available to you
and all users. Millions of new users.
Step by step, task by task a picture of a more and more
useful AI assistant will emerge thanks to the feedback
and guidance from millions active users.

> They are merely mappings from one form input to another form of input -
> they themselves don't do any action - the actions still have to be
> implemented somehow.

Yes, in a central server. In this moment there are millions creating
these tasks (probably unaware that they are programming too)

> Alexa for example by itself does diddly-squat beyond map voice to a
> lower level actionable command (with an element of context, certainly
> which makes it slightly interesting) - it's the skills that people 'like
us'
> implement which actually do the thing Alexa interprets that we want
> to be done.

Yes, this is programming. Millions active users are doing this
for free in this moment.

> Same with google assistant, siri, wolfram alpha, even google search -
> I can type 'what is 100 usd in gbp' and it gives me the answer.
> However the reason google search can do that is because
> some programmer at google has added a hook which knows
> that when that pattern is searched for it should call a program
> that has been explicitly written which looks up the current
> exchange rate and then renders the result in a nicely formatted
> string which appears at the top of the search results.

The keys to create more useful AI assistants are positive
user feedback and repeated use. Time will tell
which company wins this time.

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: valueDiff for arrays?

[Mark Waddingham via use-livecode]

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:
filter X by matching pattern "regex" into Z
Which would expand to:
filter X by keeping the lines matching regex pattern "regex" into Z


TOP:

Yes - I realized earlier on that the shortened versions do no harm, and 
in all honesty I don't think the negated forms do either.


At the end of the day they all map through a well-defined (admittedly, 
hypothetical) mechanical process to a set of unambiguous preferred forms 
- so there is no problem with meaning.


Indeed, a lot of how we code is down to personal taste. I run a team of 
programmers, and so we have to have rules internally which everyone 
follows - just like if you try and run a team where everyone speaks an 
entirely different natural language, you are going to have significant 
problems in communication; teams of programmers communicate in code a 
lot, so its important that everyone largely 'speaks' the same language 
(well 'dialect' is probably a more accurate term here).


So I'll certainly be suggesting that should the new variant form appear 
that a review criteria of LCS code will be (internally) negated forms 
are banned - just swap keeping <-> discarding; and the style rules for 
the open-source project will mandate the same.


Similarly - shortened versions would be too under the same auspices. 
This isn't anything to do with being dictatorial or just a control-freak 
- its about ensuring consistency of communication. Every line of code 
which we write that goes into the product needs to endure for a long 
time and be read by many people - so its best that its made as uniform 
as possible at the start.


What people outside those spheres wish to do is entirely up to them - 
although I'd urge people to generally use the preferred forms in all 
cases in your own code, its not like I can come and beat you all around 
the head if you don't.


(Of course, I *can* just not allow them to be included... GOTO TOP).

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: valueDiff for arrays?

[Mark Waddingham via use-livecode]

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 written as both:

filter X by keeping the lines not matching pattern “regex"

and

filter X by discarding the lines matching pattern "regex"

So it would perhaps be a good idea to only allow `matching` rather 
than `not matching`


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 my head without looking at the code ) to specify where "not"
is legal.


In this case the forms would be hardcoded:

  'not matching pattern "regex"'

is actually (essentially) sugar for:

  'where not each matches "regex"'

So *if* we could implement it like that then it would potentially do no 
harm - *however* as it stands it would be implemented as hard-coded 
parsing / exec code - so its actually more work to support 'not' here, 
and not less.


However, there is certainly a consistency argument to be had - its 
whether consistency is always better than a slight amount of positive 
coercion - in terms of restricting some forms of syntax which actually 
reduce readability rather than increase it (which, I think, on balance 
'not' here might well do - as in reduce - and since this whole 
discussion came about because *I* have a significant problem parsing the 
'filter' command as it stands - readability is perhaps the main concern 
here).


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: valueDiff for arrays?

[J. Landman Gay via use-livecode]

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 might very well just be me!).


If you and I were alone together in a room, yeah, it would just be you. 
;) Filtering "with" is always like draining potatoes to me.


However, that might be because the only form of "filter" originally was 
to keep the solids. It was some years before the "without" form was 
added, and by then I'd had a lot of time to know what to expect.



Sure we can make the extra bits optional


Cool. Backward compatibility and all that.

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

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

Re: [OT] The problem with programming and how to fix it

[Richmond Mathewson via use-livecode]

Oh, Dear, Mark, I think you've just fallen into my trap . . .

If you've lost sight of something, you . . .

Sorry about that; just too hard to resist.

---

" "enabling millions of novices to build simple applications" "

--

Although, to be fair that's not the problem.

What might be the problem is what we might call "reach".

Every single Macintosh came with HyperCard installed.

Nothing comes with LiveCode installed.

AND LiveCode's uptake is very slim indeed.

I have just started learning Python: NOT because I don't think LiveCode 
rocks the socks off almost every other programming language/IDE,


but because of pure economics.

I would like someone to explain why people all seem to want their kids 
to learn C++, C# or Python when

they all look like riffs on the PASCAL I studied 33 years ago at University.

And PYTHON comes installed on Macintosh and most Linux distros.

Richmond.

On 5/8/2018 11:46 pm, Mark Waddingham via use-livecode wrote:

On 2018-08-05 21:49, Richmond Mathewson via use-livecode wrote:

Who said LiveCode lost sight of that?

Oh, it was me.


Lost sight of what?

Mark.



___
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: valueDiff for arrays?

[Brian Milby via use-livecode]

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 expand to:
filter X by keeping the lines matching regex pattern "regex" into Z


On Sun, Aug 5, 2018 at 4:48 PM, Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
>
> > On 6 Aug 2018, at 7:07 am, Mark Waddingham via use-livecode <
> use-livecode@lists.runrev.com> 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 matching pattern "regex"
>
> So it would perhaps be a good idea to only allow `matching` rather than
> `not matching`
>
> > Anyway - extending the current form with 'where' (rather than 'with
> expression') is more than adequate at the moment.
>
> Hehe.. the `with expression` thing was me trying to come up with something
> that worked with `with | without | matching | not matching`… `where` is
> much better I agree.
>
> 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
>
___
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: valueDiff for arrays?

[Mark Wieder via use-livecode]

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 pattern “regex"

and

filter X by discarding the lines matching pattern "regex"

So it would perhaps be a good idea to only allow `matching` rather than `not 
matching`


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 my head without looking at the code ) to specify where "not" is legal.


--
 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: valueDiff for arrays?

[Mark Waddingham via use-livecode]

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 “regex"

and

filter X by discarding the lines matching pattern "regex"

So it would perhaps be a good idea to only allow `matching` rather
than `not matching`


To be fair - we could get rid of the inverted forms entirely. If you 
want inclusion, use keep, if you want exclusion use discard. i.e.


  filter X by keeping the lines with "..."
  filter X by keeping the lines matching "..."
  filter X by keeping the lines where "..."

  filter X by discarding the lines with ".."
  filter X by discarding the lines matching ".."
  filter X by discarding the lines where ".."

This would probably work much more nicely actually (now I get what you 
were saying!) - it means you don't have the 'double-negative' problem 
(which I think is what you were referring to) - and 'where' gives you a 
general 'get out' especially if we implement the 'matches' operator:


  filter X by discarding the lines where each does not match "..."

So no expressivity is lost - but you retain the absolute clarity of 
having keep/discard.


At the end of the day - why would you choose to use an extra token for a 
negated form, when you can just change keeping to discarding - or vice 
versa?



Hehe.. the `with expression` thing was me trying to come up with
something that worked with `with | without | matching | not matching`…
`where` is much better I agree.


Hehe - yeah - I think we've discussed it before (probably several times 
over a long interval) so that at least require's no bike-shedding... 
After all, in this case, if its good enough for SQL, I can't see why it 
isn't good enough for us (it also happens to be entirely correct from an 
English language point of view - which kinda helps, in an English-like 
language).


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: valueDiff for arrays?

[Monte Goulding via use-livecode]

> 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 matching pattern "regex"

So it would perhaps be a good idea to only allow `matching` rather than `not 
matching`

> Anyway - extending the current form with 'where' (rather than 'with 
> expression') is more than adequate at the moment.

Hehe.. the `with expression` thing was me trying to come up with something that 
worked with `with | without | matching | not matching`… `where` is much better 
I agree.

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: [OT] The problem with programming and how to fix it

[Mark Waddingham via use-livecode]

H - I think that is missing the point about what the current 'AI' 
technologies that exist actually do (as far as I can see anyway - I'd be more 
than happy to be proved wrong!)...

They are merely mappings from one form input to another form of input - they 
themselves don't do any action - the actions still have to be implemented 
somehow.

Alexa for example by itself does diddly-squat beyond map voice to a lower level 
actionable command (with an element of context, certainly which makes it 
slightly interesting) - it's the skills that people 'like us' implement which 
actually do the thing Alexa interprets that we want to be done.

Same with google assistant, siri, wolfram alpha, even google search - I can 
type 'what is 100 usd in gbp' and it gives me the answer.

However the reason google search can do that is because some programmer at 
google has added a hook which knows that when that pattern is searched for it 
should call a program that has been explicitly written which looks up the 
current exchange rate and then renders the result in a nicely formatted string 
which appears at the top of the search results.

Warmest Regards,

Mark.

Sent from my iPhone

> On 5 Aug 2018, at 16:08, Alejandro Tejada via use-livecode 
>  wrote:
> 
> Hi Mark,
> 
>> Lost sight of what?
> 
> If I understand Richmond correctly, he is talking that for
> many developers the name HyperCard is synonymy
> with "vastly easier and more accessible programming"
> and that RunRev could have taken advantage of this
> for positioning LiveCode among other development
> platforms... BUT I disagree, because Livecode is
> multiplatform and for everyone else, except Mac users,
> HyperCard do not run in their computers.
> 
>> How are all these artifical intelligence assistants,
>> and various drivers needed for the various forms of
>> input you suggest built?
> 
>> I don't think there are any magic beans around you
>> can plant to have them appear...
> 
> After Google, Microsoft, Apple and Linux implement these
> features in their operating systems, then every program could
> use them. Google could be first, then Apple, later Microsoft
> and finally Linux... but I could be wrong in this sequence.
> 
> 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


___
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: [OT] The problem with programming and how to fix it

[Alejandro Tejada via use-livecode]

Hi Mark,

> Lost sight of what?

If I understand Richmond correctly, he is talking that for
many developers the name HyperCard is synonymy
with "vastly easier and more accessible programming"
and that RunRev could have taken advantage of this
for positioning LiveCode among other development
platforms... BUT I disagree, because Livecode is
multiplatform and for everyone else, except Mac users,
HyperCard do not run in their computers.

> How are all these artifical intelligence assistants,
> and various drivers needed for the various forms of
> input you suggest built?

> I don't think there are any magic beans around you
> can plant to have them appear...

After Google, Microsoft, Apple and Linux implement these
features in their operating systems, then every program could
use them. Google could be first, then Apple, later Microsoft
and finally Linux... but I could be wrong in this sequence.

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: valueDiff for arrays?

[Mark Waddingham via use-livecode]

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 | where in order to figure out what
will actually happen. I would rather [by { keeping | discarding }] be
a parser error if used with without and not matching.


I'm not sure I follow - I think you took the above out of context - I 
was using an elided form of the operations to indicate the mapping from 
existence / non-existence of keywords to the underlying operation...


The form is actually:

  filter X by keeping the lines where P
  filter X by discarding the lines matching "glob"
  filter X by keeping the lines not matching pattern "regex"

* Yes I've inserted 'the' there - because it then makes the query 
expressions the same as Mark Wieder's suggestion. Also I might not have 
matching quite right - it might be a bit more verbose than that.


I'm not too fussed about whether the new form has with or without - they 
are the 'arcane' words in this situation which caused me the problem in 
the first place.


By arcane here I mean you actually have to read the docs to understand 
what they are referring to:


  filter X with "foobar"

Isn't exactly clear at first sight - "foobar" is a string - with 
 ? What does that mean? (You have to forget that you know *what* 
that command actually means to actually get my point - the reason I can 
do that easily is that I never remember correctly and always have to 
either try both or look it up).


I think the key point is that - out of context - which is generally the 
first phase of reading code:


  filter lines of X matching Y
  filter lines of X not matching Y

Makes no reference to what the 'default' mode of filter is - i.e. 
whether it keeps the solids, or keeps the liquids as Jacque put it. 
Given any recipe (to use the culinary metaphor) which in either case is 
entirely defined by *what* you are cooking (after all - how many recipes 
keep the fluid you get after draining potatoes, rather than the 
potatoes?)... 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 might very well just be me!).


If we insert an explicit keep / discard then it makes it crystal clear 
and unambiguous regardless of context.


Sure we can make the extra bits optional - so you can type less if you 
want - that's personal taste, and how much you want to torture yourself 
later, and others, when they read the code!


Anyway - extending the current form with 'where' (rather than 'with 
expression') is more than adequate at the moment.


The proposal above needs more work anyway - so it isn't an immediate 
thing in any case.


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: [OT] The problem with programming and how to fix it

[Mark Waddingham via use-livecode]

On 2018-08-05 22:40, Alejandro Tejada via use-livecode wrote:

In my humble opinion, the future of programming
would be driven by artificial intelligence assistants
and multiple ways of working and interfacing with
the computer using voice, gaze interaction, gesture,
motion, pointer, keyboard, etc...


How are all these artifical intelligence assistants, and various drivers 
needed for the various forms of input you suggest built?


I don't think there are any magic beans around you can plant to have 
them appear...


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: [OT] The problem with programming and how to fix it

[Mark Waddingham via use-livecode]

On 2018-08-05 21:49, Richmond Mathewson via use-livecode wrote:

Who said LiveCode lost sight of that?

Oh, it was me.


Lost sight of what?

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: [OT] The problem with programming and how to fix it

[Alejandro Tejada via use-livecode]

Richmond wrote:
> Who said LiveCode lost sight of that?
> Oh, it was me.

Actually, I understand why RunRev do not want to
sell LiveCode as a HyperCard replacement.

LiveCode is multiplatform and this single fact
set it apart from all previous x-talk languages.

In my humble opinion, the future of programming
would be driven by artificial intelligence assistants
and multiple ways of working and interfacing with
the computer using voice, gaze interaction, gesture,
motion, pointer, keyboard, etc...

Al


On Sun, Aug 5, 2018 at 3:16 PM, Alejandro Tejada 
wrote:
>
> "Programming could be much much easier most of the time.
> This unnecessary difficulty wastes the effort of professional
> programmers, but worse, prevents many people from programming
> at all. The problem is a nasty hairball of culture and technology
> and money that is not easily untangled"
>
> https://alarmingdevelopment.org/?p=1173
>
> Jonathan Edwards, the author of this article, remembers
> HyperCard for "enabling millions of novices to build
> simple applications"
>
> 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: valueDiff for arrays?

[Monte Goulding via use-livecode]

> 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 wildcard P)
> 
>  discarding where P -> not P
>  discarding with P -> not (each matches wildcard P)
>  discarding without P -> each matches wildcard P
>  discarding matching P -> not (each matches pattern P)
>  discarding not matching P -> each matches wildcard P
> 
> So the actual underling operation is the same: P is a boolean predicate 
> operating on 'each', where each is taken to be each 'chunk' of X in turn; if 
> P(each) returns true, the element is kept, otherwise it is discarded.
> 
> I quite like the above - it has a very simple underbelly (a single 
> operation!), but the actual English-like syntax is a true and correct 
> sentence.
> 
> What do people think?

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 | 
where in order to figure out what will actually happen. I would rather [by { 
keeping | discarding }] be a parser error if used with without and not matching.

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: valueDiff for arrays?

[Monte Goulding via use-livecode]

> 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 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: valueDiff for arrays?

[Brian Milby via 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 from left as it 
iterates and also builds the desired right at the same time.

To Mark’s point, I did try a pure LCS approach with 2 loops which only used 
delete. That was slightly slower than my initial approach.

I was just attempting to show how much the engine functions outperformed what 
could be done in pure LCS. Also I wanted to quantify the delta. I guess I 
should really compare the pure intersect and union functions too.

If anyone is interested I can put a copy of the stack online with all of the 
variations that I timed.

Thanks,
Brian
On Aug 5, 2018, 2:26 PM -0500, 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
> > intersect pLeft with pRight into tResult["1"]
> > repeat for each key tKey in tResult["1"]
> > if pLeft[tKey] is pRight[tKey] then
> > delete variable tResult["1"][tKey]
> > end if
> > end repeat
> > intersect pRight with tResult["1"] into tResult["2"]
> > return tResult
> > end bwmValueDiff
>
> That looks like LCS. What is the "pure LCS solution" you were comparing
> it to?
>
> --
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.com http://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: iOS 12 compatibility

[panagiotis merakos via use-livecode]

Hi Andrew, sure, send it to panos.mera...@livecode.com along with a recipe
to reproduce the problem.

Best,
Panos

On Sun, Aug 5, 2018, 20:39  wrote:

> I've been trying to figure out the exact recipe and/or a workaround
> for this problem and I can't. From the testing that I've done,
> items/groups are in fact moving but the screen is not being redrawn.
>
> Can I send my problem stack for someone to take a look at without
> posting it online?
>
> --Andrew Bell
>
> Quoting panagiotis merakos :
>
> > Ok, one less issue to tackle then :)
> >
> > If you could file a bug report with a reproducible recipe (and ideally a
> > sample stack), this will help us identify and fix the problem in an
> > upcoming release.
> >
> > Best,
> > Panos
> > --
> >
> > On Wed, Jul 25, 2018 at 5:13 PM,  wrote:
> >
> >> I've been using 9.0.0.
> >>
> >> When using 9.0.1rc1 the black flash (issue #1) disappears but my
> >> navigation breaks (issue #2) when I enable acceleratedRendering.
> >>
> >> When using 9.0.0 acceleratedRendering messes up all sorts of stuff like
> my
> >> navigation and has a lot of flashing black space, not just at app
> launch.
> >>
> >> --Andrew Bell
> >>
> >> --
> >>
> >>
> >> @Andrew thanks for checking.
> >>
> >> Which LC version do you now use? We have fixed *a lot* of
> >> acceleratedrendering-related issues in LC 9.0.1- RC-1, so issue #2
> might be
> >> already fixed.
> >>
> >> Best,
> >> Panos
> >> --
> >>
> >> On Wed, Jul 25, 2018 at 2:11 PM, Andrew Bell via use-livecode <
> >> use-livecode@lists.runrev.com> wrote:
> >>
> >> Yes, enabling acceleratedRendering in the preOpenStack does allow
> the
> >> app to launch in iOS 12! I was not able to actually install the app
> >> directly to the device from LiveCode (got a generic "Error" message) so
> I
> >> had to uninstall 12, install the app under 11, then upgrade back to 12
> >> (public beta 3) to test.
> >>
> >> I now remember why I disabled acceleratedRendering in the first
> place:
> >>  1- it adds a quick black screen during the launch of the app
> (between
> >> the openStack and openCard it seems)
> >>  2- it breaks the navigation system that I implemented to get from
> >> card to card (animation of a group that appears from off card)
> >>
> >> I can live with #1 for now and will start plotting a work around for
> >> #2 just so I can get an update out the door. Thanks for looking into
> this!
> >>
> >> --Andrew Bell
> >>
> >>
>
>
>
>
___
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: [OT] The problem with programming and how to fix it

[Richmond Mathewson via use-livecode]

Who said LiveCode lost sight of that?

Oh, it was me.

Richmond.

On 5/8/2018 10:16 pm, Alejandro Tejada via use-livecode wrote:

"Programming could be much much easier most of the time.
This unnecessary difficulty wastes the effort of professional
programmers, but worse, prevents many people from programming
at all. The problem is a nasty hairball of culture and technology
and money that is not easily untangled"

https://alarmingdevelopment.org/?p=1173

Jonathan Edwards, the author of this article, remembers
HyperCard for "enabling millions of novices to build
simple applications"

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


___
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: datagrid scrolling question

[Douglas Ruisaard via use-livecode]

OK.. the light bulb FINALLY went on .. I'm slow but, like the tortoise, I 
eventually "get there" (usually).  For some reason Brian's reply made me 
re-think how I could fetch the WiFi info query from *each* row, submit it to 
tsnet and then update each row in realtime.  I know, I know... that's what 
you've ALL been saying but I was interpreting that as processing ALL of the 
WiFi modules first *AND THEN* updating the WHOLE grid.  THAT would, of course, 
work but doing it one row at a time just wasn't penetrating the old noggin.

Works perfectly.  Thanks so much for your patience!  I reiterate, as has been 
done so many times to this group, how remarkably responsive and helpful this 
community is!

Douglas Ruisaard
Trilogy Software
(250) 573-3935

From: Brian Milby [mailto:br...@milby7.com] 
Sent: Sunday, August 05, 2018 8:22 AM
To: use-livecode@lists.runrev.com; Douglas Ruisaard
Subject: RE: datagrid scrolling question

You can get/put data from/into the grid one row at a time without needing to 
figure out the group name, so you could have it update in real time in your 
external button. You should be able to use the same behavior script (possibly 
with a slight modification) everywhere.

I’m not at a computer right now so I will work out an example later if someone 
else doesn’t beat me to it.

Thanks,
Brian


___
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: iOS 12 compatibility

[Andrew Bell via use-livecode]

I've been trying to figure out the exact recipe and/or a workaround  
for this problem and I can't. From the testing that I've done,  
items/groups are in fact moving but the screen is not being redrawn.


Can I send my problem stack for someone to take a look at without  
posting it online?


--Andrew Bell

Quoting panagiotis merakos :


Ok, one less issue to tackle then :)

If you could file a bug report with a reproducible recipe (and ideally a
sample stack), this will help us identify and fix the problem in an
upcoming release.

Best,
Panos
--

On Wed, Jul 25, 2018 at 5:13 PM,  wrote:


I've been using 9.0.0.

When using 9.0.1rc1 the black flash (issue #1) disappears but my
navigation breaks (issue #2) when I enable acceleratedRendering.

When using 9.0.0 acceleratedRendering messes up all sorts of stuff like my
navigation and has a lot of flashing black space, not just at app launch.

--Andrew Bell

--


@Andrew thanks for checking.

Which LC version do you now use? We have fixed *a lot* of
acceleratedrendering-related issues in LC 9.0.1- RC-1, so issue #2 might be
already fixed.

Best,
Panos
--

On Wed, Jul 25, 2018 at 2:11 PM, Andrew Bell via use-livecode <
use-livecode@lists.runrev.com> wrote:

Yes, enabling acceleratedRendering in the preOpenStack does allow the
app to launch in iOS 12! I was not able to actually install the app
directly to the device from LiveCode (got a generic "Error" message) so I
had to uninstall 12, install the app under 11, then upgrade back to 12
(public beta 3) to test.

I now remember why I disabled acceleratedRendering in the first place:
 1- it adds a quick black screen during the launch of the app (between
the openStack and openCard it seems)
 2- it breaks the navigation system that I implemented to get from
card to card (animation of a group that appears from off card)

I can live with #1 for now and will start plotting a work around for
#2 just so I can get an update out the door. Thanks for looking into this!

--Andrew Bell







___
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: valueDiff for arrays?

[Mark Waddingham via use-livecode]

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
   intersect pLeft with pRight into tResult["1"]
   repeat for each key tKey in tResult["1"]
  if pLeft[tKey] is pRight[tKey] then
 delete variable tResult["1"][tKey]
  end if
   end repeat
   intersect pRight with tResult["1"] into tResult["2"]
   return tResult
end bwmValueDiff


That looks like LCS.  What is the "pure LCS solution" you were 
comparing it to?


I think Brian means where it does not use intersect - i.e. all loops are 
in LCS.


FWIW - I'm pretty sure this operation can be done using only two loops 
(one over left, and one over right).


Also, I'm pretty sure that a 'pure' LCS solution of that as suggested 
above would actually be faster than the minimum 3 loops needed if you 
use engine array ops - above a certain array size.


However, I haven't had a chance to code it yet.

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: valueDiff for arrays?

[Mark Waddingham via use-livecode]

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 the value is an
empty string, is worth taking into account.


In the general case it depends on what data you are modelling with an 
array.


If an array key-value is modelling a field which is not optional, then 
there is no need to distinguish between an array key being there, and 
one not being there - i.e. all field accesses can be tRecord[tKey], and 
your key value can be empty.


If a field's value has to be non-empty to be valid, then you can test 
for existence of a field by doing tRecord[tKey] is not empty. So, again, 
presence or not presence of an array key is immaterial.


The only case where you need to treat no key-value as different from 
empty key-value is where a valid value for an optional field can be the 
empty string. In which case that field access needs to be structured as:


  if tKey is among the keys of tRecord then
-- yay the key is there
  else
-- oh, there is no key
  end if

This is because LC doesn't see the difference between the empty string 
and absence of a value - but you can model that with an array key-value 
which is optional.


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: valueDiff for arrays?

[Richard Gaskin via use-livecode]

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"]
>repeat for each key tKey in tResult["1"]
>   if pLeft[tKey] is pRight[tKey] then
>  delete variable tResult["1"][tKey]
>   end if
>end repeat
>intersect pRight with tResult["1"] into tResult["2"]
>return tResult
> end bwmValueDiff

That looks like LCS.  What is the "pure LCS solution" you were comparing 
it to?


--
 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: valueDiff for arrays?

[Richard Gaskin via use-livecode]

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


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

[OT] The problem with programming and how to fix it

[Alejandro Tejada via use-livecode]

"Programming could be much much easier most of the time.
This unnecessary difficulty wastes the effort of professional
programmers, but worse, prevents many people from programming
at all. The problem is a nasty hairball of culture and technology
and money that is not easily untangled"

https://alarmingdevelopment.org/?p=1173

Jonathan Edwards, the author of this article, remembers
HyperCard for "enabling millions of novices to build
simple applications"

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: valueDiff for arrays?

[Mark Waddingham via use-livecode]

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 generally useful.

This would then lead to a 'matches operator' and a 'matches wildcard' operator.

The code for this is in the filter command already - and the query expression 
impl would use the same code so it would be as fast as filter currently is.

Warmest Regards,

Mark.

Sent from my iPhone

> On 5 Aug 2018, at 13:37, Mark Wieder via use-livecode 
>  wrote:
> 
>> 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 torture!) eliminate the need for filter into.
>> e.g
>> the lines of X where Y
>> Could be something which would work anywhere an expression does.
> 
> As a long-term goal, I muchly like this.
> 
>> However, small steps - the current filter code is tied to the filter command 
>> - so additions is easier to do there first as @Monte has demonstrated.
> 
> No worries. Syntax aside, I tend to use the filter command quite a bit, as 
> the implementation in the engine is blazingly fast.
> 
> -- 
> 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


___
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: valueDiff for arrays?

[Mark Wieder via use-livecode]

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 
torture!) eliminate the need for filter into.

e.g

the lines of X where Y

Could be something which would work anywhere an expression does.


As a long-term goal, I muchly like this.


However, small steps - the current filter code is tied to the filter command - 
so additions is easier to do there first as @Monte has demonstrated.


No worries. Syntax aside, I tend to use the filter command quite a bit, 
as the implementation in the engine is blazingly fast.


--
 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: valueDiff for arrays?

[Mark Waddingham via use-livecode]

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

Could be something which would work anywhere an expression does.

However, small steps - the current filter code is tied to the filter command - 
so additions is easier to do there first as @Monte has demonstrated. 

Warmest Regards,

Mark.


Sent from my iPhone

> On 5 Aug 2018, at 12:29, Mark Wieder via use-livecode 
>  wrote:
> 
>> 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
> 
> -- 
> 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


___
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: Getting Started with DataGrid and another datagrid form

[Douglas Ruisaard via use-livecode]

Ah ... I think I can answer this.  Basically, you don't *have* to code the 
"Layout Control" beyond the recommended:

  set the rect of graphic "Background" of me to pControlRect

and even that may be, technically, optional.

The handler is there (I believe) as a method by which you can "dynamically" 
change the layout of a row (using grid FORMS.. the Behavior script is NOT used 
for TABLE grids) and/or being able to programmatically alter the layout of a 
row without going through the whole "Edit Group" method.

Not sure what you mean or asking about the "WYSIG panel" (never seen "WYSIG" .. 
only know "WYSIWYG" ... same thing?) ... do you mean the Row Template?

Douglas Ruisaard
Trilogy Software
(250) 573-3935

> From: Sannyasin Brahmanathaswami 
> To: How to use LiveCode 
> Subject: Re: Getting Started with DataGrid and another datagrid form
> Message-ID:
>   
> 
> 
> Content-Type: text/plain; charset="us-ascii"
> 
> I slowly studying as much as we can on the datagrid,and "digging" in it with 
> an first attempt to build
> a form.
> 
> One thing is not clear to me.
> 
> 1) Have the  WYSIG panel to build the datagrid form.
> 
> 2) why then do we  have, in the Behavior Script  this handler?
> 
> Isn't the layout already pre-determined in the template?
> 
> on LayoutControl pControlRect, pWorkingRect
> 
> local theFieldRect
> 
> -- This message is sent when you should layout your template's controls.
> 
> -- This is where you resize the 'Background' graphic, resize fields and
> 
> -- position objects.
> 
> -- For fixed height data grid forms you can use items 1 through 4 of 
> pControlRect as
> 
> -- boundaries for laying out your controls.
> 
> -- For variable height data grid forms you can use items 1 through 3 of 
> pControlRect as
> 
> -- boundaries, expanding the height of your control as needed.
> 
> -- The working rect is defined area of the control you can safelt use.
> 
> -- Use this rect to make sure your controls don't overlap with any edit mode 
> controls.
> 
> -- Example:
> 
> put the rect of field "Label" of me into theFieldRect
> 
> put item 1 of pWorkingRect into item 1 of theFieldRect
> 
> put item 3 of pWorkingRect - 5 into item 3 of theFieldRect
> 
> set the rect of field "Label" of me to theFieldRect
> 
> set the rect of graphic "Background" of me to pControlRect
> 
> end LayoutControl
> 
> 
> BR
> 
> 


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

Re: valueDiff for arrays?

[Mark Wieder via use-livecode]

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

--
 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: Getting Started with DataGrid and another datagrid form

[zryip theSlug via use-livecode]

The code you have in the default behavior is the one installed by the
inspector located in one of the behavior button (stack only script now,
since the dg2)

It contains the minimal example code to help the developer starting;
FillinData, preFillinData, LayoutControl, etc

If you are modifying the template for the datagrid (adding a control,
deleting a control, etc) you have to change the code for your datagrid row
manually. By default the minimal script is considering you have a field
"Label" and a "background" graphic. If you are deleting one of them in the
template and you do not update the behavior script for the row accordingly,
the datagrid library will fire an error when it will try to apply the
template to a row. Note that if your are removing the "background" graphic
you will lose the possibility to "hilited" a row, at least on screen.

When you are updating the template in DGH now, it will install first the
default script (like the inspector). If you have done a modification in the
template (especially after having delete one object), DGH can help you by
building the script required for the controls it will find inside the
template. As we want not to erase something in the script which could has
been changed by the developer, the operation is manual.

Ideally to prevent the datagrid library to send an error with missing
controls in the template, you should update the script before to click onto
the "update" button.

On Sun, Aug 5, 2018 at 7:03 PM, Sannyasin Brahmanathaswami via use-livecode
 wrote:

> I slowly studying as much as we can on the datagrid,and "digging" in it
> with an first attempt to build a form.
>
> One thing is not clear to me.
>
> 1) Have the  WYSIG panel to build the datagrid form.
>
> 2) why then do we  have, in the Behavior Script  this handler?
>
> Isn't the layout already pre-determined in the template?
>
> on LayoutControl pControlRect, pWorkingRect
>
> local theFieldRect
>
> -- This message is sent when you should layout your template's controls.
>
> -- This is where you resize the 'Background' graphic, resize fields and
>
> -- position objects.
>
> -- For fixed height data grid forms you can use items 1 through 4 of
> pControlRect as
>
> -- boundaries for laying out your controls.
>
> -- For variable height data grid forms you can use items 1 through 3 of
> pControlRect as
>
> -- boundaries, expanding the height of your control as needed.
>
> -- The working rect is defined area of the control you can safelt use.
>
> -- Use this rect to make sure your controls don't overlap with any edit
> mode controls.
>
> -- Example:
>
> put the rect of field "Label" of me into theFieldRect
>
> put item 1 of pWorkingRect into item 1 of theFieldRect
>
> put item 3 of pWorkingRect - 5 into item 3 of theFieldRect
>
> set the rect of field "Label" of me to theFieldRect
>
> set the rect of graphic "Background" of me to pControlRect
>
> end LayoutControl
>
>
> BR
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
Zryip TheSlug
http://www.aslugontheroad.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: datagrid scrolling question

[Douglas Ruisaard via use-livecode]

Many thanks to one and all for the interesting responses ... particularly to 
Zryip for the extensive reply!

I may be coming at LC from a somewhat unusual direction.  The vast majority of 
my programming background was in very large, distributed servers running 
dedicated medical applications and system and instrumentation interfaces.  My 
specialty is interfacing various disparate systems with each other and the 
amount of "user-interactive" processing I have to do in that environment is 
extremely minimal.

Initially, I very successfully employed LC to develop background (i.e. NO user 
interaction whatsoever) tasks and used its marvelous cross-platform abilities 
to the fullest.  So, in essence, user-interaction is fairly "foreign" to me.

You all point out that datagrids *are*, fundamentally, a user-interactive 
device where I am looking for a way to use them as a processing tool, in 
and of themselves.  I *do* employ the user-interaction as well... as I 
initially mentioned, using the controls on each row (interactively) works very 
well.  But, due to my nature, I want to be able to optionally "automate" any 
user-level function and remove the "human" component for consistency and 
reliability.  Yes, I can process all of the wi-fi modules first and then 
populate the grid; but, if I may be flippant, it's FUN to watch as each row 
triggers, fetches and populates each row, one at a time.  Since I made the task 
capable of being interactive, this is similar as to why someone would use any 
animation to make their display interesting to a user.  Animation often does 
not contribute to actual functionality but it is FUN to watch.

Many times in this group, I read how users and contributors reference aspects 
of LC "under-the-hood".  I found it interesting that most of the responses 
primarily referenced WHAT *I* was doing, rather than WHAT the DG was doing... 
which is what I tried to emphasize... and I apologize if that intention wasn't 
clear.  I understand and am sincerely grateful for the goal-orientation of the 
responses.  However, topically (not necessarily typically), this group is no 
stranger to investigating and constructively criticizing how LC performs a 
function.  I'm OK with my wrapping pseudo-group name method ... I was simply 
wondering if anyone had an alternative to using the "send mouseUp" approach of 
calling rows outside of the DG, itself.

My challenge now is to find a way to "calculate" the number of "visible" rows 
displayed (particularly if I want to make the visible portion of the datagrid 
dynamically sizable), so I can formulate the "break" point for the group name 
wrapping.  I, again, would appreciate any help for that function.

I genuinely appreciate the assistance and look forward to future involvement 
with this group.  I also look forward to the day I can contribute solutions to 
some of the very challenging issues discussed... many of them still leave me in 
the dust.

Douglas Ruisaard
Trilogy Software
(250) 573-3935




___
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: valueDiff for arrays?

[J. Landman Gay via use-livecode]

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 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 write a significant contraction. However, by being verbose 
you can make the command a complete representation of what is being done 
without needing to understand the context of the operation (which means 
code which is more verbose is much more quickly readable).


Anyway, maybe when we finally get to open language we can have a culinary 
based variant syntax ;)


Warmest Regards,

Mark.

Sent from my iPhone

On 5 Aug 2018, at 11:23, David Glasgow via use-livecode 
 wrote:


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


Maybe I cook too much. In any case, the solids (what remains after 
filtering) are the things you're either keeping or discarding.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On August 5, 2018 9:38:45 AM Brian Milby via use-livecode 
 wrote:


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 tFoo[each] is not tBar[each]
(And to get Richard’s result you would need to follow this by an intersect 
each way. The filter would replace the repeat loop in Mark’s solution)



Even though “with where” would be syntactically correct, the preferred 
usage would be “keeping where”.


Thanks,
Brian
On Aug 5, 2018, 7:32 AM -0500, Mark Waddingham via use-livecode 
, wrote:

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


Examples:
local tFoo,tBar
put "foo" into tFoo[1]
put "bar" into tFoo[2]
put "baz" into tBar[1]
put "bar" into tBar[2]
filter keys of tFoo with expression tFoo[each] is tBar[each]
— tFoo now has one key 2 which is `bar`

put “yes,foo” & return & “no,bar” into tFoo
filter lines of tFoo with expression item 1 of each is “yes”

We could feasibly not use `with|without` for this forcing the
expression to return true to filter. If we went that way then perhaps
`where` would be nicest?

filter lines of tFoo where item 1 of each is “yes”


Geez @Monte - you do like creating work for me don't you! ;)

In terms of syntax - definitely not 'with expression' - that's ghastly.
It is a 'where' clause - in the same vein as SQL and other query
languages - so no bike-shedding required there (also, pleasingly, all
other 'filter' types become sugar for a where clause using operators
which the language does not have yet - but obviously we have the code
for...).

If we are going to bike-shed over syntax - can we do so over the use of
'filter' itself. I don't know why but I have a complete mental block
about it - regardless of how many times I use it or read it - I always
have to 'double-think' to work out what form to use - is that just me?

filter  of X with Y
filter  of X without Y

I couldn't tell you just by looking *what* they actually do. I'm not
sure why but I think the verb is actually wrong - in all cases you have
a set of things and you are either keeping an element, or removing an
element... So I wonder if:

keep  of X where Y
discard  of X where Y

(I'm not particularly attached to keep/discard - but it does need to be
a pair of 'true' antonyms which don't intersect with any other 'core'
pairs of such things we have).

Might be more appropriate?

Of course, maybe it is just 'with' / 'without' are inappropriate, and
'where' might actually help me retrain my mind to see with/without as
the sugar they truly are.

Anyway, thought it worth throwing out there to see what people think?

Warmest Regards,

Mark.

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

__

Re: valueDiff for arrays?

[J. Landman Gay via use-livecode]

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 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 solids. Filtering "without" dumps
them and keeps the liquid.


I honestly can't see how:

filter lines of X with Y

Is less contorted and more natural language than:

filter X by keeping lines matching Y

The former *requires* 'arcane' knowledge to comprehend (it is a
significant contraction of concepts - you need to know the contractions
precisely to understand it!) - the latter does precisely what it says -
it is actually a fully correct and full English sentence...

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





___
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: Getting Started with DataGrid and another datagrid form

[Sannyasin Brahmanathaswami via use-livecode]

I slowly studying as much as we can on the datagrid,and "digging" in it with an 
first attempt to build a form.

One thing is not clear to me.

1) Have the  WYSIG panel to build the datagrid form.

2) why then do we  have, in the Behavior Script  this handler?

Isn't the layout already pre-determined in the template?

on LayoutControl pControlRect, pWorkingRect

local theFieldRect

-- This message is sent when you should layout your template's controls.

-- This is where you resize the 'Background' graphic, resize fields and

-- position objects.

-- For fixed height data grid forms you can use items 1 through 4 of 
pControlRect as

-- boundaries for laying out your controls.

-- For variable height data grid forms you can use items 1 through 3 of 
pControlRect as

-- boundaries, expanding the height of your control as needed.

-- The working rect is defined area of the control you can safelt use.

-- Use this rect to make sure your controls don't overlap with any edit mode 
controls.

-- Example:

put the rect of field "Label" of me into theFieldRect

put item 1 of pWorkingRect into item 1 of theFieldRect

put item 3 of pWorkingRect - 5 into item 3 of theFieldRect

set the rect of field "Label" of me to theFieldRect

set the rect of graphic "Background" of me to pControlRect

end LayoutControl


BR


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

Re: valueDiff for arrays?

[Mark Waddingham via use-livecode]

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 write a significant contraction. However, by being verbose you can 
make the command a complete representation of what is being done without 
needing to understand the context of the operation (which means code which is 
more verbose is much more quickly readable).

Anyway, maybe when we finally get to open language we can have a culinary based 
variant syntax ;)

Warmest Regards,

Mark.

Sent from my iPhone

> On 5 Aug 2018, at 11:23, David Glasgow via use-livecode 
>  wrote:
> 
> 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 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 liquid.
>> 
>> Maybe I cook too much. In any case, the solids (what remains after 
>> filtering) are the things you're either keeping or discarding.
>> --
>> Jacqueline Landman Gay | jac...@hyperactivesw.com
>> HyperActive Software | http://www.hyperactivesw.com
>>> On August 5, 2018 9:38:45 AM Brian Milby via use-livecode 
>>>  wrote:
>>> 
>>> 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 tFoo[each] is not tBar[each]
>>> (And to get Richard’s result you would need to follow this by an intersect 
>>> each way. The filter would replace the repeat loop in Mark’s solution)
>>> 
>>> 
>>> Even though “with where” would be syntactically correct, the preferred 
>>> usage would be “keeping where”.
>>> 
>>> Thanks,
>>> Brian
 On Aug 5, 2018, 7:32 AM -0500, Mark Waddingham via use-livecode 
 , wrote:
> 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
> 
> 
> Examples:
> local tFoo,tBar
> put "foo" into tFoo[1]
> put "bar" into tFoo[2]
> put "baz" into tBar[1]
> put "bar" into tBar[2]
> filter keys of tFoo with expression tFoo[each] is tBar[each]
> — tFoo now has one key 2 which is `bar`
> 
> put “yes,foo” & return & “no,bar” into tFoo
> filter lines of tFoo with expression item 1 of each is “yes”
> 
> We could feasibly not use `with|without` for this forcing the
> expression to return true to filter. If we went that way then perhaps
> `where` would be nicest?
> 
> filter lines of tFoo where item 1 of each is “yes”
 
 Geez @Monte - you do like creating work for me don't you! ;)
 
 In terms of syntax - definitely not 'with expression' - that's ghastly.
 It is a 'where' clause - in the same vein as SQL and other query
 languages - so no bike-shedding required there (also, pleasingly, all
 other 'filter' types become sugar for a where clause using operators
 which the language does not have yet - but obviously we have the code
 for...).
 
 If we are going to bike-shed over syntax - can we do so over the use of
 'filter' itself. I don't know why but I have a complete mental block
 about it - regardless of how many times I use it or read it - I always
 have to 'double-think' to work out what form to use - is that just me?
 
 filter  of X with Y
 filter  of X without Y
 
 I couldn't tell you just by looking *what* they actually do. I'm not
 sure why but I think the verb is actually wrong - in all cases you have
 a set of things and you are either keeping an element, or removing an
 element... So I wonder if:
 
 keep  of X where Y
 discard  of X where Y
 
 (I'm not particularly attached to keep/discard - but it does need to be
 a pair of 'true' antonyms which don't intersect with any other 'core'
 pairs of such things we have).
 
 Might be more appropriate?
 
 Of course, maybe it is just 'with' / 'without' are inappropriate, and
 'where' might actually help me retrain my mind to see with/without as
 the sugar they truly are.
 
 Anyw

Re: datagrid scrolling question

[zryip theSlug via use-livecode]

A possible approach for updating only one row is described here:

Now, for some purpose, such as interacting with the row controls, it could
be interesting to have additional keys inside the data. Not I'm thinking a
click in a button is required in your case. But you might have the need to
hide or to disable a button of a specific row on the fly by clicking a
button outside of the datagrid.

In this case
1. we are changing the data for the row by using the
 set the dgDataOfIndex property (see the datagrid documentation
http://lessons.livecode.com/m/datagrid/l/7315-how-do-i-update-data-in-a-row)
2. And when the data for the row is populated in the FillInData we might
have a specific key for disabling the button:

on FillInData pDataArray
set the text of field "Label1" of me to pDataArray["label 1"]
set the text of field "Label2" of me to pDataArray["label 2"]
set the text of field "Label3" of me to pDataArray["label 3"]
set the hilited of btn "Checkbox1" of me to (pDataArray["check box state"]
is "true")
set the enabled of btn "Action1" of me to (pDataArray["button enabled"] is
"true")
end FillInData

You can add a special "update" row key for example in the dgData and if it
is true, execute the code of the mouseUp button

on FillInData pDataArray
set the text of field "Label1" of me to pDataArray["label 1"]
set the text of field "Label2" of me to pDataArray["label 2"]
set the text of field "Label3" of me to pDataArray["label 3"]
set the hilited of btn "Checkbox1" of me to (pDataArray["check box state"]
is "true")
if (pDataArray["update"] is "true") then
 doMyTSNetQuery
end if
end FillInData

on mouseUp
   doMyTSNetQuery
end mouseUp

command doMyTSNetQuery
  doSomething
end doMyTSNetQuery

You are not sharing the code on how your are updating the result field. If
you are trying to put the result value directly in the field of each row by
considering the datagrid as a simple group of controls you are in the wrong
direction. Datagrid is a way to display data, so use the data to serve your
needs and you will be able to tame the beast. :)

For doing that use the FillInData handler. This will just send the message
to the datagrid to execute a doMyTSNetQuery message to the row.
And for changing the content of the result field of the second row for
example, use something like

SetDataOfLine 2, "update", true

and once finished, pass the value to false to stop the update.

Let me know if you could have the need of the following example:
A datagrid  with 8 rows containing a button, a result field. Plus a button
outside of the datagrid to query an update of one of the result field by
executing the code of one of the button. Do you have different scripts for
each button?


On Sun, Aug 5, 2018 at 5:21 PM, Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:

> You can get/put data from/into the grid one row at a time without needing
> to figure out the group name, so you could have it update in real time in
> your external button. You should be able to use the same behavior script
> (possibly with a slight modification) everywhere.
>
> I’m not at a computer right now so I will work out an example later if
> someone else doesn’t beat me to it.
>
> Thanks,
> Brian
> On Aug 5, 2018, 10:02 AM -0500, Douglas Ruisaard , wrote:
> > Thanks very much for the reply.
> > Good question .. made me think about why that won't work very well for
> me (but it would, of course, work).
> >
> > The button on each row not only queries the associated wi-fi module, but
> the "mouseUp" handler in the Behavior Script acquires a response back from
> each module. That message gets put into one of the fields in the row... so
> even if I didn't try to make a "mouseUp" call to within the row, I'd still
> want to populate each of the row's fields with the returning result...
> which would, of course, entail using the pseudo-group names again... *if* I
> wanted to display the returning information for each row "in real time"...
> which I do.
> >
> > There are two simple solutions, one of which I have done. Expand the
> grid to show all 8 rows and the scrolling issue disappears. Or ... as you
> suggest, "acquire" each row's data "outside" of the grid and then just
> display the complete set of data at once. Currently I do the former. Works
> very well on my big desktop monitor but not very "practical" to port to my
> iPad or Android... or any small display device.
> >
> > Another caveat is that each call to a wi-fi module take about 1 second
> to complete. This is a function of the module and what I am asking it to
> do... NOT an issue with "tsnet" (which is great!). So, taking the latter
> (your) approach, I'd lose the "real time" aspect and have to wait
> (#-of-modules * 1 second) before seeing any results. Currently that would
> be 8 seconds... not a *long* wait but annoying (in this age of microsecond
> responses). Expanding the project to more modules, obviously, increase the
> wait time... and I like the real-time display.
> >
> 

Re: valueDiff for arrays?

[David Glasgow via use-livecode]

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 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 liquid.
> 
> Maybe I cook too much. In any case, the solids (what remains after filtering) 
> are the things you're either keeping or discarding.
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
>> On August 5, 2018 9:38:45 AM Brian Milby via use-livecode 
>>  wrote:
>> 
>> 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 tFoo[each] is not tBar[each]
>> (And to get Richard’s result you would need to follow this by an intersect 
>> each way. The filter would replace the repeat loop in Mark’s solution)
>> 
>> 
>> Even though “with where” would be syntactically correct, the preferred usage 
>> would be “keeping where”.
>> 
>> Thanks,
>> Brian
>>> On Aug 5, 2018, 7:32 AM -0500, Mark Waddingham via use-livecode 
>>> , wrote:
>>> 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
>>> > 
>>> >
>>> > Examples:
>>> > local tFoo,tBar
>>> > put "foo" into tFoo[1]
>>> > put "bar" into tFoo[2]
>>> > put "baz" into tBar[1]
>>> > put "bar" into tBar[2]
>>> > filter keys of tFoo with expression tFoo[each] is tBar[each]
>>> > — tFoo now has one key 2 which is `bar`
>>> >
>>> > put “yes,foo” & return & “no,bar” into tFoo
>>> > filter lines of tFoo with expression item 1 of each is “yes”
>>> >
>>> > We could feasibly not use `with|without` for this forcing the
>>> > expression to return true to filter. If we went that way then perhaps
>>> > `where` would be nicest?
>>> >
>>> > filter lines of tFoo where item 1 of each is “yes”
>>> 
>>> Geez @Monte - you do like creating work for me don't you! ;)
>>> 
>>> In terms of syntax - definitely not 'with expression' - that's ghastly.
>>> It is a 'where' clause - in the same vein as SQL and other query
>>> languages - so no bike-shedding required there (also, pleasingly, all
>>> other 'filter' types become sugar for a where clause using operators
>>> which the language does not have yet - but obviously we have the code
>>> for...).
>>> 
>>> If we are going to bike-shed over syntax - can we do so over the use of
>>> 'filter' itself. I don't know why but I have a complete mental block
>>> about it - regardless of how many times I use it or read it - I always
>>> have to 'double-think' to work out what form to use - is that just me?
>>> 
>>> filter  of X with Y
>>> filter  of X without Y
>>> 
>>> I couldn't tell you just by looking *what* they actually do. I'm not
>>> sure why but I think the verb is actually wrong - in all cases you have
>>> a set of things and you are either keeping an element, or removing an
>>> element... So I wonder if:
>>> 
>>> keep  of X where Y
>>> discard  of X where Y
>>> 
>>> (I'm not particularly attached to keep/discard - but it does need to be
>>> a pair of 'true' antonyms which don't intersect with any other 'core'
>>> pairs of such things we have).
>>> 
>>> Might be more appropriate?
>>> 
>>> Of course, maybe it is just 'with' / 'without' are inappropriate, and
>>> 'where' might actually help me retrain my mind to see with/without as
>>> the sugar they truly are.
>>> 
>>> Anyway, thought it worth throwing out there to see what people think?
>>> 
>>> 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
>> ___
>> 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.ru

Re: valueDiff for arrays?

[Mark Waddingham via use-livecode]

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 solids. Filtering "without" dumps
them and keeps the liquid.


I honestly can't see how:

filter lines of X with Y

Is less contorted and more natural language than:

filter X by keeping lines matching Y

The former *requires* 'arcane' knowledge to comprehend (it is a 
significant contraction of concepts - you need to know the contractions 
precisely to understand it!) - the latter does precisely what it says - 
it is actually a fully correct and full English sentence...


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: valueDiff for arrays?

[J. Landman Gay via use-livecode]

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


Maybe I cook too much. In any case, the solids (what remains after 
filtering) are the things you're either keeping or discarding.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On August 5, 2018 9:38:45 AM Brian Milby via use-livecode 
 wrote:



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 tFoo[each] is not tBar[each]
(And to get Richard’s result you would need to follow this by an intersect 
each way. The filter would replace the repeat loop in Mark’s solution)



Even though “with where” would be syntactically correct, the preferred 
usage would be “keeping where”.


Thanks,
Brian
On Aug 5, 2018, 7:32 AM -0500, Mark Waddingham via use-livecode 
, wrote:

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
> 
>
> Examples:
> local tFoo,tBar
> put "foo" into tFoo[1]
> put "bar" into tFoo[2]
> put "baz" into tBar[1]
> put "bar" into tBar[2]
> filter keys of tFoo with expression tFoo[each] is tBar[each]
> — tFoo now has one key 2 which is `bar`
>
> put “yes,foo” & return & “no,bar” into tFoo
> filter lines of tFoo with expression item 1 of each is “yes”
>
> We could feasibly not use `with|without` for this forcing the
> expression to return true to filter. If we went that way then perhaps
> `where` would be nicest?
>
> filter lines of tFoo where item 1 of each is “yes”

Geez @Monte - you do like creating work for me don't you! ;)

In terms of syntax - definitely not 'with expression' - that's ghastly.
It is a 'where' clause - in the same vein as SQL and other query
languages - so no bike-shedding required there (also, pleasingly, all
other 'filter' types become sugar for a where clause using operators
which the language does not have yet - but obviously we have the code
for...).

If we are going to bike-shed over syntax - can we do so over the use of
'filter' itself. I don't know why but I have a complete mental block
about it - regardless of how many times I use it or read it - I always
have to 'double-think' to work out what form to use - is that just me?

filter  of X with Y
filter  of X without Y

I couldn't tell you just by looking *what* they actually do. I'm not
sure why but I think the verb is actually wrong - in all cases you have
a set of things and you are either keeping an element, or removing an
element... So I wonder if:

keep  of X where Y
discard  of X where Y

(I'm not particularly attached to keep/discard - but it does need to be
a pair of 'true' antonyms which don't intersect with any other 'core'
pairs of such things we have).

Might be more appropriate?

Of course, maybe it is just 'with' / 'without' are inappropriate, and
'where' might actually help me retrain my mind to see with/without as
the sugar they truly are.

Anyway, thought it worth throwing out there to see what people think?

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

___
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: datagrid scrolling question

[Brian Milby via use-livecode]

You can get/put data from/into the grid one row at a time without needing to 
figure out the group name, so you could have it update in real time in your 
external button. You should be able to use the same behavior script (possibly 
with a slight modification) everywhere.

I’m not at a computer right now so I will work out an example later if someone 
else doesn’t beat me to it.

Thanks,
Brian
On Aug 5, 2018, 10:02 AM -0500, Douglas Ruisaard , wrote:
> Thanks very much for the reply.
> Good question .. made me think about why that won't work very well for me 
> (but it would, of course, work).
>
> The button on each row not only queries the associated wi-fi module, but the 
> "mouseUp" handler in the Behavior Script acquires a response back from each 
> module. That message gets put into one of the fields in the row... so even if 
> I didn't try to make a "mouseUp" call to within the row, I'd still want to 
> populate each of the row's fields with the returning result... which would, 
> of course, entail using the pseudo-group names again... *if* I wanted to 
> display the returning information for each row "in real time"... which I do.
>
> There are two simple solutions, one of which I have done. Expand the grid to 
> show all 8 rows and the scrolling issue disappears. Or ... as you suggest, 
> "acquire" each row's data "outside" of the grid and then just display the 
> complete set of data at once. Currently I do the former. Works very well on 
> my big desktop monitor but not very "practical" to port to my iPad or 
> Android... or any small display device.
>
> Another caveat is that each call to a wi-fi module take about 1 second to 
> complete. This is a function of the module and what I am asking it to do... 
> NOT an issue with "tsnet" (which is great!). So, taking the latter (your) 
> approach, I'd lose the "real time" aspect and have to wait (#-of-modules * 1 
> second) before seeing any results. Currently that would be 8 seconds... not a 
> *long* wait but annoying (in this age of microsecond responses). Expanding 
> the project to more modules, obviously, increase the wait time... and I like 
> the real-time display.
>
> However, this is as much a learning exercise as anything else... so I still 
> would greatly appreciate if you or anyone could suggest an alternative 
> methodology for issuing any sort of message to a datagrid, if there is one. 
> Perhaps my method *is* the only one. THAT would be valuable information to 
> have, as well.
>
> Douglas Ruisaard
> Trilogy Software
> (250) 573-3935
>
> From: Brian Milby [mailto:br...@milby7.com]
> Subject: Re: datagrid scrolling question
>
> > My question is why use the button? Loop through the data in the grid and 
> > make the tsnet call manually for each line.
> > If the button is calling a script outside of the DG, then you can use the 
> > same call.
> > Then you don’t have to do any of those things to figure out the name of the 
> > row group.
>
___
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: valueDiff for arrays?

[Brian Milby via use-livecode]

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 the chunk type optional. It would make readability less 
obvious but no less than today.

My guess is that retaining the earlier form (backwards compatibility) would be 
easy since the parser just needs to switch based on the third token being “by”. 
The new form would be placed as the first one checked to make it the fastest to 
parse.

Thanks,
Brian
On Aug 5, 2018, 9:38 AM -0500, Mark Waddingham via use-livecode 
, wrote:
> 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 is that
> 'filter' by itself is not sufficient to suggest the operation the filter
> is performing - it is too general a term. However...
>
> I think Brian's suggestion of modifiers is actually much closer to the
> most appropriate syntax because they naturally work well with or without
> an 'into' clause. Contrast (with a minor tweak to @Brian's suggestion):
>
> keep lines of X [ where | matching | not matching ] Y -- seems okay
> keep lines of X [ where | matching | not matching ] Y into Z -- seems
> contorted
>
> discard lines of X [ where | matching | not matching ] Y -- seems okay
> discard lines of X [ where | matching | not matching ] Y into Z --
> ambiguous, are the discarded lines going into Z, or the ones which
> aren't discarded?
>
> In contrast here are two potential forms with modifiers:
>
> A: filter X by ( keeping | discarding ) lines ( where | [ not ] matching
> | with | without ) Y [ into Z ]
>
> B: filter lines of X by keeping those ( where | [ not ] matching | with
> | without ) Y [ into Z ]
>
> In terms of these (A) I think is preferable - simply because we already
> use 'by' in the language - rather than 'those'; further it strongly
> suggests that the process 'moves' X to Z - by parsing the chunks of X
> through some filter defined by Y.
>
> The actual fundamental operation here is:
>
> Filter(source, chunk, predicate, target)
>
> Where predicate is formed as follows (assuming we had operators matching
> wildcard / matching pattern!):
>
> 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 wildcard P)
>
> discarding where P -> not P
> discarding with P -> not (each matches wildcard P)
> discarding without P -> each matches wildcard P
> discarding matching P -> not (each matches pattern P)
> discarding not matching P -> each matches wildcard P
>
> So the actual underling operation is the same: P is a boolean predicate
> operating on 'each', where each is taken to be each 'chunk' of X in
> turn; if P(each) returns true, the element is kept, otherwise it is
> discarded.
>
> I quite like the above - it has a very simple underbelly (a single
> operation!), but the actual English-like syntax is a true and correct
> sentence.
>
> What do people think?
>
> 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
___
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: datagrid scrolling question

[Douglas Ruisaard via use-livecode]

Thanks very much for the reply.
Good question .. made me think about why that won't work very well for me (but 
it would, of course, work).

The button on each row not only queries the associated wi-fi module, but the 
"mouseUp" handler in the Behavior Script acquires a response back from each 
module.  That message gets put into one of the fields in the row... so even if 
I didn't try to make a "mouseUp" call to within the row, I'd still want to 
populate each of the row's fields with the returning result... which would, of 
course, entail using the pseudo-group names again... *if* I wanted to display 
the returning information for each row "in real time"... which I do.

There are two simple solutions, one of which I have done.  Expand the grid to 
show all 8 rows and the scrolling issue disappears.  Or ... as you suggest, 
"acquire" each row's data "outside" of the grid and then just display the 
complete set of data at once.  Currently I do the former.  Works very well on 
my big desktop monitor but not very "practical" to port to my iPad or 
Android... or any small display device.

Another caveat is that each call to a wi-fi module take about 1 second to 
complete.  This is a function of the module and what I am asking it to do... 
NOT an issue with "tsnet" (which is great!).  So, taking the latter (your) 
approach, I'd lose the "real time" aspect and have to wait (#-of-modules * 1 
second) before seeing any results.  Currently that would be 8 seconds... not a 
*long* wait but annoying (in this age of microsecond responses).  Expanding the 
project to more modules, obviously, increase the wait time... and I like the 
real-time display.

However, this is as much a learning exercise as anything else... so I still 
would greatly appreciate if you or anyone could suggest an alternative 
methodology for issuing any sort of message to a datagrid, if there is one.  
Perhaps my method *is* the only one.  THAT would be valuable information to 
have, as well.

Douglas Ruisaard
Trilogy Software
(250) 573-3935

From: Brian Milby [mailto:br...@milby7.com] 
Subject: Re: datagrid scrolling question

> My question is why use the button? Loop through the data in the grid and make 
> the tsnet call manually for each line.
> If the button is calling a script outside of the DG, then you can use the 
> same call. 
> Then you don’t have to do any of those things to figure out the name of the 
> row group.


___
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: valueDiff for arrays?

[Mark Waddingham via use-livecode]

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 is that 
'filter' by itself is not sufficient to suggest the operation the filter 
is performing - it is too general a term. However...


I think Brian's suggestion of modifiers is actually much closer to the 
most appropriate syntax because they naturally work well with or without 
an 'into' clause. Contrast (with a minor tweak to @Brian's suggestion):


keep lines of X [ where | matching | not matching ] Y -- seems okay
keep lines of X [ where | matching | not matching ] Y into Z -- seems 
contorted


discard lines of X [ where | matching | not matching ] Y -- seems okay
discard lines of X [ where | matching | not matching ] Y into Z -- 
ambiguous, are the discarded lines going into Z, or the ones which 
aren't discarded?


In contrast here are two potential forms with modifiers:

A: filter X by ( keeping | discarding ) lines ( where | [ not ] matching 
| with | without ) Y [ into Z ]


B: filter lines of X by keeping those ( where | [ not ] matching | with 
| without ) Y [ into Z ]


In terms of these (A) I think is preferable - simply because we already 
use 'by' in the language - rather than 'those'; further it strongly 
suggests that the process 'moves' X to Z - by parsing the chunks of X 
through some filter defined by Y.


The actual fundamental operation here is:

  Filter(source, chunk, predicate, target)

Where predicate is formed as follows (assuming we had operators matching 
wildcard / matching pattern!):


  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 wildcard P)

  discarding where P -> not P
  discarding with P -> not (each matches wildcard P)
  discarding without P -> each matches wildcard P
  discarding matching P -> not (each matches pattern P)
  discarding not matching P -> each matches wildcard P

So the actual underling operation is the same: P is a boolean predicate 
operating on 'each', where each is taken to be each 'chunk' of X in 
turn; if P(each) returns true, the element is kept, otherwise it is 
discarded.


I quite like the above - it has a very simple underbelly (a single 
operation!), but the actual English-like syntax is a true and correct 
sentence.


What do people think?

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: valueDiff for arrays?

[Brian Milby via use-livecode]

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 tFoo[each] is not tBar[each]
(And to get Richard’s result you would need to follow this by an intersect each 
way. The filter would replace the repeat loop in Mark’s solution)


Even though “with where” would be syntactically correct, the preferred usage 
would be “keeping where”.

Thanks,
Brian
On Aug 5, 2018, 7:32 AM -0500, Mark Waddingham via use-livecode 
, wrote:
> 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
> > 
> >
> > Examples:
> > local tFoo,tBar
> > put "foo" into tFoo[1]
> > put "bar" into tFoo[2]
> > put "baz" into tBar[1]
> > put "bar" into tBar[2]
> > filter keys of tFoo with expression tFoo[each] is tBar[each]
> > — tFoo now has one key 2 which is `bar`
> >
> > put “yes,foo” & return & “no,bar” into tFoo
> > filter lines of tFoo with expression item 1 of each is “yes”
> >
> > We could feasibly not use `with|without` for this forcing the
> > expression to return true to filter. If we went that way then perhaps
> > `where` would be nicest?
> >
> > filter lines of tFoo where item 1 of each is “yes”
>
> Geez @Monte - you do like creating work for me don't you! ;)
>
> In terms of syntax - definitely not 'with expression' - that's ghastly.
> It is a 'where' clause - in the same vein as SQL and other query
> languages - so no bike-shedding required there (also, pleasingly, all
> other 'filter' types become sugar for a where clause using operators
> which the language does not have yet - but obviously we have the code
> for...).
>
> If we are going to bike-shed over syntax - can we do so over the use of
> 'filter' itself. I don't know why but I have a complete mental block
> about it - regardless of how many times I use it or read it - I always
> have to 'double-think' to work out what form to use - is that just me?
>
> filter  of X with Y
> filter  of X without Y
>
> I couldn't tell you just by looking *what* they actually do. I'm not
> sure why but I think the verb is actually wrong - in all cases you have
> a set of things and you are either keeping an element, or removing an
> element... So I wonder if:
>
> keep  of X where Y
> discard  of X where Y
>
> (I'm not particularly attached to keep/discard - but it does need to be
> a pair of 'true' antonyms which don't intersect with any other 'core'
> pairs of such things we have).
>
> Might be more appropriate?
>
> Of course, maybe it is just 'with' / 'without' are inappropriate, and
> 'where' might actually help me retrain my mind to see with/without as
> the sugar they truly are.
>
> Anyway, thought it worth throwing out there to see what people think?
>
> 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
___
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: valueDiff for arrays?

[Brian Milby via use-livecode]

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
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: valueDiff for arrays?

[Brian Milby via use-livecode]

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} [{wildcard | regex}] filterPattern | where filterExpression} 
[into targetContainer]

“matching” was added in 6 which would probably be clearer.

Thanks,
Brian

___
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: valueDiff for arrays?

[Mark Waddingham via use-livecode]

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


Examples:
local tFoo,tBar
put "foo" into tFoo[1]
put "bar" into tFoo[2]
put "baz" into tBar[1]
put "bar" into tBar[2]
filter keys of tFoo with expression tFoo[each] is tBar[each]
— tFoo now has one key 2 which is `bar`

put “yes,foo” & return & “no,bar” into tFoo
filter lines of tFoo with expression item 1 of each is “yes”

We could feasibly not use `with|without` for this forcing the
expression to return true to filter. If we went that way then perhaps
`where` would be nicest?

filter lines of tFoo where item 1 of each is “yes”


Geez @Monte - you do like creating work for me don't you! ;)

In terms of syntax - definitely not 'with expression' - that's ghastly. 
It is a 'where' clause - in the same vein as SQL and other query 
languages - so no bike-shedding required there (also, pleasingly, all 
other 'filter' types become sugar for a where clause using operators 
which the language does not have yet - but obviously we have the code 
for...).


If we are going to bike-shed over syntax - can we do so over the use of 
'filter' itself. I don't know why but I have a complete mental block 
about it - regardless of how many times I use it or read it - I always 
have to 'double-think' to work out what form to use - is that just me?


  filter  of X with Y
  filter  of X without Y

I couldn't tell you just by looking *what* they actually do. I'm not 
sure why but I think the verb is actually wrong - in all cases you have 
a set of things and you are either keeping an element, or removing an 
element... So I wonder if:


  keep  of X where Y
  discard  of X where Y

(I'm not particularly attached to keep/discard - but it does need to be 
a pair of 'true' antonyms which don't intersect with any other 'core' 
pairs of such things we have).


Might be more appropriate?

Of course, maybe it is just 'with' / 'without' are inappropriate, and 
'where' might actually help me retrain my mind to see with/without as 
the sugar they truly are.


Anyway, thought it worth throwing out there to see what people think?

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: valueDiff for arrays?

[Mark Waddingham via use-livecode]

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 tArray2[each]


Not quite - if I understand Richard's request correctly, and the code 
which has been presented

then it cannot be done by a single filter on one array.

The result he is asking for requires information from both arrays, some 
of which may not be shared.


The above only contains information from tArray1.

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