+5
Bob S
> On Aug 26, 2017, at 16:04 , Mark Wieder via use-livecode
> wrote:
>
> filter lines of tList WHERE item 1 of each >= 1 into someVariable
> and
> filter elements of tArray where "late fee" is in each into newArray
>
> --
> Mark Wieder
Thanks Brian…
We use MS office for enterprise now, So I have one drive and it came right thru.
On 8/26/17, 5:51 PM, "use-livecode on behalf of Brian Milby via use-livecode"
wrote:
Here is a link to
Here is a link to the file on OneDrive:
https://1drv.ms/u/s!Apo0Atd869AFkjiW39Xit7Rmmp4b
(https***1drv.ms/u/s!Apo0Atd869AFkjiW39Xit7Rmmp4b)
If that won't work, I can upload to the forum somewhere.
On Sat, Aug 26, 2017 at 10:30 PM, Sannyasin Brahmanathaswami via
use-livecode
Please do post your stack… over at the forums?
On 8/26/17, 12:21 PM, "use-livecode on behalf of Brian Milby via use-livecode"
wrote:
I'm using example 5 from this site for my JSON:
> On 27 Aug 2017, at 10:24 am, Mark Wieder via use-livecode
> wrote:
>
> Well, yes and no.
> I just wanted to make sure that the 'where' clause doesn't mean that we also
> can't have the 'into' clause.
Oh, sure I would expect if implemented that it wouldn’t
On 08/26/2017 04:11 PM, Monte Goulding via use-livecode wrote:
On 27 Aug 2017, at 9:04 am, Mark Wieder via use-livecode
wrote:
I assume that syntax would do what the filter command normally does in terms of
modifying the contents of tList. I'd also like to
> On 27 Aug 2017, at 9:04 am, Mark Wieder via use-livecode
> wrote:
>
> I assume that syntax would do what the filter command normally does in terms
> of modifying the contents of tList. I'd also like to see the form that
> returns the result rather than
On 08/26/2017 02:43 PM, Monte Goulding via use-livecode wrote:
On 27 Aug 2017, at 7:40 am, Phil Davis via use-livecode
wrote:
Another one I would like:
filter lines of tList WHERE item 1 of each >= 10
Yes I like that too… a tad more than `by`. It seems
You could set your needle to be a valid LCS expression. I just ran a test
using the following:
*do* "if (" & pNeedle & ") then put tPath into xFoundPaths[the number of
elements in xFoundPaths + 1]"
It took around 4x of the time to run though. I set my needle to "tElement
> 5000" for one test
> On 27 Aug 2017, at 7:40 am, Phil Davis via use-livecode
> wrote:
>
> Another one I would like:
>
> filter lines of tList WHERE item 1 of each >= 10
Yes I like that too… a tad more than `by`. It seems to read more naturally.
Cheers
Monte
On 8/26/17 2:23 PM, Monte Goulding via use-livecode wrote:
On 27 Aug 2017, at 5:57 am, J. Landman Gay via use-livecode
wrote:
This would be really useful. I'd suggest:
filter elements of tArray by tPath[each] is “baz”
Array paths don’t work like that. `each`
> On 27 Aug 2017, at 5:57 am, J. Landman Gay via use-livecode
> wrote:
>
> This would be really useful. I'd suggest:
>
> filter elements of tArray by tPath[each] is “baz”
Array paths don’t work like that. `each` here is the element and tPath is a
path within
This would be really useful. I'd suggest:
filter elements of tArray by tPath[each] is “baz”
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On August 26, 2017 1:14:59 AM Monte Goulding via use-livecode
Alex Tweedly wrote:
> I think regex (or multiple string comparisons) is too limited a way to
> go.
>
> I would want to be able to do numeric comparisons, range comparisons,
> etc.
>
> e.g. x is a number, x<25, 24 < x < 33, etc.
The problem of querying hierarchically-ordered data has been around
I think regex (or multiple string comparisons) is too limited a way to go.
I would want to be able to do numeric comparisons, range comparisons, etc.
e.g. x is a number, x<25, 24 < x < 33, etc.
-- Alex.
On 26/08/2017 05:05, Brian Milby via use-livecode wrote:
tElement isn't the part that
As a slightly related aside in this conversation I’d still one day like to add
`each` to filter:
— filter array and retain elements where element[“foo”][“bar”] = “baz"
put “foo” into tPath[1]
put “bar” into tPath[2]
filter elements of tArray by evaluating each[tPath] is “baz”
Cheers
Monte
tElement isn't the part that would change (you are still searching against
a single value in the array), you would need to modify the comparison to
allow for pNeedle to contain multiple values and the operators. It would
probably be easier to modify to use a RegEx. If you have 2 comma separated
I created a stack to do some testing to see about making a function that
could do multiple types of tests. What I found was that adding another if
at that point added about 6% to the search time and a second level (else
if) added another 10% (16% total). (I added a parameter for search type -
OK I will bite
what would an array representing an "AND/OR"
style query look like such that if used as a predicate
for
else if tElement contains pNeedle then
it would return true/false
How would you have to construct "tElement"
??
Mark: In terms of generalizing that function -
On 2017-08-25 17:43, Sannyasin Brahmanathaswami via use-livecode wrote:
@ Mark Waddingham
Awesome! thanks, I will test this later…
Yes, my solution, at the urging of our Cohorts of the Round Table
LiveCode Data Diggers,
who earlier said "Don't go looking for your needles in arrays." (
I just
@ Mark Waddingham
Awesome! thanks, I will test this later…
Yes, my solution, at the urging of our Cohorts of the Round Table LiveCode Data
Diggers,
who earlier said "Don't go looking for your needles in arrays." (
I just reformulated the SQL quaryand passed it back "up" to the stack script
On 2017-08-23 17:24, Sannyasin Brahmanathaswami via use-livecode wrote:
We use these arrays with media metadata that is extracted from our
database of media metadata. The dbase was originally designed for lots
of columns so that "there is nothing we cannot know about a media
item" incorporating
This will work with any array. It recursively calls itself as it encounters
arrays within arrays. I agree with Richard that if all you want is one shot at
an array to find the element(s) you are looking for, then this may (or may not)
be a cleaner approach, but I think if you are taking
Bob Sneidar wrote:
> I suppose thinking about it you could arrayencode an array then do a
> search on it
You probably don't want to do that. I've given a lot of thought to
methods of indexing large LSON files on disk, and I can find no method
anywhere near as practical as working with them
Bob: fascinating
[1] ["addr2"] ,[1] ["smtppassword"] none,[1] ["itemail"],[1]
["contactphone"] 661-257-1177,[1] ["contactonsite"] false, etc.
what about a 2 diminsional array
You can see from this format that you can convert to lines and then you can
filter
I've partially deciphered it. I created a tab delimited table of each
non-printing character followed by the text between that and the next
non-printing character. Here is a sample:
12 contactphone
8
0
12 661-257-1177
0
13 contactonsite
8
0
5
Okay it's not entirely straight forward. I took a simple array from a datagrid
with one record and ran this on it:
on mouseUp pButtonNumber
put the dgData of group "dgsites" into aSiteData
put arrayencode(aSiteData) into tSiteData
repeat for each char tChar in tSiteData
add 1 to
I mentioned a few years ago when arrays first were introduced that there ought
to be an engine based way to seach arrays for values, returning matching key
references (not just one but ALL). If you are only interested in certain keys
you could then filter the results.
To make this fast for
Sannyasin Brahmanathaswami wrote:
> OK so let's say user want sto search "blues" and I want the UX to
> check *all* columns in the array. What is the best way to do this?
...
> Is there a more efficient approach?
At my local Linux User Group last year a fella from NASA gave a
presentation
Sannyasin Brahmanathaswami wrote:
> I can't wait to use the new tools for watching processes to see where
> > bottle necks arise…
...
> did you see the pitch for business upgrade? scroll down.. there some
> new thing that give you time on processes
Thanks. I'd forgotten that was a new premium
Well thanks to all of you urging me to stay away from re-processing the array
but going back to the dbase.
I Looked back at my code and realized that I *had* set it up to be re-usable, I
just forgot how well I had done that
I have this function in the behavior_Listen which is attached to the
I think you need to use ":memory:" as the name actually. It looks (from
the sqlite docs) that supplying no name creates a temporary db file.
And now i'm curious.. Is there a way to attach the file based db to a
memory db?
IE Open the file database, then use the info here:
Yep… I just found that too.
and related 4-yr old discussion
http://use-livecode.runrev.narkive.com/ntBLeXGM/relative-performance-of-two-dimensional-array-and-in-memory-sqlite-database
What I don't get is
"don't give it a name"open/create in memory,
but the data is on SQLite dbase on
On 24/08/2017 01:04, Sannyasin Brahmanathaswami via use-livecode wrote:
2) "create an in-memory SQLite Database."
this is news! Where do we find docs on this? right now the SQLite data base
is in
specialFolderPath("documents")/jnanam.sqlite
how do you "create in memory?
According to
Alex, thanks, this is very helpful
1) put x into aFilteredPlayListIndex[z]
(there's no need to replicate all the data when the array will continue to
exist, just keep the indices you want).
awesome… I think I could increment the z from 1 up and then my clickline
number will still work.
2)
The media meta dbase "jnanam.item" table actually has 87 columns, ha! way over
kill, but I'm actually glad we did that because there is indeed "nothing we
cannot know about any media item in the universe"
But any given item… only uses a subset.
media_type = "audio/song"
and
media_type =
did you see the pitch for business upgrade? scroll down.. there some new thing
that give you time on processes
On 8/23/17, 9:28 AM, "use-livecode on behalf of Richard Gaskin via
use-livecode" wrote:
> I
On 23/08/2017 20:07, Sannyasin Brahmanathaswami via use-livecode wrote:
Bob, Mike,
thanks…"use the dbase" good thought
...
So then it comes down to whether doing a query semi-complex query that looks at
50,000 records and uses %like% against 3 columns is faster than iterating
loops on a
Sannyasin Brahmanathaswami wrote:
> I can't wait to use the new tools for watching processes to see where
> bottle necks arise…
?
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
Using equal queries is efficient *if* the columns are indexed. If you use LIKE,
I do not believe that the indexes are used, unless you employ some kind of full
text search indexing. Only certain databases support that.
Bob S
> On Aug 23, 2017, at 12:07 , Sannyasin Brahmanathaswami via
Bob, Mike,
thanks…"use the dbase" good thought
The reason we use the array is once we load that into a local than I use the
click line number of the song list (titles in a simple list field) to get the
data for that particular song.
click on line 9
get use everything we need from
I'm not going to disagree with the other replies
Plan A. use your database
Plan B. create an in-memory SQLite database.
Plan C. use an array, kind of like you are doing.
And *only* if there are good reasons for not doing Plans A or B, then :
C1. Instead of
repeat for each key x in
I'm with bob on this.. If for some reason you can't use the database that
produced the array, shove the data into an sqlite db instead. In memory, or
if you need persistence a db file.
Alternatively, if you store your data flat rather than in an array. Then
you can
repeat for each line tline
Oh wait I see you ARE using an SQL database to begin with. Why would you then
want to search an array?
Bob S
> On Aug 23, 2017, at 08:34 , Bob Sneidar via use-livecode
> wrote:
>
> Yes. Don't use an array, use a memory based sqLite table.
>
> Bob S
>
>
>>
Yes. Don't use an array, use a memory based sqLite table.
Bob S
> On Aug 23, 2017, at 08:24 , Sannyasin Brahmanathaswami via use-livecode
> wrote:
>
> OK I can make this work, (have to since I don't see another way)
>
> But it seems like a lot of looping.
>
We use these arrays with media metadata that is extracted from our database of
media metadata. The dbase was originally designed for lots of columns so that
"there is nothing we cannot know about a media item" incorporating DCIM columns
and also W3C media metadata initiative's recommended
46 matches
Mail list logo