Re: ❣an amazing article [Now way off topic]

2017-04-25 Thread J. Landman Gay via use-livecode

On 4/25/17 11:27 PM, Phil Davis via use-livecode wrote:

Well, this is "special". I see the name wasn't merged in.


As long as we're talking about spam/malware, maybe someone here knows 
what happened to me two days ago. I've written to PayPal (no response) 
and done searches without any real info and only a handful of hits.


Firefox received an update and on relaunch it attempted to reload all 
previously open tabs. A small second window appeared and tried to load 
this URL:


https://www.paypal.com/webapps/hermes/fallback?product=ec=BA-4BN59940BV228700C=1=bootstrap_failed=

The window went into a loop, waiting for a response and retrying until I 
cancelled the reload. I had cookies blocked and no PayPal tabs were open 
or involved. I always log out of PayPal and close the tab when I'm done, 
and was logged out when this happened. Firefox was reloading 7 tabs, 
none pointing to PayPal (Asana, Slack, Google Drive, and other well 
known sites.)


I quit and re-launched and got the same thing with the same URL, but 
with a different token.


This spooked me. The URL points to an error page on PayPal that says, 
basically, that something went wrong with the transaction and my account 
hadn't been charged. I don't keep any financial passwords in Firefox so 
I'm not worried about that, but how did that happen?


Yesterday Firefox had another update, right on the heels of the first. 
Rather than click the Update button, I went to Mozilla and downloaded 
the file manually. I closed all open tabs and quit Firefox, then 
launched the new update. No ill effects.


Wha..?

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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: Please block sims emails

2017-04-25 Thread J. Landman Gay via use-livecode

On 4/25/17 10:36 PM, Jerry Jensen via use-livecode wrote:

Somebody is using sims email to post phishing/spam/malware - I don’t
know which because I won’t click it.


He frequently gets infected with malware. But I rather liked this set. 
"Dear!" I wanted to respond, "Darling!!"


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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

Please block sims emails

2017-04-25 Thread Jerry Jensen via use-livecode
Somebody is using sims email to post phishing/spam/malware - I don’t know which 
because I won’t click it.

Please block email from him. 

Listmom, hello???


___
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: Make numberFormat even better AND Cognitive Load

2017-04-25 Thread Richard Gaskin via use-livecode

Roland Huettmann wrote:

>  AGAIN -- having read all - I vote for the LC-NATIVE "Excel style"
> number format (enhanced numberFormat in LC, not a new one, no
> depreciation, but just different ways to achieve the same) and the
> ability of fields (text controls) to express at least the same
> styling properties that fields (cells) in Excel support, or text
> boxes in the web browser without having to write my own functions.
> I would like to have it "built-in". It is a wish. LiveCode should
> grow so that the team developing it will consist of 100 core
> developers. It is a wish. Maybe someone else can help developing.
> We can fund it. Whatever. It is a wish. And I do not want to stop
> wishing just because there is "no time left" for the core developer
> team to care for such minor (???) details. They need more support and
> more funding in such case.

I like that.  A lot.

There are many ways to support a project.  Cash is great (they do have a 
donation button), but so is code.


When we think about code contributions, they already have a team far 
larger than 100s.  It's in the thousands.  It's us.


One of the hardest aspects of this problem is the design.  The Excel 
spec is a guide, but not an implementation.  Making that work robustly, 
flexibly, and sensibly within LiveCode is a considerable design project.


And it's a design project that we can do.

We can start today.

Design doesn't require expertise in C++.  The best qualification for 
designing a solution is a clear understanding of the need.


We want this.  Can have have this.

Having begins with designing, and we can design in script.

And once the implementation's design is well honed, we may find we just 
saved the engine team a boatload of design work.


And along the way we have a functional scripted solution we get to use now.

--
 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


Make numberFormat even better AND Cognitive Load

2017-04-25 Thread Roland Huettmann via use-livecode
With reference to the past suggestions, and the last one from Richard
Gaskin:

"Even if the core team were in a position to drop other priorities to add
formatting to fields, they couldn't do it any faster than a scripter who
has the advantage of doing it in LiveCode itself."

I have been thinking about the underlying reasons why we are discussing. I
agree with Richard that a lot of what we have in mind can be done simply
using LiveCode script and behaviors for fields. But are we not doing this
already most of the time?

===
 AGAIN -- having read all - I vote for the LC-NATIVE "Excel style" number
format (enhanced numberFormat in LC, not a new one, no depreciation, but
just different ways to achieve the same) and the ability of fields (text
controls) to express at least the same styling properties that fields
(cells) in Excel support, or text boxes in the web browser without having
to write my own functions. I would like to have it "built-in". It is a
wish. LiveCode should grow so that the team developing it will consist of
100 core developers. It is a wish. Maybe someone else can help developing.
We can fund it. Whatever. It is a wish. And I do not want to stop wishing
just because there is "no time left" for the core developer team to care
for such minor (???) details. They need more support and more funding in
such case. Would they not deserve it? And are there not billions of dollars
around, often enough just wasted for what? ))). Why should not a clever
large company see LiveCode as a way to enhance their public awareness and
sponsor it?
===

Expanding the "numberformat" going beyond...

I favor great visual style and I would love when people start using
LiveCode as a development platform even for the web, as a design system, as
a way to translate to HTML/CSS, Javascript and PHP using ONE base, as a
workshop for great content management systems -- and a lot has been done in
this way during the last three years.

And I am also asking myself, why am I spending time over and over writing
lines of code that are just repeating themselves for me and others, more or
less. And my own library is just my own. I use it. I could share it, but it
is not part of the community really. (And I feel too shy to share it unless
it was reviewed and tested a hundred times.)

So basically, we are not so much discussing about ourselves -- at least not
when there is some experience gained developing with LiveCode -- we are
discussing about the LANGUAGE as we believe it deserves to be spreading out
into the world to 100x or 1000x more developers or people wishing to at
least using such jewel for their fun at home, for in-house development,
just to solve some problems that otherwise would require a professional and
very costly setup.

We know that we can already solve lots of such questions about formats
(number formats, date formats, colors, forms, visual appearance in general)
just reverting to scripting. For example, to just have a bottom border
underlined, I can of course just use a line object and have it set where I
want it to be. But is this really how it should be in today's world? I
would rather like to focus on even more abstract levels and not having to
care too much about the daily standard routines.

I am thinking of the ATTRACTION TO THE LANGUAGE especially for NEWBIES,
young people, retired people, who have not much or no experience at all
with computer languages. There is a huge market.

So, I am stretching out beyond numberFormat -- more into Cognitive Load --
another nice discussion we are having.

Why should not retired people have fun developing on a computer? Would not
LiveCode be the only and truly ideal way to learn and enjoy results
immediately? It can be a business by itself. There are growing numbers of
them, millions and millions of retired people who even have all the time to
not allowing their brains to rust. It is "just" a question of proper
worldwide marketing.

Or think of Africa with hundreds of millions of young people who have not
much chance to even touch any computer, even if almost every of their
elderly brothers and sisters owns a cheap Android phone to be proud of.
There are hundreds of millions of young people eager to get involved. And
some of them could even make a living using it. And there are funds with
hundreds of millions just for such young people.

I want the language to shine bright, really be able to compete, and even
when acknowledging that it is probably impossible to win much ground
against Javascript or PHP or Python. The base for such other languages is
too big. The support such languages enjoy from largest companies can not be
argued against.

But still, I feel, that I would love to see LiveCode gaining ground, be the
first choice at least for beginners. (And I say this because I have fun
using it.)

Who will start with the expanded "numberformat" to be shipped with newer
versions? )

Roland

P.S. I hope this contribution message is not too much missing the point --

Re: Make numberFormat even better

2017-04-25 Thread Curry Kenworthy via use-livecode


Mark:

> If we made this distinction, then it would be viable to
> make it so that numberFormat *only* affects reals:

> put 1 + 0 into tInteger
> put 1. + 0 into tReal
> set the numberFormat to "0.00"
> put tInteger , tReal
> => "1,1.00"

I would expect big problems doing that generally! But it may hint at 
another workable approach.


Doing this for all number to text conversions would be chaotic, because 
one man's integer is another man's real, and another person would like 
their integers formatted too. I may have "5" and intend that to be $5.00 
or 005. I would expect the new problems and code breakage to be much 
more extensive than the ones this is intended to solve.


> Arrays in LiveCode serve two purposes - both lists
> (if integer keyed, dense, starting from 1) and dictionaries
> (all other types).

But doing the above ONLY for numbers that are going into array keys 
would be less chaotic, more targeted to the problem. It is intuitive to 
be able to put a formatted string into an array without worrying about 
the key changing on you.


