Re: Writing Extensions

[Ali Lloyd via use-livecode]

Mark, it would be lovely if you could be more specific. What parts of the
docs in particular could be improved and how? What specific sticking points
did you have?

Could you file a bug report about the extension builder? It may be that
something about error reporting has changed that hasn't been updated in the
extension builder.

On Wed, 17 May 2017 at 03:37, William Prothero via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Herman:
> Your doAsJavascript suggestion is very cool. I might use it and might
> learn some javascript in order to use it.
>
> Great idea!
> Bill
>
> > On May 16, 2017, at 4:02 PM, hh via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> >>> Alejandro T. wrote:
> >>> How fast is LCB working with imagedata?
> >
> > Slower than slowest LC Script ever seen. I Stopped
> > all my experiments with imagedata after one full day
> > (was 12 hours).
> > For a first own test simply take an image of screensize
> > and walk through the pixeldata for each byte applying
> > only the identity mapping ...
> > We have to wait until the java FFI is comfortable enough
> > to use a java image library. (I couldn't get to there).
> >
> > Would be great, if not too difficult to realise, to have
> > a "do as javascript" here (which uses the js engine only
> > of the browser widget). This is at least ten times faster
> > with imagedata than fastest LC Script. See several recent
> > examples in "Sample stacks" (and some more links in the
> > Raspi-Subforum to extern servers).
> >
> >>> Alejandro T. wrote:
> >>> How fast is LCB working with transform matrices?
> >
> > Pretty fast and comfortable for transforming all 'small'
> > canvas data (pathes, text, pattern, image-as-a-whole).
> > I liked that after taking the first hurdles.
> >
> > You may test yourself with snippets or lcb files from the
> > LCB-subforum. There is a lot of stuff for starting there.
> > Or use the examples on github by Trevor DeVore or the ones
> > by the LC-stuff, variants by BerndN.
> >
> > But I wait for my next examples until there is a stable
> > widget format (we have meanwhile three formats that work on
> > some LC versions only, not on the others).
> > To adjust these costs too much time, simply recompiling
> > worked here only in 1 of 20 cases.
> >
> >
> > ___
> > 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: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-17 09:09, Ali Lloyd via use-livecode wrote:
Mark, it would be lovely if you could be more specific. What parts of 
the
docs in particular could be improved and how? What specific sticking 
points

did you have?

Could you file a bug report about the extension builder? It may be that
something about error reporting has changed that hasn't been updated in 
the

extension builder.


Yes - LCB errors now emit with a marker and code line as to where the 
error
is... However, this requires a monospaced font to look right (it works 
really well from the terminal, for example) - so just making the log in 
field in the extension builder use such a font should fix that issue (if 
I understand Mark's issue correctly).


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

Re: Writing Extensions

[Mark Wieder via use-livecode]

On 05/17/2017 12:19 AM, Mark Waddingham via use-livecode wrote:


Yes - LCB errors now emit with a marker and code line as to where the error
is... However, this requires a monospaced font to look right (it works
really well from the terminal, for example) - so just making the log in
field in the extension builder use such a font should fix that issue (if
I understand Mark's issue correctly).

Warmest Regards,

Mark.



Ha! Yes, It sounds like that should take care of that issue. I kept 
thinking the pointer was showing me where the error occurred (the line 
number was correct), but I kept changing the parameter it was pointing 
to and still got the same syntax error. I finally narrowed down what was 
going on with that line, and it had nothing to do with what was being 
pointed out to me. I'll file a bug report on this.


However, "Syntax error" as the sole error message doesn't really help 
much in telling me what I might have done wrong, especially given the 
lack of a messagebox or irb style playground to experiment with things.


--
 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: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-17 18:05, Mark Wieder via use-livecode wrote:

Ha! Yes, It sounds like that should take care of that issue. I kept
thinking the pointer was showing me where the error occurred (the line
number was correct), but I kept changing the parameter it was pointing
to and still got the same syntax error. I finally narrowed down what
was going on with that line, and it had nothing to do with what was
being pointed out to me. I'll file a bug report on this.

However, "Syntax error" as the sole error message doesn't really help
much in telling me what I might have done wrong, especially given the
lack of a messagebox or irb style playground to experiment with
things.


Yes - the syntax error message is about as good as we can make it at
the moment by virtue of the fact we use bison (in GLR mode) to generate
the parser (the spec of which is generated from the syntax 
specifications

in the LCB source files which are compiled in lc-compile) :(

LCB is more of a 'traditional' language - so compilation is completely
divorced from execution - hence no REPL loop.

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

Re: Writing Extensions

[Mark Wieder via use-livecode]

On 05/17/2017 12:09 AM, Ali Lloyd via use-livecode wrote:

Mark, it would be lovely if you could be more specific. What parts of the
docs in particular could be improved and how? What specific sticking points
did you have?


Oh, where to start? Here are some thoughts off the top of my head:

Well, I'd love to have more parity between LCS and LCB as far as 
keywords and syntax, but I guess that's outside the scope of the 
documentation per se. But finding that constants like comma and quote 
aren't defined in LCB was a shock. Indeed, even defining a constant 
doesn't seem possible. Or at least it's not documented. Searching for 
"constant" gives nothing, even though "PiConstant" is in the dictionary.


I have no idea what the dictionary for ScriptObject is telling me. It 
has a link to MyScriptObject which has no useful information other than 
referring me back to ScripObject. The description "Use the resolve 
script object, or my script object to obtain an object of type 
ScriptObject" is self-referential at best. The Summary is better "an 
opaque type..." yep - it's opaque all right.


The dictionary entries for LCB commands are arcane CamelCase words 
seemingly drawn from thin air. CanvasOperationDrawImage, for example, 
has the syntax of "draw [ from mSrcRect of ] mImage into mDestRect of 
mCanvas". The syntax statement is understandable, but the entry should 
be "draw", not "CanvasOperationDrawImage".


Similarly, searching for "format" brings up "BooleanFormattedAsString", 
"FormatBooleanAsString", "FormatNumberAsString", and 
"NumberFormattedAsString". These refer to either the "format" command or 
the "formatted as string" modifier. The description field "Use 
NumberFormattedAsString when you want to manipulate a numeric value as 
text" doesn't reference the proper syntax for the modifier per the example.


And nothing in the "format" commands that came up in the search helped 
me figure out how to format a hex number as decimal, which is what I was 
looking for based on LCS expectations. There's no "see also" section 
which might have pointed me to the "convert" commands. The description 
of Operand as "An expression that evaluates to a number" isn't specific 
enough to help... is "FE" a number even though it's a hex number? Is 
"0xFE" a number"? Does a number have to be an integer (digging into 
StringPasedAsNumber would indicate no, but why is it necessary to do the 
digging)? Is 0123.50 a number? What's it's string value? Does it have 
the leading zero? The trailing zero? Can I control the output format?


Once I finally tried searching for convert (mind you, I don't want to 
*convert* the number, just display it differently) I was faced with a 
similar situation: "BaseConvert" (the syntax of which is actually 
"Operand converted from base Source to base Target"), "BaseConvertFrom" 
(with a syntax of "Operand converted from base Source", "BaseConvertTo" 
(syntax of "operand converted to base Target", and a reference to the 
com.livecode.typeconvert library.


So looking at BaseConvert, the Operand is specified as "An expression 
that evaluates to a string." Fair enough - I give it a hex number and I 
expect a decimal number out the back end. What's the format for a hex 
number? Is it "0xHH"? Just "HH"? Something else? Can I specify a leading 
zero? Number of expected decimal digits (what if I need three digits 
even if one or two are leading zeros?) These are easy in LCS, not so 
much in LCB.


Is it even possible to set the various delimiters? The documentation 
only talks about retrieving them. The description talks about the 
calling (script) handler's Delimiter property... is this an actual 
property of the object or is just a shorthand way of talking about "the 
Delimiter"?


I clicked on "type" in the Filters section. What does that do? All it 
seems to do is narrow my choices down to ScriptObject (see above).


The pointer type isn't documented.

Why is the "point" operator documented as "PointMake"? Is this just to 
differentiate between the "point" creator keyword and the "point" object 
keyword?


Some major strengths of LCS are missing in LCB, or at least don't appear 
to be in the documentation. Chunks, for instance. It's possible to get 
character chunks (and the [first|last] modifier in the offset functions 
are *very* nice), but there's no conception of words. This results in 
some ugly, convoluted, and error-prone coding to deal with things that 
are not only easy in LCS, but IMNSHO one of the things that makes 
LiveCode such a productive environment. I'm hoping this is just a 
documentation failure and not a missing feature.


The StringToJString and StringFromJString examples handler use the 
"foreign handler" construct, but "foreign" isn't in the dictionary. Nor 
is the "binds to" syntax. Nor the JObject or JString objects. Nor the 
"unsafe" keyword.


--
 Mark Wieder
 ahsoftw...@gmail.com


___
use-livecode mailing list
use-livecod

Re: Writing Extensions

[Richmond Mathewson via use-livecode]

Why do I feel that the reason for all this "wierdness" is because LCB 
has been written from C++ programmers from the ground up,
while LiveCode still (well, just about) hangs onto to its HyperCard 
heritage.


LiveCode, at its best, preserves the clarity that was the best thing 
about HyperCard (certainly mind-blowingly refreshing
after my baptism with FORTRAN and PASCAL); LCB, not doing that, is as 
opaque as its heritage.


It has been suggested before that the LiveCode team have, maybe 
unwittingly, started moving away from the
HyperCard-like simplicity that was what made LiveCode so obviously the 
best successor to HyperCard; with LCB they

don't even have to pay lip service to that . . .

I am extremely grateful to you, Mark, that you were the one who took the 
first critical plunge . . .


Richmond.

On 5/17/17 10:27 pm, Mark Wieder via use-livecode wrote:

On 05/17/2017 12:09 AM, Ali Lloyd via use-livecode wrote:
Mark, it would be lovely if you could be more specific. What parts of 
the
docs in particular could be improved and how? What specific sticking 
points

did you have?


Oh, where to start? Here are some thoughts off the top of my head:

Well, I'd love to have more parity between LCS and LCB as far as 
keywords and syntax, but I guess that's outside the scope of the 
documentation per se. But finding that constants like comma and quote 
aren't defined in LCB was a shock. Indeed, even defining a constant 
doesn't seem possible. Or at least it's not documented. Searching for 
"constant" gives nothing, even though "PiConstant" is in the dictionary.


I have no idea what the dictionary for ScriptObject is telling me. It 
has a link to MyScriptObject which has no useful information other 
than referring me back to ScripObject. The description "Use the 
resolve script object, or my script object to obtain an object of type 
ScriptObject" is self-referential at best. The Summary is better "an 
opaque type..." yep - it's opaque all right.


The dictionary entries for LCB commands are arcane CamelCase words 
seemingly drawn from thin air. CanvasOperationDrawImage, for example, 
has the syntax of "draw [ from mSrcRect of ] mImage into mDestRect of 
mCanvas". The syntax statement is understandable, but the entry should 
be "draw", not "CanvasOperationDrawImage".


Similarly, searching for "format" brings up 
"BooleanFormattedAsString", "FormatBooleanAsString", 
"FormatNumberAsString", and "NumberFormattedAsString". These refer to 
either the "format" command or the "formatted as string" modifier. The 
description field "Use NumberFormattedAsString when you want to 
manipulate a numeric value as text" doesn't reference the proper 
syntax for the modifier per the example.


And nothing in the "format" commands that came up in the search helped 
me figure out how to format a hex number as decimal, which is what I 
was looking for based on LCS expectations. There's no "see also" 
section which might have pointed me to the "convert" commands. The 
description of Operand as "An expression that evaluates to a number" 
isn't specific enough to help... is "FE" a number even though it's a 
hex number? Is "0xFE" a number"? Does a number have to be an integer 
(digging into StringPasedAsNumber would indicate no, but why is it 
necessary to do the digging)? Is 0123.50 a number? What's it's string 
value? Does it have the leading zero? The trailing zero? Can I control 
the output format?


Once I finally tried searching for convert (mind you, I don't want to 
*convert* the number, just display it differently) I was faced with a 
similar situation: "BaseConvert" (the syntax of which is actually 
"Operand converted from base Source to base Target"), 
"BaseConvertFrom" (with a syntax of "Operand converted from base 
Source", "BaseConvertTo" (syntax of "operand converted to base 
Target", and a reference to the com.livecode.typeconvert library.


So looking at BaseConvert, the Operand is specified as "An expression 
that evaluates to a string." Fair enough - I give it a hex number and 
I expect a decimal number out the back end. What's the format for a 
hex number? Is it "0xHH"? Just "HH"? Something else? Can I specify a 
leading zero? Number of expected decimal digits (what if I need three 
digits even if one or two are leading zeros?) These are easy in LCS, 
not so much in LCB.


Is it even possible to set the various delimiters? The documentation 
only talks about retrieving them. The description talks about the 
calling (script) handler's Delimiter property... is this an 
actual property of the object or is just a shorthand way of talking 
about "the Delimiter"?


I clicked on "type" in the Filters section. What does that do? All it 
seems to do is narrow my choices down to ScriptObject (see above).


The pointer type isn't documented.

Why is the "point" operator documented as "PointMake"? Is this just to 
differentiate between the "point" creator keyword and the "point" 
object keyword?


Some major strengths of L

Re: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-17 21:34, Richmond Mathewson via use-livecode wrote:

Why do I feel that the reason for all this "wierdness" is because LCB
has been written from C++ programmers from the ground up,
while LiveCode still (well, just about) hangs onto to its HyperCard 
heritage.


LiveCode, at its best, preserves the clarity that was the best thing
about HyperCard (certainly mind-blowingly refreshing
after my baptism with FORTRAN and PASCAL); LCB, not doing that, is as
opaque as its heritage.

It has been suggested before that the LiveCode team have, maybe
unwittingly, started moving away from the
HyperCard-like simplicity that was what made LiveCode so obviously the
best successor to HyperCard; with LCB they
don't even have to pay lip service to that . . .


I think this perhaps displays a misunderstanding what LCB is for - it 
isn't a replacement for LiveCode Script; it is intended to be a stepping 
stone between C++ and LiveCode Script which means it can be used to 
extend the engine in way which LiveCode Script cannot. i.e. Allowing 
functionality to be added to LiveCode *without* having to deal with C++ 
and, instead, deal with something slightly more familiar (also there is 
a lot of boiler-plate required in writing engine functionality in C++, 
which LCB eliminates by raising the abstraction level of values).


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

Re: Writing Extensions

[Ali Lloyd via use-livecode]

LCB as a language is marginally (if at all) more complex than LiveCode. In
fact many lines of code are indistinguishable between the two.

The difficulty Mark was having is more related to the fact that LCB is not
'live' like LiveCode Script, and that we certainly haven't quite cracked
the documentation or the integration with the IDE yet.

On Wed, May 17, 2017 at 8:34 PM Richmond Mathewson via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Why do I feel that the reason for all this "wierdness" is because LCB
> has been written from C++ programmers from the ground up,
> while LiveCode still (well, just about) hangs onto to its HyperCard
> heritage.
>
> LiveCode, at its best, preserves the clarity that was the best thing
> about HyperCard (certainly mind-blowingly refreshing
> after my baptism with FORTRAN and PASCAL); LCB, not doing that, is as
> opaque as its heritage.
>
> It has been suggested before that the LiveCode team have, maybe
> unwittingly, started moving away from the
> HyperCard-like simplicity that was what made LiveCode so obviously the
> best successor to HyperCard; with LCB they
> don't even have to pay lip service to that . . .
>
> I am extremely grateful to you, Mark, that you were the one who took the
> first critical plunge . . .
>
> Richmond.
>
> On 5/17/17 10:27 pm, Mark Wieder via use-livecode wrote:
> > On 05/17/2017 12:09 AM, Ali Lloyd via use-livecode wrote:
> >> Mark, it would be lovely if you could be more specific. What parts of
> >> the
> >> docs in particular could be improved and how? What specific sticking
> >> points
> >> did you have?
> >
> > Oh, where to start? Here are some thoughts off the top of my head:
> >
> > Well, I'd love to have more parity between LCS and LCB as far as
> > keywords and syntax, but I guess that's outside the scope of the
> > documentation per se. But finding that constants like comma and quote
> > aren't defined in LCB was a shock. Indeed, even defining a constant
> > doesn't seem possible. Or at least it's not documented. Searching for
> > "constant" gives nothing, even though "PiConstant" is in the dictionary.
> >
> > I have no idea what the dictionary for ScriptObject is telling me. It
> > has a link to MyScriptObject which has no useful information other
> > than referring me back to ScripObject. The description "Use the
> > resolve script object, or my script object to obtain an object of type
> > ScriptObject" is self-referential at best. The Summary is better "an
> > opaque type..." yep - it's opaque all right.
> >
> > The dictionary entries for LCB commands are arcane CamelCase words
> > seemingly drawn from thin air. CanvasOperationDrawImage, for example,
> > has the syntax of "draw [ from mSrcRect of ] mImage into mDestRect of
> > mCanvas". The syntax statement is understandable, but the entry should
> > be "draw", not "CanvasOperationDrawImage".
> >
> > Similarly, searching for "format" brings up
> > "BooleanFormattedAsString", "FormatBooleanAsString",
> > "FormatNumberAsString", and "NumberFormattedAsString". These refer to
> > either the "format" command or the "formatted as string" modifier. The
> > description field "Use NumberFormattedAsString when you want to
> > manipulate a numeric value as text" doesn't reference the proper
> > syntax for the modifier per the example.
> >
> > And nothing in the "format" commands that came up in the search helped
> > me figure out how to format a hex number as decimal, which is what I
> > was looking for based on LCS expectations. There's no "see also"
> > section which might have pointed me to the "convert" commands. The
> > description of Operand as "An expression that evaluates to a number"
> > isn't specific enough to help... is "FE" a number even though it's a
> > hex number? Is "0xFE" a number"? Does a number have to be an integer
> > (digging into StringPasedAsNumber would indicate no, but why is it
> > necessary to do the digging)? Is 0123.50 a number? What's it's string
> > value? Does it have the leading zero? The trailing zero? Can I control
> > the output format?
> >
> > Once I finally tried searching for convert (mind you, I don't want to
> > *convert* the number, just display it differently) I was faced with a
> > similar situation: "BaseConvert" (the syntax of which is actually
> > "Operand converted from base Source to base Target"),
> > "BaseConvertFrom" (with a syntax of "Operand converted from base
> > Source", "BaseConvertTo" (syntax of "operand converted to base
> > Target", and a reference to the com.livecode.typeconvert library.
> >
> > So looking at BaseConvert, the Operand is specified as "An expression
> > that evaluates to a string." Fair enough - I give it a hex number and
> > I expect a decimal number out the back end. What's the format for a
> > hex number? Is it "0xHH"? Just "HH"? Something else? Can I specify a
> > leading zero? Number of expected decimal digits (what if I need three
> > digits even if one or two are leading zeros?) These are easy in L

English Like?

[William Prothero via use-livecode]

Folks:
It can be difficult for long term users of an application to appreciate the 
“exceptions” to the philosophy of a dev app. I think the livecode community is 
affected by “familiarity” over clarity sometimes. For years (when Director was 
a viable dev platform), I had a negative feeling about Hypercard type syntax. I 
had done some pretty extensive programming in Hypercard and Supercard too. I 
liked the way Director worked. I liked that it did not insult my intelligence 
by requiring “put 3 into x” instead of the universal "x=3” syntax that all 
algebra students lewarn in gradeschool, When Director died, I looked around, 
held my nose, and jumped to livecode, and now I’m glad I jumped that initial 
negative barrier. But, I take exception to the many claims that livecode is 
“english-like” (in spite of the many “english-like” commands), especially if 
you want to do the advanced work that most of the users do.

For example, suppose I want to do the very basic task of coding a conditional 
that test for the name of a card. What I would intuitively expect is:

put the name of this cd into cdName

What I get for cdName is:  Suppose the name of the cd is theName
card “theName”

Ok, now I only want the name, so I do

if word 2 of the name of this cd is “theName” then
  —do my stuff
end if

No, I don’t get that. First, I need to do:

put word 2 of cdName into cdName
replace quote with “” in cdName
if word 2 of the name of this cd is “theName” then
  —do my stuff, this works
end if

I don’t call this intuitive.  I just spent more time than I should have sorting 
this out. 

So, how should a company supporting a platform deal with this? Macromedia chose 
a really nice strategy when they added dot syntax, which its users wanted. What 
they did was implement a flag named “useLegacyCode”  (or something like that). 
This way the legacy users could just set that flag and couldn’t complain about 
their apps breaking, and the new apps could be built on a more refined code 
base.

This could be a strategy for the LiveCode mothership to implement when it 
becomes desirable to implement new, improved, and different code syntax that 
may conflict with legacy syntax. There are other non-intuitive oddities like 
the example I gave above. If livecode wants to embody “english-like” syntax, 
there could be numerous improvements to help the newby. Conversely, perhaps 
another language entirely might compile to the same tokens as the current 
version, but that’s a job for another huge effort.

Just sayin'…..

Regards,
Bill P,

William A. Prothero
http://earthlearningsolution.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: English Like?

[Marc Siskin via use-livecode]

Bill,

The solution to your issue is to use the short name version of name.

Marc

On May 17, 2017, at 1:41 PM, William Prothero via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Folks:
It can be difficult for long term users of an application to appreciate the 
“exceptions” to the philosophy of a dev app. I think the livecode community is 
affected by “familiarity” over clarity sometimes. For years (when Director was 
a viable dev platform), I had a negative feeling about Hypercard type syntax. I 
had done some pretty extensive programming in Hypercard and Supercard too. I 
liked the way Director worked. I liked that it did not insult my intelligence 
by requiring “put 3 into x” instead of the universal "x=3” syntax that all 
algebra students lewarn in gradeschool, When Director died, I looked around, 
held my nose, and jumped to livecode, and now I’m glad I jumped that initial 
negative barrier. But, I take exception to the many claims that livecode is 
“english-like” (in spite of the many “english-like” commands), especially if 
you want to do the advanced work that most of the users do.

For example, suppose I want to do the very basic task of coding a conditional 
that test for the name of a card. What I would intuitively expect is:

put the name of this cd into cdName

What I get for cdName is:  Suppose the name of the cd is theName
card “theName”

Ok, now I only want the name, so I do

if word 2 of the name of this cd is “theName” then
 —do my stuff
end if

No, I don’t get that. First, I need to do:

put word 2 of cdName into cdName
replace quote with “” in cdName
if word 2 of the name of this cd is “theName” then
 —do my stuff, this works
end if

I don’t call this intuitive.  I just spent more time than I should have sorting 
this out.

So, how should a company supporting a platform deal with this? Macromedia chose 
a really nice strategy when they added dot syntax, which its users wanted. What 
they did was implement a flag named “useLegacyCode”  (or something like that). 
This way the legacy users could just set that flag and couldn’t complain about 
their apps breaking, and the new apps could be built on a more refined code 
base.

This could be a strategy for the LiveCode mothership to implement when it 
becomes desirable to implement new, improved, and different code syntax that 
may conflict with legacy syntax. There are other non-intuitive oddities like 
the example I gave above. If livecode wants to embody “english-like” syntax, 
there could be numerous improvements to help the newby. Conversely, perhaps 
another language entirely might compile to the same tokens as the current 
version, but that’s a job for another huge effort.

Just sayin'…..

Regards,
Bill P,

William A. Prothero
http://earthlearningsolution.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

---
Marc Siskin
Manager, Modern Language Resource Center
Carnegie Mellon University
msis...@andrew.cmu.edu



___
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: English Like?

[Richard Gaskin via use-livecode]

William Prothero wrote:

> When Director died, I looked around, held my nose, and jumped to
> livecode, and now I’m glad I jumped that initial negative barrier.
> But, I take exception to the many claims that livecode is
> “english-like” (in spite of the many “english-like” commands),
> especially if you want to do the advanced work that most of the users
> do.

The team seems to share the same feeling; you'll find most references to 
"English-like" are historical.


LiveCode is readable, almost to the point of being self-documenting, and 
generally quite learnable,


But no language designed for communicating with a machine benefits much 
from from attempting to follow Chomsky rules for natural/accidental 
languages we use when communicating with humans; very different 
cognitive abilities in the listener, very different usage goals, leading 
to very different design patterns.


Your specific question is an interesting one in terms of syntax consistency:

> For example, suppose I want to do the very basic task of coding a
> conditional that test for the name of a card. What I would intuitively
> expect is:
>
> put the name of this cd into cdName
>
> What I get for cdName is:  Suppose the name of the cd is theName
> card “theName”
>
> Ok, now I only want the name, so I do
>
> if word 2 of the name of this cd is “theName” then
>   —do my stuff
> end if
>
> No, I don’t get that. First, I need to do:
>
> put word 2 of cdName into cdName
> replace quote with “” in cdName
> if word 2 of the name of this cd is “theName” then
>   —do my stuff, this works
> end if
>
> I don’t call this intuitive.  I just spent more time than I should
> have sorting this out.

I'm afraid you'll have to blame the authors of the mother tongue, 
HyperTalk, on that one.


Your expectations a perfectly reasonable:  with most properties we ask 
for a value and we get that value, without also getting some other 
metadata like object type.


Imagine if:

  put the rect of button 1

...returned:

  rectangle "20,20,120,44"

That would be annoying as hell.  And yet with object names that's pretty 
much what happens, where we have to add more (an extra keyword) to get less:


  put the name of button 1

...yields:

  button "Bob"

But:

  put the short name of button 1

...yields:

  Bob

Fortunately most properties work as expected, and the anomalous behavior 
of the name property (and only a few others) are easily learned and 
quite useful.


But posts like yours are VERY helpful for those of us who teach 
newcomers.  When we've learned these things too long ago it's easy to 
forget they were ever unintuitive at first, which may miss opportunities 
for more effective on-boarding.


--
 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: Writing Extensions

[JB via use-livecode]

It looks to me like a the easier stepping
stone to fill the gap is just write the code
in C/C++, compile it and call it using a
shell coimmand.

I have been doing it in C and it works
really good.  I am amazed at how easy
it is.  If you can get the C code I posted
to print out the argument you will have
the knowledge to use tons of c code
examples with only a few changes and
many as they are.

JB


> On May 17, 2017, at 12:59 PM, Mark Waddingham via use-livecode 
>  wrote:
> 
> On 2017-05-17 21:34, Richmond Mathewson via use-livecode wrote:
>> Why do I feel that the reason for all this "wierdness" is because LCB
>> has been written from C++ programmers from the ground up,
>> while LiveCode still (well, just about) hangs onto to its HyperCard heritage.
>> LiveCode, at its best, preserves the clarity that was the best thing
>> about HyperCard (certainly mind-blowingly refreshing
>> after my baptism with FORTRAN and PASCAL); LCB, not doing that, is as
>> opaque as its heritage.
>> It has been suggested before that the LiveCode team have, maybe
>> unwittingly, started moving away from the
>> HyperCard-like simplicity that was what made LiveCode so obviously the
>> best successor to HyperCard; with LCB they
>> don't even have to pay lip service to that . . .
> 
> I think this perhaps displays a misunderstanding what LCB is for - it isn't a 
> replacement for LiveCode Script; it is intended to be a stepping stone 
> between C++ and LiveCode Script which means it can be used to extend the 
> engine in way which LiveCode Script cannot. i.e. Allowing functionality to be 
> added to LiveCode *without* having to deal with C++ and, instead, deal with 
> something slightly more familiar (also there is a lot of boiler-plate 
> required in writing engine functionality in C++, which LCB eliminates by 
> raising the abstraction level of values).
> 
> 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
> 


___
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: Writing Extensions

[Mark Wieder via use-livecode]

On 05/17/2017 01:10 PM, Ali Lloyd via use-livecode wrote:

LCB as a language is marginally (if at all) more complex than LiveCode. In
fact many lines of code are indistinguishable between the two.


Yes. In fact it's the areas where they differ that make for a difficult 
learning curve. There are features in LCB that I wish were backported to 
LCS. I appreciate the team's reticence to make syntax changes to the 
core xtalk language, but even as a long-time C programmer,


put tHexNumber converted from base 16 into tDecimalNumber

seems so much more readable than

put format("%02x", tHexNumber) into tDecimalNumber


The difficulty Mark was having is more related to the fact that LCB is not
'live' like LiveCode Script, and that we certainly haven't quite cracked
the documentation or the integration with the IDE yet.


Yes on all counts.

--
 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: Writing Extensions

[Mark Wieder via use-livecode]

On 05/17/2017 02:30 PM, JB via use-livecode wrote:

It looks to me like a the easier stepping
stone to fill the gap is just write the code
in C/C++, compile it and call it using a
shell coimmand.


Is that working for you in Android apps?

--
 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: Writing Extensions

[JB via use-livecode]

This may sound crazy but I do not have
any mobile phones.  I have a really old
iPad that won’t run the newer os.  I think
androids are written in Java and I have
used Java.  I have read C can be ported
to Java but that is all I know.

JB


> On May 17, 2017, at 2:49 PM, Mark Wieder via use-livecode 
>  wrote:
> 
> On 05/17/2017 02:30 PM, JB via use-livecode wrote:
>> It looks to me like a the easier stepping
>> stone to fill the gap is just write the code
>> in C/C++, compile it and call it using a
>> shell coimmand.
> 
> Is that working for you in Android apps?
> 
> -- 
> 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
> 


___
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

Android policy update

[J. Landman Gay via use-livecode]

I just got a developer email about a revision to Google's policies for 
apps on Google Play. Google will not allow apps that download executable 
code, similar to Apple's policy. It sounds like that includes stack 
content downloaded via a "launcher" app.


https://play.google.com/about/privacy-security/malicious-behavior/

--
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: Android policy update

[Richard Gaskin via use-livecode]

J. Landman Gay wrote:

I just got a developer email about a revision to Google's policies for 
apps on Google Play. Google will not allow apps that download executable 
code, similar to Apple's policy. It sounds like that includes stack 
content downloaded via a "launcher" app.


https://play.google.com/about/privacy-security/malicious-behavior/


Good to know - thanks.

There *might* be some wiggle room here:

  This restriction does not apply to code that runs in a virtual
  machine and has limited access to Android APIs (such as JavaScript
  in a webview or browser).

Whether or not Google would agree that LC is a sort of "VM" is anyone's 
guess, but LC Script is limited to LC's APIs and scripts can't extend an 
app's permissions beyond what the user has already allowed for the app.


I wouldn't bet the farm on their interpretation, but I know some 
developers using a wide range of scripting languages that have been 
deploying with data+script download updates for years, even on iOS.  I'm 
not recommending it, just noting that apparently within the confines of 
the LC VM such things are either not obviously noticeable or not a 
concern for the reviewer.


Of course any app that violates any of the other policies outlined on 
that page will be dumped ASAP, regardless of how they handle updates. 
So folks, don't write jerk apps and let's keep things safe and 
user-friendly.


--
 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: Android policy update

[Mark Waddingham via use-livecode]

On 2017-05-18 00:25, J. Landman Gay via use-livecode wrote:

I just got a developer email about a revision to Google's policies for
apps on Google Play. Google will not allow apps that download
executable code, similar to Apple's policy. It sounds like that
includes stack content downloaded via a "launcher" app.

https://play.google.com/about/privacy-security/malicious-behavior/


I would agree with Richard's analysis - albeit with one caveat discussed 
later on.


Is it just me or is the wording of that page is atrocious? I hope there 
is a more detailed normative document in which these restrictions are 
placed (like the Apple SDK/Store Agreement). After all in the 
(presumably non-normative preamble) it says:


"An app distributed via Google Play may not modify, replace, or update 
itself using any method other than Google Play’s update mechanism. 
Likewise, an app may not download executable code (e.g. dex, JAR, .so 
files) from a source other than Google Play. This restriction does not 
apply to code that runs in a virtual machine and has limited access to 
Android APIs (such as JavaScript in a webview or browser)."


Then in what appears to be the normative section, it says:

"The following are explicitly prohibited:
  - Apps or SDKs that download executable code, such as dex files or 
native code, from a source other than Google Play."


This is somewhat contradictory without an explicit definition of what 
they mean by 'executable code'. However, reading between the lines I 
would infer that what they mean is this:


"It is explicitly prohibited to allow an app to download code from 
outside of Google Play which is able to call more Android APIs than the 
host app was originally able to do."


Anyway, reading between the lines, the reasoning behind this is simple - 
google can check all dex, JAR and .SO files which flow through Google 
Play for malicious code. They cannot check any code which is downloaded 
outside of Google Play - so if code is downloaded outside of Google Play 
then it must not create any more 'routes in' to the OS in order to 
trigger vulnerabilities and the only 'routes in' to the OS are Android 
API calls, whether they be Java or C.


Anyway, I think you are fine as right now the range of APIs which the 
Android engine uses is fixed at the point of building an Android 
standalone and we are definitely a VM (LiveCode Script runs using an 
Abstract Syntax Tree, LiveCode Builder a ByteCode Machine) - thus we can 
be considered 'JavaScript in a WebView'-like.


Okay so the caveat. I really want the above paragraph to be true, 
however it actually isn't if one casts a critical eye over the whole 
system...


We potentially have an issue with LiveCode Builder... Well, not LiveCode 
Builder, but its FFI capabilities.


It's very presence and the way it works means that in actual fact, we 
cannot say that 'code that runs in a virtual machine has limited access 
to Android APIs' - even the existing C FFI mechanism allows you to hook 
up to arbitrary C APIs; the upcoming Java FFI mechanism makes this even 
easier (as connecting to Java APIs is a fair bit easily than C - from 
the point of view of the developer, at least).


Indeed, LCB modules are loadable at runtime, so you could download an 
LCB module which hooks into APIs the existing app does not; and then 
call them. Further than that, it is possible to write an LCB module 
which allows arbitrary machine code to be executed directly.


This will require some thought - I'd rather LiveCode didn't get 
blacklisted from being considered a 'JavaScript running in a 
WebView'-like language.


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