Very interesting discussion! I'm still curious though. Since the op
already takes the json based file and turns it into an array ( probably
using an existing json library.) Since this step is already done, and the
array esists, is there an actual benefit to then breaking that array into
Hi Mark,
There's a reason why I haven't posted the code of explodeRow... but I'm sure
it _could_ be efficient!
Thanks for reminding me about split with one delimiter - I never use that.
I think when I first encountered it I was so annoyed by the thought that it
was pointless, because what I
Apologies - I clicked the wrong button in my email client and managed to
send a partially composed message. Here is the correct version!
On 2016-11-08 12:48, Ben Rubinstein wrote:
The point is that in my first pattern, I have outside the loop
assigned column (item) indices to named variables
On 2016-11-08 12:48, Ben Rubinstein wrote:
The point is that in my first pattern, I have outside the loop
assigned column (item) indices to named variables (based on the items
of the first, header, row). In the loop LC then has to locate the
indexed items in an individual data row.
In the
On 07/11/2016 18:05, Richard Gaskin wrote:
I wouldn't care to hazard a guess as to the relative speed of
"aData[x]" versus "item x": but it's the overhead of the function
which creates the array on that I don't want to pay *on every row*.
The function call itself has very small overheard.
On Mon, Nov 7, 2016 at 1:21 AM, Mark Wieder wrote:
> But maybe Bramanathaswami has some special use case?
Assuming that is the case then 'do' is the answer and you'll find an
example in the Dictionary under the 'local' command; the last example.
Unfortunately the example
Ben Rubinstein wrote:
> On 07/11/2016 16:52, Richard Gaskin wrote:
>> On the one hand, each array access requires a small amount of
>> overhead to run the key through a hash to find the value's address.
>> However, that overhead is pretty small...
>
> No, no - the meat here is this:
>
>> do
On 07/11/2016 16:52, Richard Gaskin wrote:
But more seriously, the meat here is this:
doSomething item viUserID of tRec, item viUserName of tRec
...vs:
doSomething aData["User ID"], aData["User Name"]
On the one hand, each array access requires a small amount of overhead to run
the
On Mon, Nov 7, 2016 at 8:52 AM, Richard Gaskin
wrote:
> There's your first bug right there - that should be:
>
> do makeAccessVars("emacs", line 1 of tTSVdata)
>
damned heretics are everywhere . . .
:)
--
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
Ben Rubinstein wrote:
> So the typical routine is something like
>
>do makeAccessVars("vi", line 1 of tTSVdata)
There's your first bug right there - that should be:
do makeAccessVars("emacs", line 1 of tTSVdata)
(Ducking from Mark Wieder who will no doubt groan at the pun )
But
On 07/11/2016 15:02, Richard Gaskin wrote:
Ben Rubinstein wrote:
(Re Mike and Mark's comments, if it's a small thing I'll use an
array; but for large quantities of data - I'm often dealing with
very large files, and after calling this function will loop over
tens or hundreds of thousands of
Ben Rubinstein wrote:
> (Re Mike and Mark's comments, if it's a small thing I'll use an
> array; but for large quantities of data - I'm often dealing with
> very large files, and after calling this function will loop over
> tens or hundreds of thousands of rows using the variables - I feel
> the
It's easy to dynamically create and set the values of variables, using the
"do" command, e.g.:
do format("put tValue into %s", tVarName)
I do lots of work with TSV files, which have a first row of field names, and
for years have used a function like this to create local variables,
g
--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/How-can-we-dynamically-create-variable-names-from-changing-value-x-on-a-loop-tp4710128p4710142.html
Sent from the Revolution - User mailing list archive at Nabble.com.
_
Why not just leave it as an array? In fact, if you want to have separate
preferences categories, that's easy enough to do too.
local sPrefsA
put getPref ("preferences/modules/color-meditation") into
sPrefsA[ColorMedPrefs]
at this point you have an local script array variable structured like
Given this scenario:
We fetch a preference array from some json on disk
We want to insert the key-values into separate discrete local vars in the stack
script
function getUserPreferences
# the following function fetches an object in a JSON file:
put getPref
16 matches
Mail list logo