Then is it necessary to differentiate real vs integer, both for the 
user's number and the array structure? Or just do it for all array keys? 
One guy may have a loop incrementing by .1 and expect it to work, 
another guy may have a mix of integer and text keys. They don't qualify 
as an LC list array, but considering the formatting a separate issue, 
should it just work for them too? To me it seems more intuitive to treat 
all those numbers the same for array key formatting (or nonformatting) 
purposes. I'm not worrying about how the array keys are stored internally.


Either way could be fine with me if it seems consistent, limited to 
array keys, and a persistent way to turn it off which could also be the 
backward compatibility solution, default on for new version stacks and 
off for old ones?


> The problem is that I'm not sure it is feasible to extend
> the allowed size of integers (having them arbitrary precision
> would be really neat!) whilst preserving this graceful
> degradation to double (at least not in a performant way).

I would consider that a completely separate issue from the formatting 
(and as above, I think it would be chaotic and break a lot of things to 
conflate them in general. Plus second-guessing the user's intended type 
(or nontype) could be frustrating. I firmly believe non-typed is a plus 
for LC.


But as a behind-the-scenes math thing, yes, very useful! Having numbers 
shift types automatically to retain best precision, without necessarily 
worrying about what type they are, could be amazing. It would probably 
still run into problems though, such as two big numbers .1 apart (one an 
integer) ending up miles apart. So it's another issue to consider on its 
own merits.


Back to formatting, this gives us at least two viable possibilities for 
the numberFormat array key issue? Not bad!


Best wishes,

Curry Kenworthy

Custom Software Development
LiveCode Training and Consulting
http://livecodeconsulting.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: Make numberFormat even better

2017-04-25 Thread Richard Gaskin via use-livecode

Curry Kenworthy wrote:

> Some people are trend-attuned, bandwagonish and when something
> like JavaScript becomes extremely popular, they feel the need
> to compromise or follow it beyond the extent which is already
> dictated by technology. It's possible that nothing will make
> those people feel comfortable until LC scripting is essentially
> JS. And later if another language were to overtake JS, they'd
> want to follow that.

Where do you find comments like those?

I've seen a request or two for true OOP in the forums, and a few for dot 
notation now and then (FWIW I'm agnostic on the subject), but by and 
large most folks I know using xTalks like the flavor of the language family.


No offense to JavaScript; I enjoy it, along with bash and R, and I even 
miss some things about Pascal now and then.  But I spend more time in LC 
than the others in large part because the language is more fun.  Seems 
most polyglots I run into feel the same.


--
 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: Make numberFormat even better

2017-04-25 Thread Curry Kenworthy via use-livecode


Roger:

> I wouldn't even be here if not for my introduction to
> English-like syntax via HyperCard 25+ years ago.  My
> apparently "not very useful work" over the past 25 years
> ... has kept me employed, my family clothed and fed,
> a roof over our heads, and all my bills paid.

Well said! I'd go even further. There's no need for xTalk users to be on 
the defensive at all. This looks like a false dilemma on two fronts.


Some people are trend-attuned, bandwagonish and when something like 
JavaScript becomes extremely popular, they feel the need to compromise 
or follow it beyond the extent which is already dictated by technology. 
It's possible that nothing will make those people feel comfortable until 
LC scripting is essentially JS. And later if another language were to 
overtake JS, they'd want to follow that. That's largely subjective, so I 
can't really add anything on that side of the equation. Objectively, 
good syntax is not a limitation.


The other front, whether/how to improve numberFormat, does have a real 
dilemma of limited size, but there's no need for massive changes to the 
language. Treating integers and reals differently would introduce a 
variety of problems, I think, starting with the fact that I may have 
what may look like an integer but I consider a real.


I think that approach would violate KISS, and certainly backward 
compatibility. There may still be little quirks to think about, but 
there are straightforward ways to make improvements to specific 
numberFormat limitations without breaking anything. Failing that, I'm 
happy to keep enjoying the limited role that it does well, and rolling 
some of my own solutions. :)


Best wishes,

Curry Kenworthy

Custom Software Development
http://curryk.com/consulting/

___
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: Primes and primality checking

2017-04-25 Thread Mark Wieder via use-livecode

On 04/25/2017 11:15 AM, Mike Kerner via use-livecode wrote:

Long Math is a longstanding ACL contest theme, and I think we've talked
about it here, before, too, because every language runs into precision
issues - sooner or later you're going to run out of digits in the register.


In addition, it's one of those interview coding tests you throw in to 
see if someone checks their 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: Primes and primality checking

2017-04-25 Thread dunbarx via use-livecode
A modification from the web, similar, adapted to LC:

on mouseUp
   local tNum
   put fld 2 into tNum
   put "" into fld 1
   put isPrime(tNum) into fld 1
end mouseUp

function isPrime pNum
   if pNum ≤ 1 then return false
   if pNum ≤ 3 then return true
   if pNum mod 2 = 0 or pNum mod 3 = 0 then return false
   repeat with y = 5 to  sqrt(pNum)
  if pNum mod y = 0 or pNum mod (y + 2) = 0 then return false
  else return true
   end repeat
end isPrime

Same overflow issue at 309 digits.

Craig



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Primes-and-primality-checking-tp4714219p4714238.html
Sent from the Revolution - User mailing list archive at Nabble.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: Make numberFormat even better

2017-04-25 Thread William Prothero via use-livecode
Sorry Roger. I didn’t mean to open a debate on whether English-like syntax is 
good or bad. Just to make a point about doing coding gymnastics to follow a 
viewpoint, that actually makes things more complex. I think that all of us who 
start with LiveCode get hooked, then learn more by discussing and reading the 
docs. For some applications we really need to burrow down to details of the 
engine that can’t be automatically take care of without understanding them. 
There is a tendency for those who already have learned something to see it as 
simple. But I think you need to really watch the newbies and their thought 
processes to really determine how easy it is to get started in livecode. 
Richmond is probably the most expert because of his work in teaching young 
learners.

I don’t see that simply declaring (optionally) that you want a variable to be 
an integer, a real, or whatever, actually violates the spirit of the language. 
To me, it seems like some folks are interested in doing numerical computations 
that exceed the scope of what now exists. For example, the computation of prime 
numbers. Others focus more on applications that are not heavily numerical and 
the current situation is fine. Although I personally may prefer other syntaxes, 
my suggestion was only to look at the trees and let the forest stay the same 
for livecode. Many of the discussions lately have been pretty esoteric and I 
could easily see where folks could get confused. Example: “how many items are 
in “x,x,x,” ?) or Is a number treated as a string or as a number, and when is 
it invisibly converted by the engine? I just think that the mantra of 
“English-like” is only partially applicable to livecode. Other languages have 
“English-like” syntaxes too, although their vocabulary and its application may 
be quite different. And, what about French speakers, Chinese speakers, etc, 
etc. I could go on, but …….

Anyway, have a great day (or evening, whatever the case may be). 
Best,
Bill P

> On Apr 25, 2017, at 11:16 AM, Roger Eller via use-livecode 
>  wrote:
> 
> I wouldn't even be here if not for my introduction to English-like syntax
> via HyperCard 25+ years ago.  My apparently "not very useful work" over the
> past 25 years while benefiting from that very same "less complex" syntax
> has kept me employed, my family clothed and fed, a roof over our heads, and
> all my bills paid.  Not too bad for a less than useful old hack who rarely
> has to rely on a cryptic syntax!
> 
> 
> On Tue, Apr 25, 2017 at 12:57 PM, prothero--- via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> My point was to set variable types when they need to be set explicitly.
>> Those who don't want to set a type can just use forget about it. Once you
>> get into more scientific, numeric type applications, the precision and type
>> of variables can get crucial. To me, the suggested changes to numberformat,
>> adding numberformatXL, etc, just make the situation more complex rather
>> than applying a simple, direct solution that is common in other programming
>> languages. I see no advantage in going through extreme gymnastics to solve
>> a problem that has been solved clearly in other environments. As far as I'm
>> concerned, the English language-like features are great for the new
>> programmer, but actually doing useful work pretty quickly deviates from
>> English like syntax. I'm thinking of Adobe Director rather than C++ or
>> JavaScript. To me, LC's greatest strength is in its UI support and cross
>> platform capabilities.
>> 
>> Best,
>> Bill P
>> 
>> William Prothero
>> http://es.earthednet.org
> ___
> 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: Primes and primality checking

2017-04-25 Thread Mike Kerner via use-livecode
Long Math is a longstanding ACL contest theme, and I think we've talked
about it here, before, too, because every language runs into precision
issues - sooner or later you're going to run out of digits in the register.

So in LC
Put the value into a container
Write the math algorithms that does it the way you know how to do it when
you are doing it manually.  It's very straightforward.

On Tue, Apr 25, 2017 at 1:27 PM, dunbarx via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Devin.
>
> i don't get an overflow error til 309 digits. Where did the guy set a
> limit?
>
> Making some sort of composite gadget, like we played around with a while
> ago
> on the forum to allow long multiplications, additions, etc. without limit
> would be a general solution without, er, limit.
>
> Maybe Hermann can step in?
>
> But post your offering. As you say, it will firm LC within stack overflow.
>
> Craig
>
>
>
> --
> View this message in context: http://runtime-revolution.
> 278305.n4.nabble.com/Primes-and-primality-checking-tp4714219p4714234.html
> Sent from the Revolution - User mailing list archive at Nabble.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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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: Make numberFormat even better

