Next goal, trying to be magnificant. :-)
Bob S
> On Oct 28, 2018, at 21:17 , J. Landman Gay via use-livecode
> wrote:
>
> Well, at least I have finally become "splendid" at something.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Yeah, I said something that was wrong - and I did apologize and will
happily do so again. And I managed to get "two people with one stone"
and mis-describe both your and Geoff's valuable inputs.
So I apologize again to both of you, and anyone else I inadvertently
knocked on the way past.
Thanks to everyone who helped me on this. Apologies if I misdirected the
discussion, but even that was very instructive.
My mouth hung open when I saw the cost of updating the progress bar every time
through a loop.
I guess I have become sloppy about time saving because most operations seem
> JLG wrote:
>
> > hh wrote:
> > Alex,
> > you and JLG are important LiveCoders. What you say has double weight.
> > From that alone you should double check what you claim to be true.
>
> Well, at least I have finally become "splendid" at something.
>
> I can't decide whether you are being
On 10/28/18 9:15 PM, hh via use-livecode wrote:
Alex,
you and JLG are important LiveCoders. What you say has double weight.
From that alone you should double check what you claim to be true.
Well, at least I have finally become "splendid" at something.
I can't decide whether you are being
Alex,
you and JLG are important LiveCoders. What you say has double weight.
>From that alone you should double check what you claim to be true.
Wrong assertions are no argument against a method but speed is one,
of course.
Anyway, it is fine that David G. has now a fast way to do his work.
(That said, yeah, repeat for each line is going to be faster)
On Sun, Oct 28, 2018 at 5:37 PM Geoff Canyon wrote:
>
>
> On Sun, Oct 28, 2018 at 5:27 PM Alex Tweedly via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> My apologies Hermann. I had not been following the original thread
On Sun, Oct 28, 2018 at 5:27 PM Alex Tweedly via use-livecode <
use-livecode@lists.runrev.com> wrote:
> My apologies Hermann. I had not been following the original thread
> closely, and got confused by the embedded quoting in the later messages.
> I was looking at Geoff's code - not yours - and
My apologies Hermann. I had not been following the original thread
closely, and got confused by the embedded quoting in the later messages.
I was looking at Geoff's code - not yours - and he explicitly said "
And of course if retaining the order isn't critical "
So I agree your array method
What's interesting with that is once again a comparison LC 6 against LC 9.
I tested with 1 lines of text (King James bible, Genesis up to 5|16) and
*non-wrapping fields*, separator tab:
LC 9.0.1 needs in average 370 ms for numbering, 330 ms for denumbering,
LC 6.7.11 needs in average 170 ms
> Alex T. wrote:
> You require to keep the line ordering completely unchanged -
> and Hermann's superfast method can't meet that need.
> JLG wrote:
> You're right, split deletes duplicates. In fact, I use it as a quick way
> to do just that.
You are both spendidly wrong:
Could you please
>> David G. wrote:
>> Thanks Geoff, I did play with Split, but one of the reasons for numbering
>> is to make any identical lines unique. With split, for any that are not,
>> all but one is deleted. So definitely not the result I wanted.
From that previous answer I concluded you intend to index
You're right, split deletes duplicates. In fact, I use it as a quick way
to do just that.
I don't see any way to add line numbers without looking at each line.
But you could keep a counter in a variable and put the text into an
array with the counter integer as the key. That might be faster
David,
I think you are correct - there is no magic version of split or array
that will do what you want.
You require to keep the line ordering completely unchanged - and
Hermann's superfast method can't meet that need.
The best solution (AFAIK) will be the one Mark Hsu and/or Jacqueline
Thanks for this, although I’m not sure I understand. In fact I am sure I
don’t.I know how amazingly fast the array method is, I use it elsewhere in
the same stack, and it is great.
I also don’t understand the distinction between line numbering and indexing.
If I was guessing, I would go
> David G. wrote:
> Thanks Geoff, I did play with Split, but one of the reasons for numbering
> is to make any identical lines unique. With split, for any that are not,
> all but one is deleted. So definitely not the result I wanted.
I am not Geoff (who played with the simple array methods I
Thanks Geoff, I did play with Split, but one of the reasons for numbering is to
make any identical lines unique. With split, for any that are not, all but one
is deleted. So definitely not the result I wanted.
I’ll sacrifice the progress bar and see where that leaves me.
Thanks folks.
> On
And of course if retaining the order isn't critical you could just go with:
function numberText T,D
split T by cr
combine T by cr and D
return T
end numberText
function unNumberText T,D
split T by cr and D
combine T by cr
return T
end unNumberText
On Sat, Oct 27, 2018 at 5:29
Sorry, missed a delimiter reference:
function numberText T,D
split T by return
put "1" & D & T[1] into R
repeat with K = 2 to item 2 of the extents of T
put cr & K & D & T[K] after R --> change separator here
end repeat
return R
end numberText
On Sat, Oct 27, 2018 at 5:27 PM
Converted to functions with the text and delimiter as paramaters for ease
of use:
-- Add "inline line numbers" [-hh fecit, 2014]
function numberText T,D
split T by return
put "1:" && T[1] into R
repeat with K = 2 to item 2 of the extents of T
put cr & K & D & T[K] after R
end
1. Besides removing scroll-update, which takes most of the time, you could
try the following array-methods (which are essentially from my stack
http://forums.livecode.com/viewtopic.php?p=101301#p101301 , see there
card "LineNums, tab "Nb2").
This needs here on a medium fast machine (Mac mini,
Another issue may be the line that updates the scrollbar. Try commenting
out that line as a test just to see if that's the problem. If so, you might
opt for a spinner or progress bar instead.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software |
Thanks Mark. What you said makes sense, but when I actually tested it, your
routine is about the same as mine - 3200 lines in 106 seconds (on my fairly
old MacBook).
Cheers,
David G
> On 26 Oct 2018, at 6:41 pm, Mark Hsu via use-livecode
> wrote:
>
> I think your issue is where you say
I think your issue is where you say “put tcount & j into line tcount of it” —
The line X of … call is very slow as it has to count every line from 1 - X.
try this:
local tBuffer
put 1 into tCount
repeat for each line j in pText
put tCount & j & lf after tBuffer
add 1 to tCount
set the
Hello folks
I am doing a content analysis of online chat and messaging. Sometimes very
large files, thousands or even hundreds of thousands of messages. I am finding
filter and find to be delightfully fast.
However…. Sometimes I want to prefix each line with the line number, and do
this:
25 matches
Mail list logo
