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.
>
> ...
> On 6 Aug 2018, at 1:57 pm, Brian Milby via use-livecode
> wrote:
>
> Just tried that and it adds .7 sec (returning the unsorted keys). The sort
> in the original takes around .7s. There are only 446 primes found at that
> point. Returning an array is about the same time as returning an
Just tried that and it adds .7 sec (returning the unsorted keys). The sort
in the original takes around .7s. There are only 446 primes found at that
point. Returning an array is about the same time as returning an unsorted
R.
On Sun, Aug 5, 2018 at 10:28 PM, Monte Goulding via use-livecode <
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
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
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
I’m fairly sure you could speed it up by continuing to add keys to p and
returning that instead of building the list R.
> On 6 Aug 2018, at 1:24 pm, Brian Milby via use-livecode
> wrote:
>
> I can speed it up by 10% just be replacing the "add 1 to" with "put true
> into". The first if would
> On 6 Aug 2018, at 1:15 pm, Mark Wieder via use-livecode
> wrote:
>
> Interesting. And here I was just assuming that true and false were boolean
> constants, like in any other language. So empty is a constant and one is a
> constant, but true and false are not. Wouldn't things be faster if
I can speed it up by 10% just be replacing the "add 1 to" with "put true
into". The first if would lose the ">0". A single pass went from 50s to
44s on my iMac.
On Sun, Aug 5, 2018 at 9:36 PM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:
> Mark Waddingham wrote:
>
>
On 08/05/2018 05:42 PM, Monte Goulding via use-livecode wrote:
I was describing a situation where you are forcing something that is not a boolean
to be one so true is true and everything else is false. You are describing comparing
something to a boolean in which case rightly or wrongly both
I posted a stack with the valueDiff code tests that I was doing if anyone
is interrested:
https://milby.us/lc/ValueDiff.livecode.zip
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage
Mark Waddingham wrote:
> On 2018-08-05 21:22, Richard Gaskin via use-livecode wrote:
>> Mark Waddingham wrote:
>>
>>> In your use-case for 'valueDiff' - do you need to tell the
>>> difference between a key value being the empty string and
>>> a key value not being present at all?
>>
>> In my own
Mark Waddingham wrote:
> Richard wrote:
>>
>> Thinking about performance, I wonder if there's anything from some of
>> the changes that have boosted PHP 7's performance so far above its
>> earlier versions which may be relevant for LC:
>>
On 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
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
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
> On 6 Aug 2018, at 9:55 am, Mark Wieder via use-livecode
> wrote:
>
> on something p1, p2, p3
> if p1 is false then
>-- fails if p1 is empty
> end if
> if p1 is true then
>-- also fails if p1 is empty
> end if
> end something
I was describing a situation where you are forcing
On 08/05/2018 04:37 PM, Monte Goulding via use-livecode wrote:
Actually you need to be careful to remember not to put not before a boolean
expression without putting parenthesis around the expression because anything
that is not “true” in LC evaluates to false. For example:
That's generally
> On 6 Aug 2018, at 8:03 am, Mark Wieder via use-livecode
> wrote:
>
> True, but syntacticly I like the idea of being able to place "not" in front
> of any boolean without having to remember where it's legal and where it's
> not. I also think it's harder on the engine (this off the top of
Earlier in this thread it was mentioned that LCS doing a loop once would
probably outpace the engine looping 2 times + a LCS loop at some point. I
decided to see if I could figure out a point where this might take place.
My test was pretty simple. I set a target number of elements for each
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
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
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
On 2018-08-06 00:07, Brian Milby via use-livecode wrote:
So this syntax:
filter filterSource by [keeping | discarding] [[the] {lines | items |
keys
| elements}] {matching [wildcard | regex] pattern filterPattern | where
filterExpression} [into targetContainer]
Would allow a shortened version:
On 2018-08-06 00:03, Mark Wieder via use-livecode wrote:
On 08/05/2018 02:48 PM, Monte Goulding via use-livecode wrote:
On 6 Aug 2018, at 7:07 am, Mark Waddingham via use-livecode
wrote:
filter X by keeping the lines not matching pattern "regex"
My point was this statement can be
On 8/5/18 4:07 PM, Mark Waddingham via use-livecode wrote:
But this isn't cooking - this is coding, so in this case you need to
read the docs to find out what the default mode of filter is. (Of
course, this might entirely be one of those things that my brain just
won't get, or ever get - so it
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
So this syntax:
filter filterSource by [keeping | discarding] [[the] {lines | items | keys
| elements}] {matching [wildcard | regex] pattern filterPattern | where
filterExpression} [into targetContainer]
Would allow a shortened version:
filter X by matching pattern "regex" into Z
Which would
On 08/05/2018 02:48 PM, Monte Goulding via use-livecode wrote:
On 6 Aug 2018, at 7:07 am, Mark Waddingham via use-livecode
wrote:
filter X by keeping the lines not matching pattern "regex"
My point was this statement can be written as both:
filter X by keeping the lines not matching
On 2018-08-05 23:48, Monte Goulding via use-livecode wrote:
On 6 Aug 2018, at 7:07 am, Mark Waddingham via use-livecode
wrote:
filter X by keeping the lines not matching pattern "regex"
My point was this statement can be written as both:
filter X by keeping the lines not matching pattern
> On 6 Aug 2018, at 7:07 am, Mark Waddingham via use-livecode
> wrote:
>
> filter X by keeping the lines not matching pattern "regex"
My point was this statement can be written as both:
filter X by keeping the lines not matching pattern “regex"
and
filter X by discarding the lines
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 -
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
On 2018-08-05 22:37, Monte Goulding via use-livecode wrote:
I think it’s nice sugar but it adds complexity when trying to
understand the statement. You need to comprehend the expression or
pattern then comprehend the relationship between discarding/keeping
and with | without | not matching |
On 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,
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
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
> On 6 Aug 2018, at 12:38 am, Mark Waddingham via use-livecode
> wrote:
>
> keeping where P -> P
> keeping with P -> each matches wildcard P
> keeping without P -> not (each matches wildcard P)
> keeping matching P -> each matches pattern P
> keeping not matching P -> not (each matches
> On 5 Aug 2018, at 10:32 pm, Mark Waddingham via use-livecode
> wrote:
>
> Geez @Monte - you do like creating work for me don't you! ;)
Aha.. sorry but I have been threatening to implement this for 2 years ;-)
Cheers
Monte
___
use-livecode
Intersect is an engine implementation of something that can be done in pure
LCS. I wrote a version of the function you needed that only used LCS without
the engine optimized functions. My function only iterates over an array once
(instead of 3 times) yet takes twice as long. It deletes keys
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,
>
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
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
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?
On 2018-08-05 21:25, Richard Gaskin via use-livecode wrote:
Brian Milby wrote:
I think Mark's code had a typo (left returned too many keys), but even
when corrected it takes half the time as a pure LCS solution. Here's
my modification:
function bwmValueDiff pLeft, pRight
local tResult
On 2018-08-05 21:22, Richard Gaskin via use-livecode wrote:
Mark Waddingham wrote:
In your use-case for 'valueDiff' - do you need to tell the difference
between a key value being the empty string and a key value not being
present at all?
In my own head, any name-value pair, even one in which
Brian Milby wrote:
> I think Mark's code had a typo (left returned too many keys), but even
> when corrected it takes half the time as a pure LCS solution. Here's
> my modification:
>
> function bwmValueDiff pLeft, pRight
>local tResult
>intersect pLeft with pRight into tResult["1"]
>
Mark Waddingham wrote:
> In your use-case for 'valueDiff' - do you need to tell the difference
> between a key value being the empty string and a key value not being
> present at all?
In my own head, any name-value pair, even one in which the value is an
empty string, is worth taking into
"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"
It's just a case of refactoring but some further thought is required even about
the current filter improvement.
By creating a revised form of filter, for example, we have the option of making
'matches' take an RE and not a glob (shell wildcard expr). Yes REs are more
complicated but much more
On 08/05/2018 11:20 AM, Mark Waddingham via use-livecode wrote:
That isn't overloading put - that's introducing query expressions...
Which would (at least as far as filter currently goes - I have another as yet
unstated reason for suggesting a revised syntax beyond stopping my own mental
That isn't overloading put - that's introducing query expressions...
Which would (at least as far as filter currently goes - I have another as yet
unstated reason for suggesting a revised syntax beyond stopping my own mental
torture!) eliminate the need for filter into.
e.g
the lines of X
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
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
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
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
I think "filter" is culinary enough. Coffee filters do the same thing, only
they filter without. :)
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On August 5, 2018 11:53:11 AM Mark Waddingham via use-livecode
wrote:
Well...
strain
Yes, yours is natural. Some of the others were stretching it a bit.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On August 5, 2018 11:10:47 AM Mark Waddingham via use-livecode
wrote:
On 2018-08-05 17:36, J. Landman Gay via
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
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
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
Maybe 'strain' could be a culinary synonym?
;-)
Best wishes
David Glasgow
Sent from my iPad via iBrain & iFingers
LinkedIn
> On 5 Aug 2018, at 16:36, J. Landman Gay via use-livecode
> wrote:
>
> This is getting pretty contorted and is becoming less like natural language.
> For what it's
On 2018-08-05 17:36, J. Landman Gay via use-livecode wrote:
This is getting pretty contorted and is becoming less like natural
language. For what it's worth, I have never been confused by the
current use of filter. I think of it as pouring soup through a wire
strainer. Filtering "with" keeps the
This is getting pretty contorted and is becoming less like natural
language. For what it's worth, I have never been confused by the current
use of filter. I think of it as pouring soup through a wire strainer.
Filtering "with" keeps the solids. Filtering "without" dumps them and keeps
the
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
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
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
On 2018-08-05 16:00, Brian Milby wrote:
Or to include new modifiers:
{keeping | discarding | with | without | [not] matching}
Which if not using the “into” form the first two make the
statement much clearer as to the intent.
So, I figured out my 'cognitive dissonance' on filter. The issue
Probably better:
filter [{lines | items | keys | elements} of] filterSource {keeping |
discarding | with | without | [not] matching} {[{wildcard | regex} pattern]
filterPattern | where filterExpression} [into targetContainer]
So Monte’s example would be:
filter keys of tFoo keeping where
Or to include new modifiers:
{keeping | discarding | with | without | [not] matching}
Which if not using the “into” form the first two make the statement much
clearer as to the intent.
Thanks,
Brian
___
use-livecode mailing list
Current
filter [{lines | items | keys | elements} of] filterSource {with | without |
[not] matching} [{wildcard pattern | regex pattern}] filterPattern [into
targetContainer]
Possible Suggestion
filter [{lines | items | keys | elements} of] filterSource {{with | without |
[not] matching}
On 2018-08-05 07:31, Monte Goulding via use-livecode wrote:
Given I have been wanting to do ^ for a couple of years I decided to
just go ahead and do it… might be a while before we have time to
bikeshed the syntax though.
https://github.com/livecode/livecode/pull/6626
On 2018-08-05 03:59, Monte Goulding via use-livecode wrote:
Just to throw it out there I still want to add `each` to filter one
day. So in this case I think it would be:
filter keys of tArray1 with expression \
each is among the keys of tArray2 and \
tArray1[each] is not
Same remark than Mike, James and Jacque. When you have to change the value
of each row, populating the datagrid with a new data, seems to be the
better way to go.
Now for helping you with datagrids, I think you have to understand 2
importants concepts about datagrids:
- rows groups are created on
74 matches
Mail list logo