2017-04-25 Thread Roger Eller via use-livecode
I wouldn't even be here if not for my introduction to English-like syntax
via HyperCard 25+ years ago.  My apparently "not very useful work" over the
past 25 years while benefiting from that very same "less complex" syntax
has kept me employed, my family clothed and fed, a roof over our heads, and
all my bills paid.  Not too bad for a less than useful old hack who rarely
has to rely on a cryptic syntax!


On Tue, Apr 25, 2017 at 12:57 PM, prothero--- via use-livecode <
use-livecode@lists.runrev.com> wrote:

> My point was to set variable types when they need to be set explicitly.
> Those who don't want to set a type can just use forget about it. Once you
> get into more scientific, numeric type applications, the precision and type
> of variables can get crucial. To me, the suggested changes to numberformat,
> adding numberformatXL, etc, just make the situation more complex rather
> than applying a simple, direct solution that is common in other programming
> languages. I see no advantage in going through extreme gymnastics to solve
> a problem that has been solved clearly in other environments. As far as I'm
> concerned, the English language-like features are great for the new
> programmer, but actually doing useful work pretty quickly deviates from
> English like syntax. I'm thinking of Adobe Director rather than C++ or
> JavaScript. To me, LC's greatest strength is in its UI support and cross
> platform capabilities.
>
> Best,
> Bill P
>
> William Prothero
> http://es.earthednet.org
___
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: Primes and primality checking

2017-04-25 Thread dunbarx via use-livecode
Devin.

i don't get an overflow error til 309 digits. Where did the guy set a limit?

Making some sort of composite gadget, like we played around with a while ago
on the forum to allow long multiplications, additions, etc. without limit
would be a general solution without, er, limit.

Maybe Hermann can step in?

But post your offering. As you say, it will firm LC within stack overflow.

Craig



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Primes-and-primality-checking-tp4714219p4714234.html
Sent from the Revolution - User mailing list archive at Nabble.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: Make numberFormat even better

2017-04-25 Thread Mike Kerner via use-livecode
Way to steal my post and make it eloquent, Bill :-P

On Tue, Apr 25, 2017 at 12:57 PM, prothero--- via use-livecode <
use-livecode@lists.runrev.com> wrote:

> My point was to set variable types when they need to be set explicitly.
> Those who don't want to set a type can just use forget about it. Once you
> get into more scientific, numeric type applications, the precision and type
> of variables can get crucial. To me, the suggested changes to numberformat,
> adding numberformatXL, etc, just make the situation more complex rather
> than applying a simple, direct solution that is common in other programming
> languages. I see no advantage in going through extreme gymnastics to solve
> a problem that has been solved clearly in other environments. As far as I'm
> concerned, the English language-like features are great for the new
> programmer, but actually doing useful work pretty quickly deviates from
> English like syntax. I'm thinking of Adobe Director rather than C++ or
> JavaScript. To me, LC's greatest strength is in its UI support and cross
> platform capabilities.
>
> Best,
> Bill P
>
> William Prothero
> http://es.earthednet.org
>
> > On Apr 25, 2017, at 9:27 AM, Bob Sneidar via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Variable Typing! EEEK!!!
> >
> > Bob S
> >
> >
> >> On Apr 25, 2017, at 08:33 , prothero--- via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >>
> >> Folks,
> >> What I see in this discussion is extreme efforts to do something that
> is straightforward and transparent in other languages (I can see these
> suggested solutions as creating unnecessary complexity).That is to simply
> declare some variable types.
> >>
> >> E.g.
> >> variable ix=integer double
> >> variable yzz=real
> >>
> >> Etc, etc
> >>
> >> Variables that are not declared would be handled in the same way they
> are now, by default.
> >>
> >> Just my 2 cents.
> >> Bill P
> >>
> >> William Prothero
> >> http://es.earthednet.org
> >>
> >>> On Apr 25, 2017, at 7:31 AM, Roger Eller via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >>>
> >>> +1
> >>>
> >>> And if you must introduce a arguably newer/better term, please make its
> >>> syntax more English-like and less code-like.  This _is_ LiveCode.
> Cryptic
> >>> is for those other languages.  /2_cents
> >>>
> >>> ~Roger
> >>>
> >>>
> >>> On Tue, Apr 25, 2017 at 10:11 AM, Rick Harrison via use-livecode <
> >>> use-livecode@lists.runrev.com> wrote:
> >>>
>  Hi Lagi,
> 
>  I can’t agree more.  Never break anyone’s code if at all possible.
>  Create a new numberformat like NumberFormatXL or something
>  similar.  Leave the old working stuff alone.
> 
>  Just my 2 cents for the day!
> 
>  Rick
> 
> > On Apr 25, 2017, at 6:48 AM, Lagi Pittas via use-livecode <
>  use-livecode@lists.runrev.com> wrote:
> >
> > Hi
> >
> > I don't know why you want to adapt/enhance the number format as that
>  could
> > break already working code that uses the nuances of numberformat
> already.
> >
> > Why not add an instruction NumberFormatXL and create the an Excel
> version
> > like Curry says. You won't have to jump through hoops to make sure it
> > doesn't break anything, you can fix what's wrong(?) and you can add
> stuff
> > in there without affecting old code, plus and with Curry's experience
>  with
> > spreadlib you probably have a lot of the problems to solve sorted.
> >
> > Now my usual caveat "Everything is easy for the man who doesn't have
> to
>  do
> > it himself" - but I haven't seen anything that Mark and his team
> can't
>  do -
> > usually the problems stem from trying no to break older stuff.
> >
> > I think in this case adding a new command would make it easier all
> round.
> > While you're at it why not put a callback/ or in  wordpress parlance
> an
> > "AddAction"  option so you can add to the formatting on the fly?
> >
> > Regards Lagi
> >
> 
> 
>  ___
>  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
> >>
> >>
> >> ___
> >> 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

Re: Font embedding for iOS in LC9

2017-04-25 Thread Mike Kerner via use-livecode
Try with 8 to make sure fonts work.  There is a font bug in 9 on devices
with retina screens.

On Tue, Apr 25, 2017 at 12:33 PM, Keith Martin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 25 Apr 2017, at 15:36, Andrew Bell via use-livecode wrote:
>
> Digging around through my stack I found some old commented out code for
>> "start using font file tFont" but that seems to be Mac/PC standalone code
>> not needed for mobile.
>>
>
> Not actual insight, at least in the sense of answers, but I found a way to
> install fonts in iOS. They need to be base64 encoded and saved as
> .mobileconfig documents in order to work. I made a tool (using LiveCode,
> natch) to do this; it's available at http://thehelpful.com/iosfonts/
>
> One day I must upload the stack for others to grab! But so many other
> things to do... :-/
>
> k
>
>
> ---
>
> Keith Martin
> Senior Lecturer, LCC (University of the Arts London)
> President, http://IVRPA.org
> http://PanoramaPhotographer.com
> http://thatkeith.com
> +44 (0)7909541365
>
> ---
>
> ___
> 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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: Maje numberFormst even better

2017-04-25 Thread prothero--- via use-livecode
Richard,
I'd love to see the behavior script. Soon I'll be needing something like that. 
I can roll my own, but will save a lot of time if there is a shareable version.
Bill P

William Prothero
http://es.earthednet.org

> On Apr 25, 2017, at 9:53 AM, Richard Gaskin via use-livecode 
>  wrote:
> 
> Roland Huettmann wrote:
> 
> > Here is a link for Excel cell formatting:
> >
> > 
> 
> Good guidance - thanks for including the link.
> 
> 
> > Millions of users know this formatting style. Why reinvent the wheel?
> > Numberformat could eventually be enhanced to this direction...
> >
> > I still also wished to see it as a property-set of fields, but built
> > in, not "just" as a custom property. Dreaming...). It is a simple
> > user wish, not a recipe about how to do it. I understand that it is
> > difficult to do.
> 
> Like Lagi says, "Everything is easy for the man who doesn't have to do
> it himself." :)
> 
> Why not have both, "good" now and "best" later?
> 
> Even if the core team were in a position to drop other priorities to add 
> formatting to fields, they couldn't do it any faster than a scripter who has 
> the advantage of doing it in LiveCode itself.
> 
> There are many things only the engine team can do, and for those we have no 
> choice of what language they must be done in:  the engine is written in C++, 
> so it requires a C++ expert to work on engine features.
> 
> As a attractive as this proposal for field-level numeric formatting is, there 
> are many other tasks already in queue (it's been many years since I was able 
> to play a video in Linux, and others have their own lists of preferred 
> priorities as well).
> 
> So even the most optimistic projection of engine team availability for this 
> field enhancement would be months down the road.
> 
> But we could have this by this afternoon with a behavior script.
> 
> Why wait?
> 
> Sure, an engine-level version would execute faster, and it's worth doing for 
> language design and workflow reasons as well.
> 
> But a very useful behavior script could be crafted in an afternoon, and it 
> would not only provide immediate value to those using it, but help with the 
> design considerations that would have to go into an engine-based property 
> later on anyway.
> 
> So we could consider the behavior script a prototype, but even better it can 
> be used to provide immediate useful results.
> 
> -- 
> 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


