date:20200220

Re: Diagnosing a crasher (was Re: Quality, reputation, and improving both)

2020-02-20 Thread J. Landman Gay via use-livecode

I'm having the same problem. I had to build with the latest 9.6dp release 
because it fixed some Android issues and I had a deadline. It's in the Play 
Store now and it's had several crashes and ANRS. There's no info on the 
cause and we couldn't repeat it. We're about to submit the iOS app now and 
my testers have had several intermittent crashes we can't repeat, even 
though I built that one with 9.5.1 stable. I submitted crash logs but the 
team could only repeat the problem once and there's no real recipe. How 
would you trace something like that?


It feels like a memory leak to me but that could happen anywhere in the 
app. Wherever it is, it goes back a ways.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On February 20, 2020 10:40:59 PM dunbarx--- via use-livecode 
 wrote:


So I am fascinated; how would you even start? It isn't one handler that 
causes the problem.




___
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: Diagnosing a crasher (was Re: Quality, reputation, and improving both)

2020-02-20 Thread Richard Gaskin via use-livecode

dunbarx wrote:> Richard.
>  I will keep a eye out to see if something I do or some particular
> section of code which causes a crash.
> I have no issue with sending you my stack; it is only for internal
> use. But there are many handlers in many controls on many cards, all
> in a mainStack and a handful of substacks. I do feel, though, that the
> problem occurs when handlers in the mainStack are being worked on.
> So I am fascinated; how would you even start? It isn't one handler
> that causes the problem. You would not even know how to use the thing,
> and therefore could not really put it through its paces.
> I feel this would be a waste of your time, and though the offer is
> priceless, I have always felt that, in particular, your time is far
> more priceless.

That's kind of you to say.  And I am working on some things for the 
community, so perhaps best to keep my focus on those, at least for now.

If you discover a recipe, or even anything close to a pattern, maybe the 
first thing I'd do is add some logging.  Logs are great for crashers, as 
the last line that successfully executed will usually provide some good 
clues.

Here's a simple logger I made a while back, not fancy but it gets the 
job done:

http://fourthworld.net/lc/4wLogger.livecode.zip

If you happen to run it when you have a crash, maybe email me the last 
hundred lines or so (but not the whole thing, please; as you'll see, it 
makes a _very_ verbose log).

--
 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: Diagnosing a crasher (was Re: Quality, reputation, and improving both)

2020-02-20 Thread dunbarx--- via use-livecode

Richard.
 I will keep a eye out to see if something I do or some particular section of 
code which causes a crash. 
I have no issue with sending you my stack; it is only for internal use. But 
there are many handlers in many controls on many cards, all in a mainStack and 
a handful of substacks. I do feel, though, that the problem occurs when 
handlers in the mainStack are being worked on.
So I am fascinated; how would you even start? It isn't one handler that causes 
the problem. You would not even know how to use the thing, and therefore could 
not really put it through its paces.
I feel this would be a waste of your time, and though the offer is priceless, I 
have always felt that, in particular, your time is far more priceless.
Craig

-Original Message-
From: Richard Gaskin via use-livecode 
To: use-livecode 
Cc: Richard Gaskin 
Sent: Thu, Feb 20, 2020 9:08 pm
Subject: Diagnosing a crasher (was Re: Quality, reputation, and improving both)

dunbarx wrote:

 > Richard wrote:
 >> Crashers are of course serious, but the good news is that you're only
 >> seeing it in one project.  Feel free to email me directly if you're
 >> in a position to allow me to review the errant code, and I'll see
 >> what we can do to both find a workaround to keep your progress moving
 >> along well, and submit a report for the underlying cause once we find
 >> it. This happens all over the place, and seems to occur only after
 >> the stack has been fiddled with for a while.
 >
 > This happens all over the place, and seems to occur only after the
 > stack has been fiddled with for a while.

Apparently I was mistaken.  When I read:

  "I must add that I am working mainly on a single project when this
    happens, and am conditioned to save often. The other projects I
    have currently do not exhibit this at all, though that may be
    simply due to the fact that I am involved in them much less
    intensely.
    I suppose it is less worrisome that this is a problem in only a
    single project, than if it happened here and there, everywhere.

...I got the impression that it was a problem in only one single 
project, less worrisome than if it happened in others.

Do you see a pattern to the crashes that might lead to a recipe?

 > I cannot imagine that anything can be gleaned from the code base,
 > which is 9000 lines of straight LC, with only a smattering of
 > printing, printing to PDF, creating text files and reading and writing
 > to them.

Software is code. I already have the engine code.

I'm of the opinion that crashers are something that ideally should never 
happen in any scripting language.  So even if there's something we can 
change in your code to eliminate the crash, I'd still submit a bug 
report to see if a more graceful degradation is possible.

You're not obliged to accept the help.

 > In fact, none of those "outside LC" gadgets have ever caused a crash.

That may be useful diagnostic info.  What is an "'outside LC' gadget"?

 > The bugaboo is inside somewhere; I do not believe it is something I
 > wrote.

