Writing Extensions

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

Writing Extensions

Sannyasin Brahmanathaswami via use-livecode
Now that we are talking about widgets and extensions, many thanks again
Mark Wieder for updating Peter Thirkell multicolor svg widget.

Just for curiosity, Could you write a blog entry about your process of
updating this widget? Maybe others would find this useful to update their
own widgets.

If you have time, Could you compile this same widget for LCB of LC 8.1.3?
I am curious to learn if deploying a widget for both LC8 and LC9 is too
difficult or just requires some simple changes.

Al
_______________________________________________
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/18/2017 07:14 PM, Alejandro Tejada via use-livecode wrote:
> Now that we are talking about widgets and extensions, many thanks again
> Mark Wieder for updating Peter Thirkell multicolor svg widget.
>
> Just for curiosity, Could you write a blog entry about your process of
> updating this widget? Maybe others would find this useful to update their
> own widgets.

I'll think about it, but I'm probably the wrong person to write up the
process of creating/modifying widgets at this point. But I'd love to see
Peter write up the process he went through. All I did was add some
flexibility to the xml parsing (which in LCB ends up working with char
offsets and is ridiculously ugly, fragile, and error-prone) and allowing
hex representations of color specifications.

>
> If you have time, Could you compile this same widget for LCB of LC 8.1.3?
> I am curious to learn if deploying a widget for both LC8 and LC9 is too
> difficult or just requires some simple changes.

Here's a link to the folder for the LC8.1.3 version - no changes to the
source required, but the Extension Builder popped up a few extraneous
windows during the process. I just canceled out of them and the widget
seems to work.

<https://www.dropbox.com/sh/gr8p7d6urk2a3st/AAA3rWHHp2VK8kBOkMINzofla?dl=0>

I had to move it out of my Extensions folder after testing it since
having both the LC8 and LC9 versions in places messes things up. This
changing binary format thing is a pain.

--
  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-19 06:23, Mark Wieder via use-livecode wrote:

> On 05/18/2017 07:14 PM, Alejandro Tejada via use-livecode wrote:
>> Now that we are talking about widgets and extensions, many thanks
>> again
>> Mark Wieder for updating Peter Thirkell multicolor svg widget.
>>
>> Just for curiosity, Could you write a blog entry about your process of
>> updating this widget? Maybe others would find this useful to update
>> their
>> own widgets.
>
> I'll think about it, but I'm probably the wrong person to write up the
> process of creating/modifying widgets at this point. But I'd love to
> see Peter write up the process he went through. All I did was add some
> flexibility to the xml parsing (which in LCB ends up working with char
> offsets and is ridiculously ugly, fragile, and error-prone) and
> allowing hex representations of color specifications.

If we are honest then parsing XML even with LCS's excellent text
chunking isn't
necessarily *that* much 'prettier'. XML is quite a complicated format if
you
want a 100% compliant reader (do we have a 100% compliant XML parser
written in LiveCode?) - hence why, in this case, it would probably be
better
to have a wrapper around a well established XML library in LCB.

Why reinvent a wheel which many other people have already decided needs
reinventing...

(Although, having said that, there is something quite pleasing about
this
kind of thing being written in the host language - pragmatically though,
we're probably better off with readers which are maintained by people
who live and breath these import formats - at least when you need the
most
generality).

> I had to move it out of my Extensions folder after testing it since
> having both the LC8 and LC9 versions in places messes things up. This
> changing binary format thing is a pain.

Point taken - it is a pain! However, it won't be like this forever - and
obviously the sooner it is stable, the better it is for the ecosystem.

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
(getting back to this thread after being without internet for several
days - it's rather an interesting experience)

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

> If we are honest then parsing XML even with LCS's excellent text
> chunking isn't
> necessarily *that* much 'prettier'. XML is quite a complicated format if
> you
> want a 100% compliant reader (do we have a 100% compliant XML parser
> written in LiveCode?) - hence why, in this case, it would probably be
> better
> to have a wrapper around a well established XML library in LCB.
>
> Why reinvent a wheel which many other people have already decided needs
> reinventing...

I'm not doing this because it's fun. I'm stuck with parsing xml data,
and it's much uglier trying to treat it as a text stream, especially
with a subset of the xtalk chunking functions, than by using the revXML
functions in LCS.

It might be useful to have a list of what xtalk features are available
in LCB, and possibly even more useful to have a list of the features
that *aren't* available in LCB. For instance, the lack of a switch
statement is both surprising and disappointing. What decisions were made
as to what language features to support / remove?

--
  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-23 17:53, Mark Wieder via use-livecode wrote:
> I'm not doing this because it's fun. I'm stuck with parsing xml data,
> and it's much uglier trying to treat it as a text stream, especially
> with a subset of the xtalk chunking functions, than by using the
> revXML functions in LCS.

Yes - so LCB could do with a module which wraps libxml...

> It might be useful to have a list of what xtalk features are available
> in LCB, and possibly even more useful to have a list of the features
> that *aren't* available in LCB. For instance, the lack of a switch
> statement is both surprising and disappointing. What decisions were
> made as to what language features to support / remove?

That is the wrong way to look at things I think - it was never a
question
of 'what should we remove or add compared to LCS'.

LCB is a language in its own right - indeed, you can write entire
applications
in LCB (and run them using the 'lc-run' tool)... Our 'vulcanbot' (the
system
which integrates our buildbot-based build system with github) is written
entirely
in LCB for example.

The design of LCB has been influenced by a number of design principals
(in no
particular order, nor exhaustive):

   a) it should have fully customizable syntax (at least 'statically' -
      i.e. at the point the compiler is built)

   b) the syntax should be familiar to LCS

   c) operations should be strict (throw an error for indexing out of
      array bounds, for example, rather than throw an error)

   d) strong dynamic typing, with the aim that if fully typed, then an
      LCB module should be completely statically checkable

   e) enable interoperation with other languages to be defined *safely*

   f) allow modularity without co-operation

   g) it should run on a VM which could be shared with LCS

   h) it should have a type-system which could subsume LCS's type-system

   i) be a natural extension language for LCS (i.e. replace C++ as the
      main implementation language for LCS features)

   j) favour abstract patterns, rather than concrete features (as one
      can implement many concrete features from one abstract pattern)

   k) it should be possible to compile a full typed LCB program to