___
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: Make numberFormat even better

2017-04-25 Thread prothero--- via use-livecode
My point was to set variable types when they need to be set explicitly. Those 
who don't want to set a type can just use forget about it. Once you get into 
more scientific, numeric type applications, the precision and type of variables 
can get crucial. To me, the suggested changes to numberformat, adding 
numberformatXL, etc, just make the situation more complex rather than applying 
a simple, direct solution that is common in other programming languages. I see 
no advantage in going through extreme gymnastics to solve a problem that has 
been solved clearly in other environments. As far as I'm concerned, the English 
language-like features are great for the new programmer, but actually doing 
useful work pretty quickly deviates from English like syntax. I'm thinking of 
Adobe Director rather than C++ or JavaScript. To me, LC's greatest strength is 
in its UI support and cross platform capabilities.

Best,
Bill P

William Prothero
http://es.earthednet.org

> On Apr 25, 2017, at 9:27 AM, Bob Sneidar via use-livecode 
>  wrote:
> 
> Variable Typing! EEEK!!! 
> 
> Bob S
> 
> 
>> On Apr 25, 2017, at 08:33 , prothero--- via use-livecode 
>>  wrote:
>> 
>> Folks,
>> What I see in this discussion is extreme efforts to do something that is 
>> straightforward and transparent in other languages (I can see these 
>> suggested solutions as creating unnecessary complexity).That is to simply 
>> declare some variable types.
>> 
>> E.g.
>> variable ix=integer double
>> variable yzz=real 
>> 
>> Etc, etc
>> 
>> Variables that are not declared would be handled in the same way they are 
>> now, by default.
>> 
>> Just my 2 cents.
>> Bill P
>> 
>> William Prothero
>> http://es.earthednet.org
>> 
>>> On Apr 25, 2017, at 7:31 AM, Roger Eller via use-livecode 
>>>  wrote:
>>> 
>>> +1
>>> 
>>> And if you must introduce a arguably newer/better term, please make its
>>> syntax more English-like and less code-like.  This _is_ LiveCode.  Cryptic
>>> is for those other languages.  /2_cents
>>> 
>>> ~Roger
>>> 
>>> 
>>> On Tue, Apr 25, 2017 at 10:11 AM, Rick Harrison via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
>>> 
 Hi Lagi,
 
 I can’t agree more.  Never break anyone’s code if at all possible.
 Create a new numberformat like NumberFormatXL or something
 similar.  Leave the old working stuff alone.
 
 Just my 2 cents for the day!
 
 Rick
 
> On Apr 25, 2017, at 6:48 AM, Lagi Pittas via use-livecode <
 use-livecode@lists.runrev.com> wrote:
> 
> Hi
> 
> I don't know why you want to adapt/enhance the number format as that
 could
> break already working code that uses the nuances of numberformat already.
> 
> Why not add an instruction NumberFormatXL and create the an Excel version
> like Curry says. You won't have to jump through hoops to make sure it
> doesn't break anything, you can fix what's wrong(?) and you can add stuff
> in there without affecting old code, plus and with Curry's experience
 with
> spreadlib you probably have a lot of the problems to solve sorted.
> 
> Now my usual caveat "Everything is easy for the man who doesn't have to
 do
> it himself" - but I haven't seen anything that Mark and his team can't
 do -
> usually the problems stem from trying no to break older stuff.
> 
> I think in this case adding a new command would make it easier all round.
> While you're at it why not put a callback/ or in  wordpress parlance an
> "AddAction"  option so you can add to the formatting on the fly?
> 
> Regards Lagi
> 
 
 
 ___
 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
>> 
>> 
>> ___
>> 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


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage 

Re: Maje numberFormst even better

2017-04-25 Thread Richard Gaskin via use-livecode

Roland Huettmann wrote:

> Here is a link for Excel cell formatting:
>
> 



Good guidance - thanks for including the link.


> Millions of users know this formatting style. Why reinvent the wheel?
> Numberformat could eventually be enhanced to this direction...
>
> I still also wished to see it as a property-set of fields, but built
> in, not "just" as a custom property. Dreaming...). It is a simple
> user wish, not a recipe about how to do it. I understand that it is
> difficult to do.

Like Lagi says, "Everything is easy for the man who doesn't have to do
it himself." :)

Why not have both, "good" now and "best" later?

Even if the core team were in a position to drop other priorities to add 
formatting to fields, they couldn't do it any faster than a scripter who 
has the advantage of doing it in LiveCode itself.


There are many things only the engine team can do, and for those we have 
no choice of what language they must be done in:  the engine is written 
in C++, so it requires a C++ expert to work on engine features.


As a attractive as this proposal for field-level numeric formatting is, 
there are many other tasks already in queue (it's been many years since 
I was able to play a video in Linux, and others have their own lists of 
preferred priorities as well).


So even the most optimistic projection of engine team availability for 
this field enhancement would be months down the road.


But we could have this by this afternoon with a behavior script.

Why wait?

Sure, an engine-level version would execute faster, and it's worth doing 
for language design and workflow reasons as well.


But a very useful behavior script could be crafted in an afternoon, and 
it would not only provide immediate value to those using it, but help 
with the design considerations that would have to go into an 
engine-based property later on anyway.


So we could consider the behavior script a prototype, but even better it 
can be used to provide immediate useful results.


--
 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: Font embedding for iOS in LC9

2017-04-25 Thread Keith Martin via use-livecode

On 25 Apr 2017, at 15:36, Andrew Bell via use-livecode wrote:

Digging around through my stack I found some old commented out code 
for "start using font file tFont" but that seems to be Mac/PC 
standalone code not needed for mobile.


Not actual insight, at least in the sense of answers, but I found a way 
to install fonts in iOS. They need to be base64 encoded and saved as 
.mobileconfig documents in order to work. I made a tool (using LiveCode, 
natch) to do this; it's available at http://thehelpful.com/iosfonts/


One day I must upload the stack for others to grab! But so many other 
things to do... :-/


k


---

Keith Martin
Senior Lecturer, LCC (University of the Arts London)
President, http://IVRPA.org
http://PanoramaPhotographer.com
http://thatkeith.com
+44 (0)7909541365

---
___
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: Make numberFormat even better

2017-04-25 Thread Mark Waddingham via use-livecode

On 2017-04-25 12:48, Lagi Pittas via use-livecode wrote:

Hi

I don't know why you want to adapt/enhance the number format as that 
could
break already working code that uses the nuances of numberformat 
already.


Although it may have not been 100% clear in my previous post, as 
numberFormat
in LiveCode is just string formatting (it doesn't do what it does in 
HyperCard
where it also controls numerical precision of each arithmetic operation) 
it can be

extended without affecting existing code.

Why not add an instruction NumberFormatXL and create the an Excel 
version

like Curry says. You won't have to jump through hoops to make sure it
doesn't break anything, you can fix what's wrong(?) and you can add 
stuff
in there without affecting old code, plus and with Curry's experience 
with

spreadlib you probably have a lot of the problems to solve sorted.


When would numberFormatXL be used instead of numberFormat? I presume if 
it has

been explicitly set in local context... In which case...

There's no point in introducing a new property whose only action is to 
subsume
the action of the previous one since that is equivalent to just 
extending the

original property.

Warmest Regards,

Mark.

P.S. The main suggestion in my previous post wasn't about numberFormat 
per-se
more about restricting its domain slightly (to things which are not 
integers)
in order to (1) solve a problem with numeric representation (wouldn't it 
be nice
to have infinite precision integers?) and (2) make the language more 
ergonomic

when dealing with numeric arrays - allowing to use 'numberFormat'
(or whatever) *and* numeric arrays.

--
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: Make numberFormat even better

2017-04-25 Thread Bob Sneidar via use-livecode
Variable Typing! EEEK!!! 

Bob S