If you wrote nothing no crash would occur. :)

I'm not interested in seeking blame, only in seeking solutions.  And as 
I've said above, if there needs to a be any sort blaming we can always 
blame crashes on the engine.  So even if we find a workaround in which 
we change your script to stop the crash, that it resulted in a crash and 
not an error dialog implies an opportunity to further refine LC's 
exception handling.  And along the way you'd see the end to a 
long-standing crasher that's been interrupting your workflow.

 > Can I say "bugaboo" which is not a bug, but rather something that just
 > bugs me?

Sure, feel free to say anything you like.  But to me, any crash in any 
scripting language is a serious issue that merits further diagnosis.

If I can help diagnose this one I'd be happy to lend a hand.

-- 
  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: Quality, reputation, and improving both (was Re: text copied form LC generated PDF, WTF?)

2020-02-20 Thread Mark Wieder via use-livecode


On 2/20/20 7:34 PM, Richard Gaskin via use-livecode wrote:
Thank you, Mark.  Receiving the corrupted stack might be interesting, 


A doubtful prospect at best.


Do you have a recipe I can follow for this?


Absolutely no recipe. These things just sneak up on me, and by the time 
I can notice them I've already relaunched the IDE. That's what's most 
frustrating. If I had a recipe there would be something to fix.


--
 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: Quality, reputation, and improving both (was Re: text copied form LC generated PDF, WTF?)

2020-02-20 Thread Richard Gaskin via use-livecode

Thank you, Mark.  Receiving the corrupted stack might be interesting, 
but what would certainly be most interesting would be to re-create that 
here.


Do you have a recipe I can follow for this?

Do you see the same behavior if plugins are disabled?

--
 Richard Gaskin
 Fourth World Systems


Mark Wieder wrote:

On 2/20/20 11:56 AM, Richard Gaskin via use-livecode wrote:

On the forums we see a another, with surprising frequency:  when the 
behavior of a script is not understood, the poster will sometimes 
surmise that the cause is somehow file format corruption. Many cases 
turn out to be just syntax errors, and IIRC few or none of those have 
turned out to be file format corruption.


So here's one for you: As I've mentioned before, I don't use 9.6dpx for 
anything serious. I've been working with LC9.6dp2 lately to see if my 
stacks still work with the latest builds and I've been coming up with 
interesting results.


At least twice now I've been editing scripts with two tabs open in the 
script editor. After dutifully saving my changes I close the IDE and 
relaunch to ensure a clean slate. I see that my stack crashes horribly 
because the script I was editing has been saved into the wrong object 
(the other script I was editing). Luckily backups saved me.


I have two different corrupted stacks after editing them (one of the 
corrupted stacks is your 4wdevolution stack - happy to send it your way 
if desired). Again backups saved the day. Made the same changes to the 
stack and it works fine.


One of my stacks that behaved properly in LC9.5.1 consistently crashed 
my distro's desktop manager in LC9.6dp2 (any edition), having to be 
restarted. I just spent two days trying to figure out if I was doing 
something wrong or something changed in LC itself, and it turns out to 
be a combination. The cef browser code has changed enough that just 
instantiating a browser widget is enough to cause havoc, so I now 
sidestep some previously-working code and hope that still works when we 
get dp3.


Yes, I realize that these are dp releases and shouldn't be considered 
stable, but it's gotten to the point where I don't know whether problems 
I come across are bugs in my code, bugs in the latest LC build, or 
upcoming changes to The Way Things Work.


___
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: Quality, reputation, and improving both (was Re: text copied form LC generated PDF, WTF?)

2020-02-20 Thread Mark Wieder via use-livecode


On 2/20/20 11:56 AM, Richard Gaskin via use-livecode wrote:

On the forums we see a another, with surprising frequency:  when the 
behavior of a script is not understood, the poster will sometimes 
surmise that the cause is somehow file format corruption. Many cases 
turn out to be just syntax errors, and IIRC few or none of those have 
turned out to be file format corruption.


So here's one for you: As I've mentioned before, I don't use 9.6dpx for 
anything serious. I've been working with LC9.6dp2 lately to see if my 
stacks still work with the latest builds and I've been coming up with 
interesting results.


At least twice now I've been editing scripts with two tabs open in the 
script editor. After dutifully saving my changes I close the IDE and 
relaunch to ensure a clean slate. I see that my stack crashes horribly 
because the script I was editing has been saved into the wrong object 
(the other script I was editing). Luckily backups saved me.


I have two different corrupted stacks after editing them (one of the 
corrupted stacks is your 4wdevolution stack - happy to send it your way 
if desired). Again backups saved the day. Made the same changes to the 
stack and it works fine.


One of my stacks that behaved properly in LC9.5.1 consistently crashed 
my distro's desktop manager in LC9.6dp2 (any edition), having to be 
restarted. I just spent two days trying to figure out if I was doing 
something wrong or something changed in LC itself, and it turns out to 
be a combination. The cef browser code has changed enough that just 
instantiating a browser widget is enough to cause havoc, so I now 
sidestep some previously-working code and hope that still works when we 
get dp3.