'native'
      code (for some definition of native) with performance commensurate
      to that you would get if you wrote in said 'native' tongue

LCB is as much about trying to find the line between what we consider a
very high level language (LCS) and what we consider to be a low level
language (such as C) - blending the two together. It is influenced by
many
languages (principally LCS, admittedly) but perhaps is not quite like
any
specific one.

At the end of the day I could go on at length here (what do you know,
language design and implementation is probably my biggest computing
interest ;) ); however, I'll leave it as an 'interesting exercise for
the
reader' to consider what becomes possible if we can (at the very least)
achieve to the full extent possible principals (a), (g), (h) and (k)...

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
Another way to search individual guides is to search the markdown files on
GitHub: https://github.com/livecode/livecode/tree/develop/docs/guides and
https://github.com/livecode/livecode-ide/tree/develop/Documentation/guides.
Again, not ideal. There's an outstanding enhancement request for full-text
search of all the guides: http://quality.livecode.com/show_bug.cgi?id=15957

I've just added http://quality.livecode.com/show_bug.cgi?id=19728 for quick
search of the currently viewed guide in the IDE.

On Tue, May 23, 2017 at 6:57 PM Mark Waddingham via use-livecode <
[hidden email]> wrote:

> On 2017-05-23 17:53, Mark Wieder via use-livecode wrote:
> > I'm not doing this because it's fun. I'm stuck with parsing xml data,
> > and it's much uglier trying to treat it as a text stream, especially
> > with a subset of the xtalk chunking functions, than by using the
> > revXML functions in LCS.
>
> Yes - so LCB could do with a module which wraps libxml...
>
> > It might be useful to have a list of what xtalk features are available
> > in LCB, and possibly even more useful to have a list of the features
> > that *aren't* available in LCB. For instance, the lack of a switch
> > statement is both surprising and disappointing. What decisions were
> > made as to what language features to support / remove?
>
> That is the wrong way to look at things I think - it was never a
> question
> of 'what should we remove or add compared to LCS'.
>
> LCB is a language in its own right - indeed, you can write entire
> applications
> in LCB (and run them using the 'lc-run' tool)... Our 'vulcanbot' (the
> system
> which integrates our buildbot-based build system with github) is written
> entirely
> in LCB for example.
>
> The design of LCB has been influenced by a number of design principals
> (in no
> particular order, nor exhaustive):
>
>    a) it should have fully customizable syntax (at least 'statically' -
>       i.e. at the point the compiler is built)
>
>    b) the syntax should be familiar to LCS
>
>    c) operations should be strict (throw an error for indexing out of
>       array bounds, for example, rather than throw an error)
>
>    d) strong dynamic typing, with the aim that if fully typed, then an
>       LCB module should be completely statically checkable
>
>    e) enable interoperation with other languages to be defined *safely*
>
>    f) allow modularity without co-operation
>
>    g) it should run on a VM which could be shared with LCS
>
>    h) it should have a type-system which could subsume LCS's type-system
>
>    i) be a natural extension language for LCS (i.e. replace C++ as the
>       main implementation language for LCS features)
>
>    j) favour abstract patterns, rather than concrete features (as one
>       can implement many concrete features from one abstract pattern)
>
>    k) it should be possible to compile a full typed LCB program to
> 'native'
>       code (for some definition of native) with performance commensurate
>       to that you would get if you wrote in said 'native' tongue
>
> LCB is as much about trying to find the line between what we consider a
> very high level language (LCS) and what we consider to be a low level
> language (such as C) - blending the two together. It is influenced by
> many
> languages (principally LCS, admittedly) but perhaps is not quite like
> any
> specific one.
>
> At the end of the day I could go on at length here (what do you know,
> language design and implementation is probably my biggest computing
> interest ;) ); however, I'll leave it as an 'interesting exercise for
> the
> reader' to consider what becomes possible if we can (at the very least)
> achieve to the full extent possible principals (a), (g), (h) and (k)...
>
> 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
On 05/23/2017 11:41 AM, Ali Lloyd via use-livecode wrote:
> Another way to search individual guides is to search the markdown files on
> GitHub: https://github.com/livecode/livecode/tree/develop/docs/guides and
> https://github.com/livecode/livecode-ide/tree/develop/Documentation/guides.
> Again, not ideal. There's an outstanding enhancement request for full-text
> search of all the guides: http://quality.livecode.com/show_bug.cgi?id=15957
>
> I've just added http://quality.livecode.com/show_bug.cgi?id=19728 for quick
> search of the currently viewed guide in the IDE.

Thanks. I just added comments to both those reports.

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