> On Apr 25, 2017, at 08:33 , prothero--- via use-livecode 
>  wrote:
> 
> Folks,
> What I see in this discussion is extreme efforts to do something that is 
> straightforward and transparent in other languages (I can see these suggested 
> solutions as creating unnecessary complexity).That is to simply declare some 
> variable types.
> 
> E.g.
> variable ix=integer double
> variable yzz=real 
> 
> Etc, etc
> 
> Variables that are not declared would be handled in the same way they are 
> now, by default.
> 
> Just my 2 cents.
> Bill P
> 
> William Prothero
> http://es.earthednet.org
> 
>> On Apr 25, 2017, at 7:31 AM, Roger Eller via use-livecode 
>>  wrote:
>> 
>> +1
>> 
>> And if you must introduce a arguably newer/better term, please make its
>> syntax more English-like and less code-like.  This _is_ LiveCode.  Cryptic
>> is for those other languages.  /2_cents
>> 
>> ~Roger
>> 
>> 
>> On Tue, Apr 25, 2017 at 10:11 AM, Rick Harrison via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> 
>>> Hi Lagi,
>>> 
>>> I can’t agree more.  Never break anyone’s code if at all possible.
>>> Create a new numberformat like NumberFormatXL or something
>>> similar.  Leave the old working stuff alone.
>>> 
>>> Just my 2 cents for the day!
>>> 
>>> Rick
>>> 
 On Apr 25, 2017, at 6:48 AM, Lagi Pittas via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
 
 Hi
 
 I don't know why you want to adapt/enhance the number format as that
>>> could
 break already working code that uses the nuances of numberformat already.
 
 Why not add an instruction NumberFormatXL and create the an Excel version
 like Curry says. You won't have to jump through hoops to make sure it
 doesn't break anything, you can fix what's wrong(?) and you can add stuff
 in there without affecting old code, plus and with Curry's experience
>>> with
 spreadlib you probably have a lot of the problems to solve sorted.
 
 Now my usual caveat "Everything is easy for the man who doesn't have to
>>> do
 it himself" - but I haven't seen anything that Mark and his team can't
>>> do -
 usually the problems stem from trying no to break older stuff.
 
 I think in this case adding a new command would make it easier all round.
 While you're at it why not put a callback/ or in  wordpress parlance an
 "AddAction"  option so you can add to the formatting on the fly?
 
 Regards Lagi
 
>>> 
>>> 
>>> ___
>>> 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
> 
> 
> ___
> 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: Make numberFormat even better

2017-04-25 Thread Mark Wieder via use-livecode

On 04/25/2017 08:33 AM, prothero--- via use-livecode wrote:

Folks,
What I see in this discussion is extreme efforts to do something that is 
straightforward and transparent in other languages (I can see these suggested 
solutions as creating unnecessary complexity).That is to simply declare some 
variable types.

E.g.
variable ix=integer double
variable yzz=real

Etc, etc

Variables that are not declared would be handled in the same way they are now, 
by default.

Just my 2 cents.
Bill P


Heh. Don't hold your breath waiting for this one.
Requested back in 2005 (version 2.5.1).

http://quality.livecode.com/show_bug.cgi?id=2783

--
 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: Application not working with MacOSX 10.6 (maybe due to tsNet)

2017-04-25 Thread Hakima Manseri via use-livecode

I'll look into that.
Thanks !


Le 25/04/2017 à 17:52, Ludovic THEBAULT via use-livecode a écrit :

Le 25 avr. 2017 à 17:47, Hakima Manseri via use-livecode 
 a écrit :

Hi everyone,

I'm a LC newbie and have been trying to use an application a colleague is 
developping with LiveCode 8.1.3

It works with MacOSX 10.9 and above but fails to launch for previous version. 
This was surprising since we thought LiveCode was still compatible with the 
10.6 version.

I have this message in the log :


Apr 17 20:49:15 myuser myapp[787]: ***
__NSAutoreleaseNoPool(): Object 0xd82460 of class NSMachPort
autoreleased with no pool in place - just leaking
Apr 17 20:49:16 myuser myapp[787]: Error loading
/Users/myuser/myapp.app/Contents/MacOS/Externals/tsNet.bundle/Contents/MacOS/tsNet:
  
dlopen(/Users/myuser/myapp.app/Contents/MacOS/Externals/tsNet.bundle/Contents/MacOS/tsNet,
 262): Symbol not found: _kSecImportExportPassphrase\n  Referenced from:
  
/Users/myuser/myapp.app/Contents/MacOS/Externals/tsNet.bundle/Contents/MacOS/tsNet\n
  Expected in:
/System/Library/Frameworks/Security.framework/Versions/A/Security\n in
/Users/myuser/myapp.app/Contents/MacOS/Externals/tsNet.bundle/Contents/MacOS/tsNet
Apr 17 20:49:16: --- last message repeated 1 time ---
Apr 17 20:49:16 myuser [0x0-0x40040].myapp-Org.[787]: Startup error - failed to 
load external
Apr 17 20:49:16 myuser com.apple.launchd.peruser.501[208] 
([0x0-0x40040].myapp-Org.[787]): Exited with exit code: 255

I've looked up the "_kSecImportExportPassphrase" variable and it seems that 
there may be a difference between iOS and MacOSX regarding this variable : 
http://stackoverflow.com/questions/17348420/private-key-signature-different-on-ios-and-macosx#17349506

So is tsNet the culprit ? Or is this a problem in the way we add the external ? 
Or something else ?

Thanks in advance for your help.

Hakima


See http://quality.livecode.com/show_bug.cgi?id=19035 


Workaround : compile standalone with Livecode 8.0
___
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



--
Hakima Manseri
Ingénieure développement et bases de données

Tél : 04 67 14 58 42
Site : http://asm.cnrs.fr/
Dev@LR : http://devatlr.univ-montp2.fr/


___
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: Application not working with MacOSX 10.6 (maybe due to tsNet)

2017-04-25 Thread Ludovic THEBAULT via use-livecode

> Le 25 avr. 2017 à 17:47, Hakima Manseri via use-livecode 
>  a écrit :
> 
> Hi everyone,
> 
> I'm a LC newbie and have been trying to use an application a colleague is 
> developping with LiveCode 8.1.3
> 
> It works with MacOSX 10.9 and above but fails to launch for previous version. 
> This was surprising since we thought LiveCode was still compatible with the 
> 10.6 version.
> 
> I have this message in the log :
> 
>> Apr 17 20:49:15 myuser myapp[787]: ***
>> __NSAutoreleaseNoPool(): Object 0xd82460 of class NSMachPort
>> autoreleased with no pool in place - just leaking
>> Apr 17 20:49:16 myuser myapp[787]: Error loading
>> /Users/myuser/myapp.app/Contents/MacOS/Externals/tsNet.bundle/Contents/MacOS/tsNet:
>>  
>> dlopen(/Users/myuser/myapp.app/Contents/MacOS/Externals/tsNet.bundle/Contents/MacOS/tsNet,
>>  262): Symbol not found: _kSecImportExportPassphrase\n  Referenced from:
>>  
>> /Users/myuser/myapp.app/Contents/MacOS/Externals/tsNet.bundle/Contents/MacOS/tsNet\n
>>  Expected in:
>> /System/Library/Frameworks/Security.framework/Versions/A/Security\n in
>> /Users/myuser/myapp.app/Contents/MacOS/Externals/tsNet.bundle/Contents/MacOS/tsNet
>> Apr 17 20:49:16: --- last message repeated 1 time ---
>> Apr 17 20:49:16 myuser [0x0-0x40040].myapp-Org.[787]: Startup error - failed 
>> to load external
>> Apr 17 20:49:16 myuser com.apple.launchd.peruser.501[208] 
>> ([0x0-0x40040].myapp-Org.[787]): Exited with exit code: 255
> I've looked up the "_kSecImportExportPassphrase" variable and it seems that 
> there may be a difference between iOS and MacOSX regarding this variable : 
> http://stackoverflow.com/questions/17348420/private-key-signature-different-on-ios-and-macosx#17349506
> 
> So is tsNet the culprit ? Or is this a problem in the way we add the external 
> ? Or something else ?
> 
> Thanks in advance for your help.
> 
> Hakima
> 

See http://quality.livecode.com/show_bug.cgi?id=19035 


Workaround : compile standalone with Livecode 8.0 
___
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

Application not working with MacOSX 10.6 (maybe due to tsNet)

2017-04-25 Thread Hakima Manseri via use-livecode

Hi everyone,

I'm a LC newbie and have been trying to use an application a colleague 
is developping with LiveCode 8.1.3


It works with MacOSX 10.9 and above but fails to launch for previous 
version. This was surprising since we thought LiveCode was still 
compatible with the 10.6 version.


I have this message in the log :


Apr 17 20:49:15 myuser myapp[787]: ***
__NSAutoreleaseNoPool(): Object 0xd82460 of class NSMachPort
autoreleased with no pool in place - just leaking
Apr 17 20:49:16 myuser myapp[787]: Error loading
/Users/myuser/myapp.app/Contents/MacOS/Externals/tsNet.bundle/Contents/MacOS/tsNet:
  
dlopen(/Users/myuser/myapp.app/Contents/MacOS/Externals/tsNet.bundle/Contents/MacOS/tsNet, 262): Symbol not found: _kSecImportExportPassphrase\n  Referenced from:
  