Yes, I realize that these are dp releases and shouldn't be considered 
stable, but it's gotten to the point where I don't know whether problems 
I come across are bugs in my code, bugs in the latest LC build, or 
upcoming changes to The Way Things Work.


--
 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: Mobile "shake" ??

2020-02-20 Thread Sannyasin Brahmanathaswami via use-livecode

Great!

BR


yes. :-)

> I found nothing in a dictionary search for "shake" and looked through 
> (quickly) all mobile commands, perhaps it a buried parameter?

Check this lesson from the mothership:

___
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

Diagnosing a crasher (was Re: Quality, reputation, and improving both)

2020-02-20 Thread Richard Gaskin via use-livecode

dunbarx wrote:

> Richard wrote:
>> Crashers are of course serious, but the good news is that you're only
>> seeing it in one project.  Feel free to email me directly if you're
>> in a position to allow me to review the errant code, and I'll see
>> what we can do to both find a workaround to keep your progress moving
>> along well, and submit a report for the underlying cause once we find
>> it. This happens all over the place, and seems to occur only after
>> the stack has been fiddled with for a while.
>
> This happens all over the place, and seems to occur only after the
> stack has been fiddled with for a while.

Apparently I was mistaken.  When I read:

  "I must add that I am working mainly on a single project when this
   happens, and am conditioned to save often. The other projects I
   have currently do not exhibit this at all, though that may be
   simply due to the fact that I am involved in them much less
   intensely.
   I suppose it is less worrisome that this is a problem in only a
   single project, than if it happened here and there, everywhere.

...I got the impression that it was a problem in only one single 
project, less worrisome than if it happened in others.

Do you see a pattern to the crashes that might lead to a recipe?

> I cannot imagine that anything can be gleaned from the code base,
> which is 9000 lines of straight LC, with only a smattering of
> printing, printing to PDF, creating text files and reading and writing
> to them.

Software is code. I already have the engine code.

I'm of the opinion that crashers are something that ideally should never 
happen in any scripting language.  So even if there's something we can 
change in your code to eliminate the crash, I'd still submit a bug 
report to see if a more graceful degradation is possible.

You're not obliged to accept the help.

> In fact, none of those "outside LC" gadgets have ever caused a crash.

That may be useful diagnostic info.  What is an "'outside LC' gadget"?

> The bugaboo is inside somewhere; I do not believe it is something I
> wrote.

If you wrote nothing no crash would occur. :)

I'm not interested in seeking blame, only in seeking solutions.  And as 
I've said above, if there needs to a be any sort blaming we can always 
blame crashes on the engine.  So even if we find a workaround in which 
we change your script to stop the crash, that it resulted in a crash and 
not an error dialog implies an opportunity to further refine LC's 
exception handling.  And along the way you'd see the end to a 
long-standing crasher that's been interrupting your workflow.

> Can I say "bugaboo" which is not a bug, but rather something that just
> bugs me?

Sure, feel free to say anything you like.  But to me, any crash in any 
scripting language is a serious issue that merits further diagnosis.

If I can help diagnose this one I'd be happy to lend a hand.

--
 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: Translate metadata to field content

2020-02-20 Thread J. Landman Gay via use-livecode

So glad you chimed in, Mark. This is pretty impressive. I'll need to use the "for each element" 
structure because my tags are not unique, but it still is much faster. When clicking a tag at 
the top of the document that links to the last anchor at the bottom of the text, I get a timing 
of about 25ms. If I omit the timing for loading the htmltext and the selection of the text at 
the end of the handler it brings the timing to almost 0. The test text is long, but not nearly 
as long as Bernd's sample.


I need to select the entire range of text covered by the metadata span, not just a single word. 
I've got that working, but since we're on a roll here, I wonder if there's a more optimal way 
to do it.


I'm using chars instead of codepoints because when I tried it, they both gave the same number. 
Should I change that?


  put the styledText of fld 1 into tDataA
  put 0 into tTotalChars
  put 0 into tStartChar
  repeat with i = 1 to the number of elements in tDataA
put tDataA[i]["runs"] into tRunsA
repeat with j = 1 to the number of elements in tRunsA
  put tRunsA[j] into tRunA
  add the num of chars in tRunA["text"] to tTotalChars
  if tRunA["metadata"] is pTag then
if tStartChar = 0 then
  put tTotalChars - len(tRunA["text"]) + 3 into tStartChar
end if
  else if tStartChar > 0 then
put tTotalChars - len(tRunA["text"]) into tEndChar
select char tStartChar to tEndChar of fld 1
select empty
set the backcolor of char tStartChar to tEndChar of fld 1 to "yellow"
return tStartChar & comma & tEndChar
  end if
end repeat
  end repeat

Also, I had to add 3 to tStartChar to get the right starting point but I can't figure out why. 
Otherwise it selects the last character before the metadata span as the starting point.



On 2/20/20 2:13 AM, Mark Waddingham via use-livecode wrote:

Of course *all* three of my suggested approaches are wrong - I messed up the 
inner loop in each...

On 2020-02-20 07:56, Mark Waddingham via use-livecode wrote:

NON-UNIQUE ANCHORS
repeat with i = 1 to the number of elements in tDataA
  local tRunsA
  put tDataA[i]["runs"] into tRunsA
  repeat with j = 1 to the number of elements in tRunsA
    if tRunsA[j]["metadata"] is tSearchText then
  repeat with m = 1 to j
    add the number of words of tRunsA[m]["text"] to tNumWords
    put true into tFlagExit
    exit repeat
  end repeat
    end if
  end repeat
  if tFlagExit then
    exit repeat
  end if
end repeat
select word tNumWords of line i of field "x"


Should be:

  repeat with i = 1 to the number of elements in tDataA
    local tRunsA
    put tDataA[i]["runs"] into tRunsA
    repeat with j = 1 to the number of elements in tRunsA
  if tRunsA[j]["metadata"] is tSearchText then
    repeat with m = 1 to j
  add the number of words of tRunsA[m]["text"] to tNumWords
    end repeat
    put true into tFlagExit
    exit repeat
  end if
    end repeat
    if tFlagExit then
  exit repeat
    end if
  end repeat
  select word tNumWords of line i of field "x"


UNIQUE ANCHORS



repeat for each key i in tDataA
  local tRunsA
  put tDataA[i]["runs"] into tRunsA
  repeat for each key j in tRunsA
    if tRunsA[j]["metadata"] is tSearchText then
  repeat with m = 1 to j
    add the number of words of tRunsA[m]["text"] to tNumWords
    put true into tFlagExit
    exit repeat
  end repeat
    end if
  end repeat
  if tFlagExit then
    exit repeat
  end if
end repeat
select word tNumWords of line i of field "x"


Should be:

  repeat for each key i in tDataA
    local tRunsA
    put tDataA[i]["runs"] into tRunsA
    repeat for each key j in tRunsA
  if tRunsA[j]["metadata"] is tSearchText then
    repeat with m = 1 to j
  add the number of words of tRunsA[m]["text"] to tNumWords
    end repeat
    put true into tFlagExit
    exit repeat
  end if
    end repeat
    if tFlagExit then
  exit repeat
    end if
  end repeat
  select word tNumWords of line i of field "x"


RUN WITH METADATA DEFINES SELECTION - NON-UNIQUE SEARCH

repeat with i = 1 to the number of elements in tDataA
  local tRunsA
  put tDataA[i]["runs"] into tRunsA
  repeat with j = 1 to the number of elements in tRunsA
    local tRunA
    put tRunsA[j] into tRunA
    if tRunA["metadata"] is tSearchText then
  repeat with m = 1 to j - 1
    add the number of codeunits of tRunsA[m]["text"] to tNumCodeunitsBefore
    put the number of codeunits in tRunA["text"] into tNumCodeunits
    put true into tFlagExit
    exit repeat
  end repeat
    end if
  end repeat
  if tFlagExit then
    exit repeat
  end if
end repeat
select codeunit tNumCodeunitsBefore to tNumCodeunitsBefore +
tNumCodeunits - 1 of line i of field "x"


Should be:

  repeat with i = 1 to the number of elements in tDataA
    local tRunsA
    put tDataA[i]["runs"] into tRunsA
    repeat with j = 1 to the num

Re: Quality, reputation, and improving both (was Re: text copied form LC generated PDF, WTF?)

2020-02-20 Thread dunbarx--- via use-livecode

Crashers are of course serious, but the good news is that you're only 
seeing it in one project.  Feel free to email me directly if you're in a 
position to allow me to review the errant code, and I'll see what we can 
do to both find a workaround to keep your progress moving along well, 
and submit a report for the underlying cause once we find it.
Richard.
This happens all over the place, and seems to occur only after the stack has 
been fiddled with for a while. I cannot imagine that anything can be gleaned 
from the code base, which is 9000 lines of straight LC, with only a smattering 
of printing, printing to PDF, creating text files and reading and writing to 
them.
In fact, none of those "outside LC" gadgets have ever caused a crash. The 
bugaboo is inside somewhere; I do not believe it is something I wrote.
I have seen this in my other projects. They are not free of this issue. They 
just are not worked as hard,
Can I say "bugaboo" which is not a bug, but rather something that just bugs me?
I save often, and thereby save myself a lot of trouble.
Craig

-Original Message-
From: Richard Gaskin via use-livecode 
To: use-livecode 
Cc: Richard Gaskin 
Sent: Thu, Feb 20, 2020 2:57 pm
Subject: Quality, reputation, and improving both (was Re: text copied form LC 
generated PDF, WTF?)

dunbarx wrote:

 > Several threads on the forum have bemoaned what is labeled an
 > overarching bug issue in LC.
...
 > I am really only concerned that LC not get a reputation for being
 > unstable.

Most of us share that concern.  To assess the issue soberly compels us 
to examine the nature and sources of reputation.

