Writing Extensions

classic Classic list List threaded Threaded
73 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Writing Extensions

Sannyasin Brahmanathaswami via use-livecode
Having spent a bit of the day experimenting with LCB, I have this to say:

the documentation is atrocious

...also, the only thing I have to say about error reporting in the
Extension Builder is that it lets you know there's an error. There's a
caret displayed under the error line that misleadingly appears to point
to the problem, when actually it's just pointing to the middle of the
line. And "Syntax error" isn't a very rewarding message.

It took me three hours today to figure out how to convert a hex number
into decimal format.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Writing Extensions

Sannyasin Brahmanathaswami via use-livecode
yep.  it's not fun, yet.

On Tue, May 16, 2017 at 4:48 PM, Mark Wieder via use-livecode <
[hidden email]> wrote:

> Having spent a bit of the day experimenting with LCB, I have this to say:
>
> the documentation is atrocious
>
> ...also, the only thing I have to say about error reporting in the
> Extension Builder is that it lets you know there's an error. There's a
> caret displayed under the error line that misleadingly appears to point to
> the problem, when actually it's just pointing to the middle of the line.
> And "Syntax error" isn't a very rewarding message.
>
> It took me three hours today to figure out how to convert a hex number
> into decimal format.
>
> --
>  Mark Wieder
>  [hidden email]
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Writing Extensions

Sannyasin Brahmanathaswami via use-livecode
In reply to this post by Sannyasin Brahmanathaswami via use-livecode
On Tue, May 16, 2017 at 1:48 PM, Mark Wieder via use-livecode <
[hidden email]> wrote:

> It took me three hours today to figure out how to convert a hex number
> into decimal format.


Why?  Because the IP is IPV6 ? Large hex number that overflows?

--
Stephen Barncard - Sebastopol Ca. USA -
mixstream.org
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Writing Extensions

Sannyasin Brahmanathaswami via use-livecode
In reply to this post by Sannyasin Brahmanathaswami via use-livecode
Thanks for this post. I was already thinking it is just me who struggles with LCB.
I tried a bit, gave up and decided to wait for the announced course.

Matthias

Matthias Rebbe
+49 5741 310000
‌matthiasrebbe.eu <http://matthiasrebbe.eu/>‌

> Am 16.05.2017 um 22:48 schrieb Mark Wieder via use-livecode <[hidden email] <mailto:[hidden email]>>:
>
> Having spent a bit of the day experimenting with LCB, I have this to say:
>
> the documentation is atrocious
>
> ...also, the only thing I have to say about error reporting in the Extension Builder is that it lets you know there's an error. There's a caret displayed under the error line that misleadingly appears to point to the problem, when actually it's just pointing to the middle of the line. And "Syntax error" isn't a very rewarding message.
>
> It took me three hours today to figure out how to convert a hex number into decimal format.
>
> --
> Mark Wieder
> [hidden email] <mailto:[hidden email]>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email] <mailto:[hidden email]>
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Writing Extensions

Sannyasin Brahmanathaswami via use-livecode
In reply to this post by Sannyasin Brahmanathaswami via use-livecode
On 05/16/2017 02:47 PM, Stephen Barncard via use-livecode wrote:
> On Tue, May 16, 2017 at 1:48 PM, Mark Wieder via use-livecode <
> [hidden email]> wrote:
>
>> It took me three hours today to figure out how to convert a hex number
>> into decimal format.
>
>
> Why?  Because the IP is IPV6 ? Large hex number that overflows?

Nope. Because the way I would do this in LCS doesn't exist in LCB. The
LCB syntax is actually more intuitive, but getting to that point took
all morning. Having to read between the lines in the dictionary and make
guesses (educated and non) about the keywords and syntax.

I wasn't dealing with IP addresses, just converting #NNNNNN colors to
(DDD,DDD,DDD) format, two hex digits at a time. Along the way I
discovered interesting things like the fact that 'comma' isn't a defined
constant in LCB. And that there's no concept of word chunks in LCB.

And there's afaict no messagebox-style way to interactively try out the
possible syntax forms - you just have to write the code, try to compile
it, and then try to figure out why there's a syntax error.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Writing Extensions

Sannyasin Brahmanathaswami via use-livecode
In reply to this post by Sannyasin Brahmanathaswami via use-livecode
>> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Writing Extensions

Sannyasin Brahmanathaswami via use-livecode
In reply to this post by Sannyasin Brahmanathaswami via use-livecode
This is why the LiveCode Infinity project had such attraction to me.

There were to be fully documented examples.

Oh well.

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Writing Extensions

Sannyasin Brahmanathaswami via use-livecode
In reply to this post by Sannyasin Brahmanathaswami via use-livecode
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 <[hidden email]> 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
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Writing Extensions

Sannyasin Brahmanathaswami 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 <
[hidden email]> 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 <
> [hidden email]> 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
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Writing Extensions

Sannyasin Brahmanathaswami 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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Writing Extensions

Sannyasin Brahmanathaswami 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
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Writing Extensions

Sannyasin Brahmanathaswami 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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Writing Extensions

Sannyasin Brahmanathaswami via use-livecode
In reply to this post by Sannyasin Brahmanathaswami 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 <type>Delimiter property... is this an actual
property of the object or is just a shorthand way of talking about "the
<type>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
  [hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Writing Extensions

Sannyasin Brahmanathaswami 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 <type>Delimiter property... is this an
> actual property of the object or is just a shorthand way of talking
> about "the <type>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.
>

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Writing Extensions

Sannyasin Brahmanathaswami 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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Writing Extensions

Sannyasin Brahmanathaswami via use-livecode
In reply to this post by Sannyasin Brahmanathaswami 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 <
[hidden email]> 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 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 <type>Delimiter property... is this an
> > actual property of the object or is just a shorthand way of talking
> > about "the <type>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.
> >
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Writing Extensions

Sannyasin Brahmanathaswami via use-livecode
In reply to this post by Sannyasin Brahmanathaswami 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 <[hidden email]> 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 ~ [hidden email] ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Writing Extensions

Sannyasin Brahmanathaswami via use-livecode
In reply to this post by Sannyasin Brahmanathaswami 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
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Writing Extensions

Sannyasin Brahmanathaswami via use-livecode
In reply to this post by Sannyasin Brahmanathaswami 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
  [hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Writing Extensions

Sannyasin Brahmanathaswami 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 <[hidden email]> 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
> [hidden email]
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
1234