/Users/myuser/myapp.app/Contents/MacOS/Externals/tsNet.bundle/Contents/MacOS/tsNet\n

  Expected in:
/System/Library/Frameworks/Security.framework/Versions/A/Security\n in
/Users/myuser/myapp.app/Contents/MacOS/Externals/tsNet.bundle/Contents/MacOS/tsNet
Apr 17 20:49:16: --- last message repeated 1 time ---
Apr 17 20:49:16 myuser [0x0-0x40040].myapp-Org.[787]: Startup error - failed to 
load external
Apr 17 20:49:16 myuser com.apple.launchd.peruser.501[208] 
([0x0-0x40040].myapp-Org.[787]): Exited with exit code: 255
I've looked up the "_kSecImportExportPassphrase" variable and it seems 
that there may be a difference between iOS and MacOSX regarding this 
variable : 
http://stackoverflow.com/questions/17348420/private-key-signature-different-on-ios-and-macosx#17349506


So is tsNet the culprit ? Or is this a problem in the way we add the 
external ? Or something else ?


Thanks in advance for your help.

Hakima



--
Hakima Manseri
Ingénieure développement et bases de données

Tél : 04 67 14 58 42
Site : http://asm.cnrs.fr/
Dev@LR : http://devatlr.univ-montp2.fr/


___
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: Make numberFormat even better

2017-04-25 Thread prothero--- via use-livecode
Folks,
What I see in this discussion is extreme efforts to do something that is 
straightforward and transparent in other languages (I can see these suggested 
solutions as creating unnecessary complexity).That is to simply declare some 
variable types.

E.g.
variable ix=integer double
variable yzz=real 

Etc, etc

Variables that are not declared would be handled in the same way they are now, 
by default.

Just my 2 cents.
Bill P

William Prothero
http://es.earthednet.org

> On Apr 25, 2017, at 7:31 AM, Roger Eller via use-livecode 
>  wrote:
> 
> +1
> 
> And if you must introduce a arguably newer/better term, please make its
> syntax more English-like and less code-like.  This _is_ LiveCode.  Cryptic
> is for those other languages.  /2_cents
> 
> ~Roger
> 
> 
> On Tue, Apr 25, 2017 at 10:11 AM, Rick Harrison via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> Hi Lagi,
>> 
>> I can’t agree more.  Never break anyone’s code if at all possible.
>> Create a new numberformat like NumberFormatXL or something
>> similar.  Leave the old working stuff alone.
>> 
>> Just my 2 cents for the day!
>> 
>> Rick
>> 
>>> On Apr 25, 2017, at 6:48 AM, Lagi Pittas via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>>> 
>>> Hi
>>> 
>>> I don't know why you want to adapt/enhance the number format as that
>> could
>>> break already working code that uses the nuances of numberformat already.
>>> 
>>> Why not add an instruction NumberFormatXL and create the an Excel version
>>> like Curry says. You won't have to jump through hoops to make sure it
>>> doesn't break anything, you can fix what's wrong(?) and you can add stuff
>>> in there without affecting old code, plus and with Curry's experience
>> with
>>> spreadlib you probably have a lot of the problems to solve sorted.
>>> 
>>> Now my usual caveat "Everything is easy for the man who doesn't have to
>> do
>>> it himself" - but I haven't seen anything that Mark and his team can't
>> do -
>>> usually the problems stem from trying no to break older stuff.
>>> 
>>> I think in this case adding a new command would make it easier all round.
>>> While you're at it why not put a callback/ or in  wordpress parlance an
>>> "AddAction"  option so you can add to the formatting on the fly?
>>> 
>>> Regards Lagi
>>> 
>> 
>> 
>> ___
>> 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


___
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

Maje numberFormst even better

2017-04-25 Thread Roland Huettmann via use-livecode
Very interesting discussion. Many thanks to all for deeper insight!

Here is a link for Excel cell formatting:

https://support.microsoft.com/en-us/help/264372/how-to-control-and-understand-settings-in-the-format-cells-dialog-box-in-excel

Millions of users know this formatting style. Why reinvent the wheel?
Numberformat could eventually be enhanced to this direction...

I still also wished to see it as a property-set of fields, but built in,
not "just" as a custom property. Dreaming...). It is a simple user wish,
not a recipe about how to do it. I understand that it is difficult to do.

Roland
___
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


Primes and primality checking

2017-04-25 Thread Devin Asay via use-livecode
Hey folks,

This guy over on stackoverflow.com is asking for help 
generating and testing very large prime numbers.
http://stackoverflow.com/questions/43600252/generate-and-check-the-primality-of-very-large-numbers-in-livecode

I came up with this:

on mouseUp
local tNum
put fld "testNum" into tNum
put isPrime(tNum) into fld "report"
end mouseUp

function isPrime pNum
if pNum <> 2 AND pNum mod 2 = 0 then
return false
end if
repeat with x = 3 to sqrt(pNum) step 2
if pNum mod x = 0 then
return false
end if
end repeat
return true
end isPrime


However, it doesn’t seem to be reliable for very large numbers (> 100 digits) 
as the fellow wants. My math skills are pretty creaky. Anybody want a crack at 
this? It’s a fun challenge, plus it can boost LC’s presence on stackoverflow.

Cheers,

Devin

Devin Asay
Director
Office of Digital Humanities
Brigham Young University

___
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

Font embedding for iOS in LC9

2017-04-25 Thread Andrew Bell via use-livecode


I've been compiling an iOS app in 8.1.x but am trying to make the jump  
to 9.0dp6 for the cool new Business features like Remote Debugging.  
Things seemed to be working ok until I compiled a development version  
and installed it on my iPhone to find all my custom fonts were  
replaced with bland defaults.