Reputation is only partly a reflection of actual technical fitness. The 
rest is a mix of factors that lie far outside of computer science, into 
the realms of psychology, sociology, and political science.

This thread is a good example:  What might have seemed at first like a 
bug in LC turned out to be a limitation inherent in the nature of PDF 
itself.

On the forums we see a another, with surprising frequency:  when the 
behavior of a script is not understood, the poster will sometimes 
surmise that the cause is somehow file format corruption. Many cases 
turn out to be just syntax errors, and IIRC few or none of those have 
turned out to be file format corruption.

We see a similar pattern with the documentation: many posts point to a 
need for additional information being added to the docs, with 
recommendations for learning basics linking to any of a wide range of 
resources spread out across the web, but on further examination we find 
that the fairly comprehensive 655-page User Guide included with the 
install hadn't yet been consulted at all.

None of this is to suggest that LiveCode is the world's first 
million-line code base that's completely bug-free.

But neither is it a roach motel when we consider the scope and 
complexity of the system with common metrics like bugs/kloc.

In the vast gulf between needlessly contentious allegations of 
"apologists" at one extreme and "Henny Pennys" on the other is a middle 
ground where meaningful product improvement can actually happen:

- Let questions be questions:  When an unexpected outcome is observed, 
we can keep an open mind about possible causes until the issue is 
diagnosed.  If we keep telling new users in advance that every 
unexpected outcome is a bug in LC they'll eventually believe it, even in 
the many cases where that isn't true.

- Let learning happen right in the box: We are blessed with a great many 
contributions from community members all across the web.  But to be 
clear, many of these predate the expanded documentation effort the team 
undertook several versions ago.  Moreover, those written after LC 
adopted an open source workflow missed the opportunity for greater 
readership, keeping them in a relatively small corner of the 
possibly-discoverable web rather than submitting them to the core docs 
every user is directed to right in the Help menu.  The docs are good, 
and can always be made even better.  We can help. Of course we want to 
see as much LC info everywhere, but core basics might just as well be in 
the box, and we do a good service to the learner to let them know when 
they already are.

- Let pre-release builds realize their value:  use them, whenever 
practical.  Putting off trying a new version until after Stable is the 
one choice that guarantees any issues affecting your specific work won't 
be fixed in that version.  We know from our own experiences and decades 
of industry literature that the earlier in the process bugs are 
identified, the less impact they have, and thus the total systemic cost 
to address them is much lower.

These are just suggestions, and certainly not any attempt at 
establishing any sort of "rules".  I have no authority to require anyone 
to do anything, nor would I even try, as I understand that from time to 
time there can be good reason to ignore each of these, and any other

Re: Translate metadata to field content

2020-02-20 Thread hh via use-livecode

Sorry, forgot that some html entities are not displayed in the list:

So assuming (unusual) should read

-- [1] you use the following for a link target
-- Xtarget10X

where X is ("&" & "#1;") ..., the html translation of numToChar(1).

-- LC translates numToChar(1) to " " should read

-- LC translates numToChar(1) to "X", where X is ("&" & "#1;")
___
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: Translate metadata to field content

2020-02-20 Thread hh via use-livecode

As others try to optimize ("ping") I'll try an improvement too ("pong")
with using another method that requires to change your link targets ONCE:

Instead of unique targets  write in your field

