D3 LiveCode Chart Examples

Sannyasin Brahmanathaswami brahma at hindu.org
Sat Mar 25 18:22:36 EDT 2017


Ditta what Trevor said.

 Our new app has both binary and livecodescript stacks.  In the beginning I was "sloppy" and named some of the script only stacks (libraries, models, behaviors) with extension only ".livecode"  in short order there is massive confusion

a)  about what can and cannot be opened in a text editor.
b) about what can be diff'ed with the git compare tools

and other "gotchas"  

"huh? How come that stack did not open? no window?  Maybe it's off screen?"

one in fact wonders why this was no enforce in the new model from the get go.

It gets worse if you try to engage collaboration and the new person on the team has not been there on the ground floor. "Hmmm, should we maybe document which of these are binary and which are livecodescript files"  

So not only for your own LC team's sanity, but for the clarity of interface between Livecode and the rest of the languages world, Ditto what Trevor said.

In fact, is there a case to be made to enforce this at the engine level?

BR
 

On 3/24/17, 1:00 PM, "use-livecode on behalf of Trevor DeVore via use-livecode" <use-livecode-bounces at lists.runrev.com on behalf of use-livecode at lists.runrev.com> wrote:

    If everyone who posts files to GitHub differentiates binary stacks from
    script only stacks using the extension then it will be helpful going
    forward. As part of the submission process you have to send a search to
    them that shows how often the language extension is used. A search that
    doesn't show binary files would need to be submitted so the search would
    filter by .livecodescript.



More information about the use-livecode mailing list