In the Standalone Settings I have an entire fonts/* folder set under  
Copy Files and the exact font selected for various fields in the  
Property Inspector (Roboto Condensed and Vacer Serif Bold, but  
shouldn't make a difference). Fonts display correctly in LiveCode,  
fonts display correctly in iOS Simulator, but fonts revert to some  
default in the compiled standalone.


Nothing has changed with the files, filepaths, or font references  
between the working versions compiled in LC8 and the non-working LC9  
compile.


Digging around through my stack I found some old commented out code  
for "start using font file tFont" but that seems to be Mac/PC  
standalone code not needed for mobile. I looked in the release notes  
for LC9 and the forum, but didn't see any mention to a new filepath  
for fonts. Does anyone have any insight?


--Andrew Bell
--MidWest Coast Media


___
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: Make numberFormat even better

2017-04-25 Thread Roger Eller via use-livecode
+1

And if you must introduce a arguably newer/better term, please make its
syntax more English-like and less code-like.  This _is_ LiveCode.  Cryptic
is for those other languages.  /2_cents

~Roger


On Tue, Apr 25, 2017 at 10:11 AM, Rick Harrison via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi Lagi,
>
> I can’t agree more.  Never break anyone’s code if at all possible.
> Create a new numberformat like NumberFormatXL or something
> similar.  Leave the old working stuff alone.
>
> Just my 2 cents for the day!
>
> Rick
>
> > On Apr 25, 2017, at 6:48 AM, Lagi Pittas via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Hi
> >
> > I don't know why you want to adapt/enhance the number format as that
> could
> > break already working code that uses the nuances of numberformat already.
> >
> > Why not add an instruction NumberFormatXL and create the an Excel version
> > like Curry says. You won't have to jump through hoops to make sure it
> > doesn't break anything, you can fix what's wrong(?) and you can add stuff
> > in there without affecting old code, plus and with Curry's experience
> with
> > spreadlib you probably have a lot of the problems to solve sorted.
> >
> > Now my usual caveat "Everything is easy for the man who doesn't have to
> do
> > it himself" - but I haven't seen anything that Mark and his team can't
> do -
> > usually the problems stem from trying no to break older stuff.
> >
> > I think in this case adding a new command would make it easier all round.
> > While you're at it why not put a callback/ or in  wordpress parlance an
> > "AddAction"  option so you can add to the formatting on the fly?
> >
> > Regards Lagi
> >
>
>
> ___
> 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: Make numberFormat even better

2017-04-25 Thread Rick Harrison via use-livecode
Hi Lagi,

I can’t agree more.  Never break anyone’s code if at all possible.
Create a new numberformat like NumberFormatXL or something
similar.  Leave the old working stuff alone. 

Just my 2 cents for the day!

Rick

> On Apr 25, 2017, at 6:48 AM, Lagi Pittas via use-livecode 
>  wrote:
> 
> Hi
> 
> I don't know why you want to adapt/enhance the number format as that could
> break already working code that uses the nuances of numberformat already.
> 
> Why not add an instruction NumberFormatXL and create the an Excel version
> like Curry says. You won't have to jump through hoops to make sure it
> doesn't break anything, you can fix what's wrong(?) and you can add stuff
> in there without affecting old code, plus and with Curry's experience with
> spreadlib you probably have a lot of the problems to solve sorted.
> 
> Now my usual caveat "Everything is easy for the man who doesn't have to do
> it himself" - but I haven't seen anything that Mark and his team can't do -
> usually the problems stem from trying no to break older stuff.
> 
> I think in this case adding a new command would make it easier all round.
> While you're at it why not put a callback/ or in  wordpress parlance an
> "AddAction"  option so you can add to the formatting on the fly?
> 
> Regards Lagi
> 


___
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: Make numberFormat even better

2017-04-25 Thread Mike Kerner via use-livecode
Would it make sense to say that if a container is strongly typed (i.e.
declared as type x) it is type x and if it is not then it is not?  Why
can't you have it both ways?

On Tue, Apr 25, 2017 at 6:48 AM, Lagi Pittas via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi
>
> I don't know why you want to adapt/enhance the number format as that could
> break already working code that uses the nuances of numberformat already.
>
> Why not add an instruction NumberFormatXL and create the an Excel version
> like Curry says. You won't have to jump through hoops to make sure it
> doesn't break anything, you can fix what's wrong(?) and you can add stuff
> in there without affecting old code, plus and with Curry's experience with
> spreadlib you probably have a lot of the problems to solve sorted.
>
> Now my usual caveat "Everything is easy for the man who doesn't have to do
> it himself" - but I haven't seen anything that Mark and his team can't do -
> usually the problems stem from trying no to break older stuff.
>
> I think in this case adding a new command would make it easier all round.
> While you're at it why not put a callback/ or in  wordpress parlance an
>  "AddAction"  option so you can add to the formatting on the fly?
>
> Regards Lagi
>
> On 25 April 2017 at 09:38, Mark Waddingham via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > On 2017-04-25 09:01, Curry Kenworthy via use-livecode wrote:
> >
> >> To handle arrays better without requiring more lines of code, how
> >> about making numberFormat itself an array with at least two parts?
> >> Similar to the way the clipboardData has parts.
> >>
> >> Using it without a key works exactly like before, by setting both parts,
> >> ie:
> >>
> >> -- (assume i=binary 5 and starting format=default)
> >>
> >> set numberformat to "0.0"
> >> put "#" & i into a[i] --> a["5.0"] = "#5.0"
> >>
> >> If you want just the regular strings formatted and not any array keys,
> >> or vice versa, use the appropriate part:
> >>
> >> set numberformat["text"] to "0.0"
> >> put "#" & i into a[i] --> a["5"] = "#5.0"
> >>
> >> (or)
> >>
> >> set numberformat["keys"] to "0.0"
> >> put "#" & i into a[i] --> a["5.0"] = "#5"
> >>
> >
> > This is certainly an idea - however, I wonder if it isn't quite
> addressing
> > the crux of the issue.
> >
> > Arrays in LiveCode serve two purposes - both lists (if integer keyed,
> > dense, starting from 1) and dictionaries (all other types). The
> distinction
> > is made purely on the string structure of the keys (for all intents and
> > purposes) and what keys are present. Indeed for a LiveCode array to be
> > treated as a list the keys *must* be very strictly formatted as integers
> -
> > there must be no fractional part (i.e. "1.0" is *not* considered the same
> > key as "1").
> >
> > For dictionaries, then having the numberFormat affect your numbers isn't
> > really an issue - as the keys are strings, they have to be strings, there
> > is no option.
> >
> > For lists, however, what is really happening is that they are being
> > indexed by integers. So, could it be that the problem in LiveCode
> > is that it doesn't distinguish between integers and non-integers?
> >
> > This actually alludes to another problem I've been struggling with
> > recently (and, indeed, partly why this numberFormat problem is so
> > interesting).
> >
> > At the moment LiveCode's arithmetic uses 64-bit doubles universally. This
> > gives a relatively consistent arithmetic, but it has a significant limit:
> > you cannot represent 64-bit integers accurately - only up to 53-bit.
> > Indeed,
> > the current semantics basically mean that you can do integer computations
> > up
> > to 53-bits and then things 'gracefully' degrade in precision. The problem
> > is that I'm not sure it is feasible to extend the allowed size of
> integers
> > (having them arbitrary precision would be really neat!) whilst preserving
> > this graceful degradation to double (at least not in a performant way).
> >
> > One solution here is to have (internally at least) two distinct numeric
> > types - integers and (inexact) reals - with the common-sense rules:
> >
> >integer int_op integer -> integer (+, -, *, div, mod are int_ops)
> >integer op real -> real (+, -, *, /, div, mod are ops)
> >real op integer -> real
> >real op real -> real
> >
> > The question, now, is that how would we distinguish between a string
> > we want to auto-convert to an integer, and a string we want to
> > auto-convert to a real?
> >
> > One option here is to make it so that integers are always of the form
> >
> >   [1-9][0-9]+
> >
> > With a string being considered a real if it is any other valid numeric
> > string:
> >
> >   "1" is an integer
> >   "1.", "1e10", "1.03", "1.0" are all reals.
> >
> > If we made this distinction, then it would be viable to make it so that
> > numberFormat *only* affects reals:
> >
> >   put 1 + 0 into tInteger
> >   put 1. + 0 into tReal
> >   set the 

Re: Make numberFormat even better

2017-04-25 Thread Lagi Pittas via use-livecode
Hi

I don't know why you want to adapt/enhance the number format as that could
break already working code that uses the nuances of numberformat already.

Why not add an instruction NumberFormatXL and create the an Excel version
like Curry says. You won't have to jump through hoops to make sure it
doesn't break anything, you can fix what's wrong(?) and you can add stuff
in there without affecting old code, plus and with Curry's experience with
spreadlib you probably have a lot of the problems to solve sorted.

Now my usual caveat "Everything is easy for the man who doesn't have to do
it himself" - but I haven't seen anything that Mark and his team can't do -
usually the problems stem from trying no to break older stuff.

I think in this case adding a new command would make it easier all round.
While you're at it why not put a callback/ or in  wordpress parlance an
 "AddAction"  option so you can add to the formatting on the fly?

Regards Lagi

On 25 April 2017 at 09:38, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2017-04-25 09:01, Curry Kenworthy via use-livecode wrote:
>
>> To handle arrays better without requiring more lines of code, how
>> about making numberFormat itself an array with at least two parts?
>> Similar to the way the clipboardData has parts.
>>
>> Using it without a key works exactly like before, by setting both parts,
>> ie:
>>
>> -- (assume i=binary 5 and starting format=default)
>>
>> set numberformat to "0.0"
>> put "#" & i into a[i] --> a["5.0"] = "#5.0"
>>
>> If you want just the regular strings formatted and not any array keys,
>> or vice versa, use the appropriate part:
>>
>> set numberformat["text"] to "0.0"
>> put "#" & i into a[i] --> a["5"] = "#5.0"
>>
>> (or)
>>
>> set numberformat["keys"] to "0.0"
>> put "#" & i into a[i] --> a["5.0"] = "#5"
>>
>
> This is certainly an idea - however, I wonder if it isn't quite addressing
> the crux of the issue.
>
> Arrays in LiveCode serve two purposes - both lists (if integer keyed,
> dense, starting from 1) and dictionaries (all other types). The distinction
> is made purely on the string structure of the keys (for all intents and
> purposes) and what keys are present. Indeed for a LiveCode array to be
> treated as a list the keys *must* be very strictly formatted as integers -
> there must be no fractional part (i.e. "1.0" is *not* considered the same
> key as "1").
>
> For dictionaries, then having the numberFormat affect your numbers isn't
> really an issue - as the keys are strings, they have to be strings, there
> is no option.
>
> For lists, however, what is really happening is that they are being
> indexed by integers. So, could it be that the problem in LiveCode
> is that it doesn't distinguish between integers and non-integers?
>
> This actually alludes to another problem I've been struggling with
> recently (and, indeed, partly why this numberFormat problem is so
> interesting).
>
> At the moment LiveCode's arithmetic uses 64-bit doubles universally. This
> gives a relatively consistent arithmetic, but it has a significant limit:
> you cannot represent 64-bit integers accurately - only up to 53-bit.
> Indeed,
> the current semantics basically mean that you can do integer computations
> up
> to 53-bits and then things 'gracefully' degrade in precision. The problem
> is that I'm not sure it is feasible to extend the allowed size of integers
> (having them arbitrary precision would be really neat!) whilst preserving
> this graceful degradation to double (at least not in a performant way).
>
> One solution here is to have (internally at least) two distinct numeric
> types - integers and (inexact) reals - with the common-sense rules:
>
>integer int_op integer -> integer (+, -, *, div, mod are int_ops)
>integer op real -> real (+, -, *, /, div, mod are ops)
>real op integer -> real
>real op real -> real
>
> The question, now, is that how would we distinguish between a string
> we want to auto-convert to an integer, and a string we want to
> auto-convert to a real?
>
> One option here is to make it so that integers are always of the form
>
>   [1-9][0-9]+
>
> With a string being considered a real if it is any other valid numeric
> string:
>
>   "1" is an integer
>   "1.", "1e10", "1.03", "1.0" are all reals.
>
> If we made this distinction, then it would be viable to make it so that
> numberFormat *only* affects reals:
>
>   put 1 + 0 into tInteger
>   put 1. + 0 into tReal
>   set the numberFormat to "0.00"
>   put tInteger , tReal
> => "1,1.00"
>
> This would certainly solve the sequence-style-array 'ambiguity' and would
> perhaps make sorting out numeric literals not being touched by numberFormat
> a little more sane:
>
>   set the numberFormat to "0.00"
>   put "This is an integer: " & 1
> => This is an integer: 1
>   put "This is a real: " & 1.
> => This is a real: 1.0
>
> The problem here is that I have no idea if that distinction is too subtle
> (for LiveCode, at 

Re: Make numberFormat even better

2017-04-25 Thread Mark Waddingham via use-livecode

On 2017-04-25 09:01, Curry Kenworthy via use-livecode wrote:

To handle arrays better without requiring more lines of code, how
about making numberFormat itself an array with at least two parts?
Similar to the way the clipboardData has parts.

Using it without a key works exactly like before, by setting both 
parts, ie:


-- (assume i=binary 5 and starting format=default)

set numberformat to "0.0"
put "#" & i into a[i] --> a["5.0"] = "#5.0"

If you want just the regular strings formatted and not any array keys,
or vice versa, use the appropriate part:

set numberformat["text"] to "0.0"
put "#" & i into a[i] --> a["5"] = "#5.0"

(or)

set numberformat["keys"] to "0.0"
put "#" & i into a[i] --> a["5.0"] = "#5"


This is certainly an idea - however, I wonder if it isn't quite 
addressing

the crux of the issue.

Arrays in LiveCode serve two purposes - both lists (if integer keyed,
dense, starting from 1) and dictionaries (all other types). The 
distinction

is made purely on the string structure of the keys (for all intents and
purposes) and what keys are present. Indeed for a LiveCode array to be
treated as a list the keys *must* be very strictly formatted as integers 
-
there must be no fractional part (i.e. "1.0" is *not* considered the 
same

key as "1").

For dictionaries, then having the numberFormat affect your numbers isn't
really an issue - as the keys are strings, they have to be strings, 
there

is no option.

For lists, however, what is really happening is that they are being
indexed by integers. So, could it be that the problem in LiveCode
is that it doesn't distinguish between integers and non-integers?

This actually alludes to another problem I've been struggling with
recently (and, indeed, partly why this numberFormat problem is so
interesting).

At the moment LiveCode's arithmetic uses 64-bit doubles universally. 
This
gives a relatively consistent arithmetic, but it has a significant 
limit:
you cannot represent 64-bit integers accurately - only up to 53-bit. 
Indeed,
the current semantics basically mean that you can do integer 
computations up
to 53-bits and then things 'gracefully' degrade in precision. The 
problem
is that I'm not sure it is feasible to extend the allowed size of 
integers
(having them arbitrary precision would be really neat!) whilst 
preserving

this graceful degradation to double (at least not in a performant way).

One solution here is to have (internally at least) two distinct numeric
types - integers and (inexact) reals - with the common-sense rules:

   integer int_op integer -> integer (+, -, *, div, mod are int_ops)
   integer op real -> real (+, -, *, /, div, mod are ops)
   real op integer -> real
   real op real -> real

The question, now, is that how would we distinguish between a string
we want to auto-convert to an integer, and a string we want to
auto-convert to a real?

One option here is to make it so that integers are always of the form

  [1-9][0-9]+

With a string being considered a real if it is any other valid numeric
string:

  "1" is an integer
  "1.", "1e10", "1.03", "1.0" are all reals.

If we made this distinction, then it would be viable to make it so that
numberFormat *only* affects reals:

  put 1 + 0 into tInteger
  put 1. + 0 into tReal
  set the numberFormat to "0.00"
  put tInteger , tReal
=> "1,1.00"

This would certainly solve the sequence-style-array 'ambiguity' and 
would
perhaps make sorting out numeric literals not being touched by 
numberFormat

a little more sane:

  set the numberFormat to "0.00"
  put "This is an integer: " & 1
=> This is an integer: 1
  put "This is a real: " & 1.
=> This is a real: 1.0

The problem here is that I have no idea if that distinction is too 
subtle
(for LiveCode, at least). It is certainly something you get used to 
pretty

quickly in pretty much any other language - most (if not all!) have a
strict distinction between integer and real.

To put the potentially subtlety in context; it only arise in:

  - numeric literals

  - strings/text/files taken as inputs

In the former case, if you actually wanted a real, then you'd
just have to add a '.' to the literal (there's an advantage here is that
it completely expresses your intent as to the type of number). In the
latter case, then if you are processing string inputs:

  - For integer do:
  put tStringFromOutside + 0 -> integer if tStringFromOutside is integer
  - For real do:
  put tStringFromOutside + 0.0 -> real

The advantages of this approach are:

  1) The implementation of integers is free to be whatever it needs to
 be.

  2) It explicitly means you can indicate your numeric intent (integer
 operations and real operations have very different semantics)
 in your scripts.

  3) It potentially opens the door to a much less 'surprising' 
numberFormat

 with regards indexing arrays.

  4) It potentially opens the door to a much less 'surprising' 
numberFormat

 with regards numeric literals in scripts

The 

Make numberFormat even better

2017-04-25 Thread Curry Kenworthy via use-livecode


We've talked about this topic so much that now it almost seems a waste 
to let it go without trying to make some progress. :)


Mark:

> I'd disagree that anything involving the use of arrays could
> be considered a 'rare case' or an 'outlier case'

To handle arrays better without requiring more lines of code, how about 
making numberFormat itself an array with at least two parts? Similar to 
the way the clipboardData has parts.


Using it without a key works exactly like before, by setting both parts, ie:

-- (assume i=binary 5 and starting format=default)

set numberformat to "0.0"
put "#" & i into a[i] --> a["5.0"] = "#5.0"

If you want just the regular strings formatted and not any array keys, 
or vice versa, use the appropriate part:


set numberformat["text"] to "0.0"
put "#" & i into a[i] --> a["5"] = "#5.0"

(or)

set numberformat["keys"] to "0.0"
put "#" & i into a[i] --> a["5.0"] = "#5"

Pros: Array keys can be set independently of their contents or any other 
text, but only one "set" statement required for most situations. Fully 
backward compatible. Basic syntax is just as before, easy to learn and 
sufficing for many (most?) tasks.


Cons: A bit more complex and less English-like when using the special 
parts. It's a bit unusual to need to differentiate array keys from all 
other text.


Also: You'll notice it can be confusing if you think i=5 binary and 
expect a change, but it was actually already text. If we have to add +0 
&"" stuff it's less intuitive. But that's a separate issue to consider, 
outside this particular point.


Mark:

> I'd mind less if numberFormat was actually had wide utility -
> but, in reality, for all but the simplest of cases (wanting
> US/UK style numbers, with preceding or following '0's) it isn't
> very useful.

Doing a simple job keeps it simple, and it does that job well. However, 
it would be possible to have both the classic simplicity and more power, 
by adding more optional symbols and rules.


-- (assume i=binary )

set numberformat to "$#,##0.00"
put "Cost:" && i into x --> x = "Cost: $5,555.00"

BTW, I've worked with Excel number format a bit. Supporting it would be 
an impressive product compatibility and even benefit some of my own 
projects. However, that might be overkill for LC team and the user. (It 
has 4 parts, to start with, and a learning curve of its own for advanced 
features.)


A simpler route (based on ideas and techniques while doing SpreadLib and 
other projects) would be to retain any text prefix and suffix outside 
the # and 0 number portion of the representation, and also look for 
commas and periods within the number. Bonus: allow smart period/comma 
positions and a few other tricks. Maybe including a parenthesis anywhere 
before the number portion = negatives in parentheses.


-- (assume i=binary )

set numberformat to "#.##0,00 EUR"
put "Cost:" && i into x --> x = "Cost: 5.555,00 EUR"

-- (assume i=binary 5)

set numberformat to "$ (0.##)"
put "Cost:" && i into x --> x = "Cost: $ 5"
put "Cost:" && -i into x --> x = "Cost: $ (5)"

That should be backward compatible, except if existing code was reading 
the numberformat to analyze it for decisions or settings. Should be able 
to figure out a way around that.


(If I've proposed something that has been proposed before, sorry!)

Richard:

> there are so many precedents in other tools for defining
> display format in the object used for display that I think
> when that's what's needed it would be the simplest to learn.

That's true, very nice to have that option too!

Best wishes,

Curry Kenworthy

Custom Software Development
LiveCode Training and Consulting
http://curryk.com/consulting/

___
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