""&numTochar(1)&"target10"&numTochar(1)&"""

Handler replaceTargets below does it (slowly) but you probably don't
need it on mobile.

So assuming (unusual)

-- [1] you use the following for a link target
-- target10
-- [2] you use the following for a local page link
-- Target10
-- [3] you don't use  elsewhere. Else add
-- an additional marker to it to differentiate.


Then script your field with the following simple handler:

on linkClicked pUrl
  put the milliseconds into m1
  lock messages; lock screen
  if pUrl begins with "#" then
put numToChar(1)& (char 2 to -1 of pUrl) &numToChar(1) into tTarget
put 1+offset(tTarget,me)+length(tTarget) into tOff
select char tOff to tOff+3 of me -- see it in locked field
-- select char tOff of me -- variant
scrollSelectionIntoView -- optional
  end if
  put the millisecs -m1 into fld "timing1"
end linkClicked

 helpers (optionally needed)

-- Note. LC adds also an additional "", we don't mind.
on replaceTargets -- should be optimized if used often
  put the millisecs into m1
  lock messages; lock screen
  put the htmltext of fld 1 into tHTML
  set linedel to ""
  put line 1 of tHtml into tI2
  put numToChar(1) into b1
  repeat for each line L in (line 2 to -1 of tHtml)
put ""&b1&char 1 to offset(quote,L)-1 of L into item 1 of L
put offset("",L) into o1
put b1&"" into char o1 to o1+3 of L
put L after tI2
  end repeat
  set htmlText of fld 1 to tI2 -- LC translates numToChar(1) to ""
  put the millisecs-m1 into fld "timing2"
end mouseUp

on scrollSelectionIntoView
  put the selectedLoc into tSL
  put the vscroll of me into tV
  put item 2 of tSL - the top of me into tDiff
  if tDiff > 0.75*the height of me then
set vscroll of me to tV + 0.4*the height of me
  else if tDiff < 0.25*the height of me then
set vscroll of me to tV - 0.4*the height of me
  end if
end scrollSelectionIntoView


___
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

Quality, reputation, and improving both (was Re: text copied form LC generated PDF, WTF?)

2020-02-20 Thread Richard Gaskin via use-livecode

dunbarx wrote:

> Several threads on the forum have bemoaned what is labeled an
> overarching bug issue in LC.
...
> I am really only concerned that LC not get a reputation for being
> unstable.

Most of us share that concern.  To assess the issue soberly compels us 
to examine the nature and sources of reputation.

Reputation is only partly a reflection of actual technical fitness. The 
rest is a mix of factors that lie far outside of computer science, into 
the realms of psychology, sociology, and political science.

This thread is a good example:  What might have seemed at first like a 
bug in LC turned out to be a limitation inherent in the nature of PDF 
itself.

On the forums we see a another, with surprising frequency:  when the 
behavior of a script is not understood, the poster will sometimes 
surmise that the cause is somehow file format corruption. Many cases 
turn out to be just syntax errors, and IIRC few or none of those have 
turned out to be file format corruption.

We see a similar pattern with the documentation: many posts point to a 
need for additional information being added to the docs, with 
recommendations for learning basics linking to any of a wide range of 
resources spread out across the web, but on further examination we find 
that the fairly comprehensive 655-page User Guide included with the 
install hadn't yet been consulted at all.

None of this is to suggest that LiveCode is the world's first 
million-line code base that's completely bug-free.

But neither is it a roach motel when we consider the scope and 
complexity of the system with common metrics like bugs/kloc.

In the vast gulf between needlessly contentious allegations of 
"apologists" at one extreme and "Henny Pennys" on the other is a middle 
ground where meaningful product improvement can actually happen:

- Let questions be questions:  When an unexpected outcome is observed, 
we can keep an open mind about possible causes until the issue is 
diagnosed.  If we keep telling new users in advance that every 
unexpected outcome is a bug in LC they'll eventually believe it, even in 
the many cases where that isn't true.

- Let learning happen right in the box: We are blessed with a great many 
contributions from community members all across the web.  But to be 
clear, many of these predate the expanded documentation effort the team 
undertook several versions ago.  Moreover, those written after LC 
adopted an open source workflow missed the opportunity for greater 
readership, keeping them in a relatively small corner of the 
possibly-discoverable web rather than submitting them to the core docs 
every user is directed to right in the Help menu.  The docs are good, 
and can always be made even better.  We can help. Of course we want to 
see as much LC info everywhere, but core basics might just as well be in 
the box, and we do a good service to the learner to let them know when 
they already are.

- Let pre-release builds realize their value:  use them, whenever 
practical.  Putting off trying a new version until after Stable is the 
one choice that guarantees any issues affecting your specific work won't 
be fixed in that version.  We know from our own experiences and decades 
of industry literature that the earlier in the process bugs are 
identified, the less impact they have, and thus the total systemic cost 
to address them is much lower.

These are just suggestions, and certainly not any attempt at 
establishing any sort of "rules".  I have no authority to require anyone 
to do anything, nor would I even try, as I understand that from time to 
time there can be good reason to ignore each of these, and any other 
common practices observable in healthy software communities.

But most of us have been around the block enough times to recognize the 
value of such ordinary practices.  And all of us want LC to improve - 
both in terms of actual product quality, and its *perceived* quality, 
its reputation.

LiveCode is moving its way up the TIOBE Index of programming language 
popularity, slowly but steadily. For all the reasons Geoff Moore 
outlined in Crossing the Chasm and many more, expanding LC's audience 
benefits all of us: more tools, more libraries, more eyeballs, more hands.

There isn't a single language on the TIOBE Index that's bug-free, and 
yes, that includes LiveCode.

We the community have at least as much power and influence over LiveCode 
adoption as anything the core team can do, by virtue of our numbers and 
reach.  With any programming tool, the number of end-users who 
ultimately benefit is orders of magnitude larger than the number of 
developers using it.

Let's produce great work, and build upon those practices proven across 
the industry to expand both real and perceived quality.

Along those lines, I'll extend an offer here:

> For my part, I only notice that LC 9x crashes intermittently, though
> regularly. I must add that I am working mainly on a single project
> w

Re: Translate metadata to field content

2020-02-20 Thread Niggemann, Bernd via use-livecode

In reply to Mark Waddingham's comments


Thank you Mark Waddingham for the improved scripts and the hints as to why they 
improve speed.

I adapted Mark's version for unique occurrence, changed how the position of the 
target word is determined in the target line.
It is not safe to assume that the sum of words of the runs is the number of 
words of the line up to the target word. The reason is that runs are depending 
on formatting and formatting can create a new run in the middle of a word and 
thus increase word count.
I did not opt for Mark's use of codeunits because I had the impression it was 
not faster and makes the code less obvious.

--
local tTextOfRuns
repeat for each key i in tDataA
   local tRunsA
   put tDataA[i]["runs"] into tRunsA
   repeat for each key j in tRunsA
  if tRunsA[j]["metadata"] is tSearchText then
 repeat with m = 1 to j
put tRunsA[m]["text"] after tTextOfRuns
 end repeat
 put the number of words of tTextOfRuns into tNumWords
 put true into tFlagExit
 exit repeat
  end if
   end repeat
   if tFlagExit then
  exit repeat
   end if
end repeat
--
select word tNumWords of line i of field "x"

text consists of 96881 words and 23161 lines of heavily formatted text
(it is the script of RevDataGridLibraryBehaviorsDataGridButtonBehavior copied 
twice into a field as described before)

word# old new version, times in ms

96881 240 110
8 220 100
6 180  60
3 120 125
1  85 125
 1000  50  90
1  50  60

Timing this is a bit tricky. For "repeat with I = 1 to item 2 of the extents" 
it is obvious that time increases with increasing the target word number.

For "repeat for each key I in tDataA" it is not sequential but faster. However 
that also makes for variations in speed depending on the internal state of the 
array structure.

All timings are estimated averages of 5 to 10 measurements . Variability is 
typically about +-5 to 10 milliseconds with outliers.

However the overall speed gain is quite impressive and well worth the change.
I learned a lot about handling larger datasets using arrays, than you.

Kind regards
Bernd


___
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: text copied form LC generated PDF, WTF?

2020-02-20 Thread Klaus major-k via use-livecode

Hi Mark,

> Am 20.02.2020 um 14:55 schrieb Mark Waddingham via use-livecode 
> :
> 
> On 2020-02-18 18:40, Klaus major-k via use-livecode wrote:
>> Hi friends,
>> I know that copying text form a PDF file may result in unexspected results,
>> but this is really ridicoulous!?
>> I created a PDF from LC (selected "Save as PDF" in the macOS Print dialog)
>> and when I copy some text and past it into TextEdit, this is what i get:
>> 
>> Where on earth are my numbers and where is my text?
>> Any insights very appreciated!
> 
> As requested by Klaus on the forum thread 
> (http://forums.livecode.com/viewtopic.php?f=9&t=33683&start=15) this isn't a 
> bug.
> TL;DR version - extracting text from PDFs is hard, and viewers all do it 
> differently with different levels of 'correctness'.
> The fonts used and the layout can affect what they can produce.
> In this case, the stack in question was being printed with the default system 
> theme fonts (on macOS this is .SFNSText it would seem) - and for whatever 
> reason that font generates glyphs for numbers in the PDF which PDF viewers 
> don't seem to be able to map back to actual digits.
> Upshot - make sure the controls you are printing have an explicit font 
> setting to a 'normal' font if you want to be able to copy text from any PDF 
> you might generate as a result :)

thank you very much for this valuable hint! :-D

> Warmest Regards,
> 
> Mark.

Best

Klaus

--
Klaus Major
https://www.major-k.de
kl...@major-k.de


___
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: text copied form LC generated PDF, WTF?

2020-02-20 Thread Mark Waddingham via use-livecode


On 2020-02-18 18:40, Klaus major-k via use-livecode wrote:

Hi friends,

I know that copying text form a PDF file may result in unexspected 
results,

but this is really ridicoulous!?

I created a PDF from LC (selected "Save as PDF" in the macOS Print 
dialog)
and when I copy some text and past it into TextEdit, this is what i 
get:


Where on earth are my numbers and where is my text?

Any insights very appreciated!


As requested by Klaus on the forum thread 
(http://forums.livecode.com/viewtopic.php?f=9&t=33683&start=15) this 
isn't a bug.


TL;DR version - extracting text from PDFs is hard, and viewers all do it 
differently with different levels of 'correctness'.


The fonts used and the layout can affect what they can produce.

In this case, the stack in question was being printed with the default 
system theme fonts (on macOS this is .SFNSText it would seem) - and for 
whatever reason that font generates glyphs for numbers in the PDF which 
PDF viewers don't seem to be able to map back to actual digits.


Upshot - make sure the controls you are printing have an explicit font 
setting to a 'normal' font if you want to be able to copy text from any 
PDF you might generate as a result :)


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

ChangeImage Widget

2020-02-20 Thread hh via use-livecode



ChangeImage Widget v106

This is a (partial) extension of the TurnImage widget (v135).
It adds masking of the images and several transition animations
(from one  image to a second one). We now have
zoom, barn door horiz/vert, move horiz/vert, squeeze horiz/vert,
swipe diag/horiz/vert, (perspective) turn horiz/vert, rotate.

Download the widget and a sample stack from here:
https://hyperhh.de/widgets/changeimage.html

___
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: Translate metadata to field content

2020-02-20 Thread Mark Waddingham via use-livecode

Of course *all* three of my suggested approaches are wrong - I messed up 
the inner loop in each...


On 2020-02-20 07:56, Mark Waddingham via use-livecode wrote:

NON-UNIQUE ANCHORS
repeat with i = 1 to the number of elements in tDataA
  local tRunsA
  put tDataA[i]["runs"] into tRunsA
  repeat with j = 1 to the number of elements in tRunsA
if tRunsA[j]["metadata"] is tSearchText then
  repeat with m = 1 to j
add the number of words of tRunsA[m]["text"] to tNumWords
put true into tFlagExit
exit repeat
  end repeat
end if
  end repeat
  if tFlagExit then
exit repeat
  end if
end repeat
select word tNumWords of line i of field "x"


Should be:

 repeat with i = 1 to the number of elements in tDataA
   local tRunsA
   put tDataA[i]["runs"] into tRunsA
   repeat with j = 1 to the number of elements in tRunsA
 if tRunsA[j]["metadata"] is tSearchText then
   repeat with m = 1 to j
 add the number of words of tRunsA[m]["text"] to tNumWords
   end repeat
   put true into tFlagExit
   exit repeat
 end if
   end repeat
   if tFlagExit then
 exit repeat
   end if
 end repeat
 select word tNumWords of line i of field "x"


UNIQUE ANCHORS



repeat for each key i in tDataA
  local tRunsA
  put tDataA[i]["runs"] into tRunsA
  repeat for each key j in tRunsA
if tRunsA[j]["metadata"] is tSearchText then
  repeat with m = 1 to j
add the number of words of tRunsA[m]["text"] to tNumWords
put true into tFlagExit
exit repeat
  end repeat
end if
  end repeat
  if tFlagExit then
exit repeat
  end if
end repeat
select word tNumWords of line i of field "x"


Should be:

 repeat for each key i in tDataA
   local tRunsA
   put tDataA[i]["runs"] into tRunsA
   repeat for each key j in tRunsA
 if tRunsA[j]["metadata"] is tSearchText then
   repeat with m = 1 to j
 add the number of words of tRunsA[m]["text"] to tNumWords
   end repeat
   put true into tFlagExit
   exit repeat
 end if
   end repeat
   if tFlagExit then
 exit repeat
   end if
 end repeat
 select word tNumWords of line i of field "x"


RUN WITH METADATA DEFINES SELECTION - NON-UNIQUE SEARCH

repeat with i = 1 to the number of elements in tDataA
  local tRunsA
  put tDataA[i]["runs"] into tRunsA
  repeat with j = 1 to the number of elements in tRunsA
local tRunA
put tRunsA[j] into tRunA
if tRunA["metadata"] is tSearchText then
  repeat with m = 1 to j - 1
add the number of codeunits of tRunsA[m]["text"] to 
tNumCodeunitsBefore

put the number of codeunits in tRunA["text"] into tNumCodeunits
put true into tFlagExit
exit repeat
  end repeat
end if
  end repeat
  if tFlagExit then
exit repeat
  end if
end repeat
select codeunit tNumCodeunitsBefore to tNumCodeunitsBefore +
tNumCodeunits - 1 of line i of field "x"


Should be:

 repeat with i = 1 to the number of elements in tDataA
   local tRunsA
   put tDataA[i]["runs"] into tRunsA
   repeat with j = 1 to the number of elements in tRunsA
 local tRunA
 put tRunsA[j] into tRunA
 if tRunA["metadata"] is tSearchText then
   repeat with m = 1 to j - 1
 add the number of codeunits of tRunsA[m]["text"] to 
tNumCodeunitsBefore

   end repeat
   put the number of codeunits in tRunA["text"] into tNumCodeunits
   put true into tFlagExit
   exit repeat
 end if
   end repeat
   if tFlagExit then
 exit repeat
   end if
 end repeat
 select codeunit tNumCodeunitsBefore to tNumCodeunitsBefore + 
tNumCodeunits - 1 of line i of field "x"


Oops!

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: Diagnosing a crasher (was Re: Quality, reputation, and improving both)

Re: Diagnosing a crasher (was Re: Quality, reputation, and improving both)

Re: Diagnosing a crasher (was Re: Quality, reputation, and improving both)

Re: Quality, reputation, and improving both (was Re: text copied form LC generated PDF, WTF?)

Re: Quality, reputation, and improving both (was Re: text copied form LC generated PDF, WTF?)

Re: Quality, reputation, and improving both (was Re: text copied form LC generated PDF, WTF?)

Re: Mobile "shake" ??

Diagnosing a crasher (was Re: Quality, reputation, and improving both)

Re: Translate metadata to field content

Re: Quality, reputation, and improving both (was Re: text copied form LC generated PDF, WTF?)

Re: Translate metadata to field content

Re: Translate metadata to field content

Quality, reputation, and improving both (was Re: text copied form LC generated PDF, WTF?)

Re: Translate metadata to field content

Re: text copied form LC generated PDF, WTF?

Re: text copied form LC generated PDF, WTF?

ChangeImage Widget

Re: Translate metadata to field content

18 matches

Site Navigation

Mail list logo

Footer information