Andre Alves Garzia wrote:
> Be aware that YAML is tricky to parse, there are better formats such
> as TOML which are much easier and tend to be less error prone. It is
> very easy to get some indentation wrong in YAML and move something up
> or down a level. TOML is IMHO a better format for such
Be aware that YAML is tricky to parse, there are better formats such as
TOML which are much easier and tend to be less error prone. It is very
easy to get some indentation wrong in YAML and move something up or down
a level. TOML is IMHO a better format for such stuff.
YAML: http://yaml.org
Mark Wieder wrote:
> On 12/29/18 10:27 AM, Alex Tweedly via use-livecode wrote:
>
>> Could breakpoints also go in an LSON file ? Is there a way that a
>> script can set breakpoints into a script? (i.e. not insert eh command
>> into the script, but set a dynamic breakpoint like are stored in a
>>
On 12/29/18 10:27 AM, Alex Tweedly via use-livecode wrote:
Could breakpoints also go in an LSON file ? Is there a way that a script
can set breakpoints into a script? (i.e. not insert eh command into the
script, but set a dynamic breakpoint like are stored in a binary-stack) ?
There is
In another email on the list, Richard said something like :
> relatively easy to use a parallel LSON file and load via a library
and
On 29/12/2018 18:03, Richard Gaskin via use-livecode wrote:
Breakpoint support may well be a uniquely valuable addition worth
considering. I rarely use them
Quentin Long wrote:
>> From: Richard Gaskin
>> By what means would be indicate which properties we want saved there
>> and which ones we don't care about?
>
> To a first approximation, I'd say that any property which has been
> changed from the engine's built-in default value should be saved.
Sannyasin Brahmanathaswami wrote:
> Richard wrote:
>> Not at all my intention to hijack your thread by exploring that
>> option further to see if we can arrive at an actionable plan. On the
>> contrary, it is in direct support of pursuing solutions specific to
>> your needs.
>
> I don't mind
Bob Sneidar wrote:
>> On Dec 28, 2018, at 09:49 , Richard Gaskin wrote:
>>
>> In the beginning, script-only stacks contained only a script.
>>
>> Later, accommodation was made to allow the behavior property there,
>> using the "with behavior" clause.
>>
>> Now we're considering adding
> From: Richard Gaskin
>> J. Landman Gay wrote:
>>
>> On December 27, 2018 2:36:16 PM Richard Gaskin via use-livecode
>> wrote:
>>>
>>> Sounds like one more reason to allow stack properties as YAML
>>> frontmatter in the file. Ever since I suggested that a couple
>>> years back, the range of
Trevor wrote:
set the behavior of stack "MyStack" to the long id of stack "MyBehavior"
BR: ahha... Simple enough to do; and then it you wanted to undo the "binding",
you do it in the script editor itself.
Trevor:
" Perhaps the SE could use an update that shows the
I don't mind hijacked my thread.
It just that I see it as important innovation.
To make sure such a good idea that it was "hidden"
BR
Richard wrote:
YAML is a notation for expressing name-value pairs in a format optimized
for human writing, something we LC fans like in a language. It
I think most would agree with you on this Richard. It's like stack files are
evolving into flat files. Soon we won't need to write code, we will just think
it. It's kind of like a Star Trek episode, only for software developers. :-)
Bob S
> On Dec 28, 2018, at 09:49 , Richard Gaskin via
On Thu, Dec 27, 2018 at 10:43 PM Sannyasin Brahmanathaswami via
use-livecode wrote:
> ...
>
> BUT: " A new developer may be more likely to see the chained behavior if
> the behaviors are explicitly assigned in code vs having to use vs going to
> the IDE to look up what the behavior chain is."
J. Landman Gay wrote:
> On December 27, 2018 8:54:29 PM Richard Gaskin via use-livecode
> wrote:
>>
>> At your prompting I started to open an enhancement request for this,
>> but not long into it I hit on why they probably haven't done this
>> yet:
>>
>> By what means would be indicate which
Sannyasin Brahmanathaswami wrote:
> @ y'all about revision control of binary stacks and YAML properities
> (front matter) for text only scripts.. cool musings! but they might
> want/need different threads?
One of your team members requested extending the format of script-only
stacks
In some of my projects, I have a handler in my stack script to help with
this. It requires one extra click (to step out of th handler) - but I
often find it's worth that for the other advantages.
The minimalist version is
on mybreakpoint
breakpoint
end mybreakpoint
while the fancier
On December 27, 2018 8:54:29 PM Richard Gaskin via use-livecode
wrote:
At your prompting I started to open an enhancement request for this, but
not long into it I hit on why they probably haven't done this yet:
By what means would be indicate which properties we want saved there and
which
I see nested behaviors and all behaviors in fact, like I see constants in
relation to variables. Behaviors are or ought to be a structural thing fixed at
startup, much like constants are declared at compile time and fixed. If a set
of handlers needs to be declared, then that is what start using
That's an interesting idea!
Bob S
> On Dec 27, 2018, at 20:13 , Brian Milby via use-livecode
> wrote:
>
> I’ve briefly looked at the load/save code and think that it would be doable
> to extend the export code from just covering widgets to covering entire stack
> files. That would yield
Ha! Fixed... I have using Navigator for so long I have hardly touched the PB.
And on the big monitor the tools tip are small, be yes, they are there!
BR
On 12/28/18, 1:29 AM, "use-livecode on behalf of Niggemann, Bernd via
use-livecode" wrote:
"too obscure"... in Project Browser
Sannyasin Brahmanathaswami wrote
> BUT: " A new developer may be more likely to see the chained behavior if the
>behaviors are explicitly assigned in code vs having to use vs going to the IDE
>to look up what the behavior chain is."
>
>That is a problem using "Navigator" (does not show nested
Well, this stimulated a quite a discussion.
@Trevor: Thank you about tips on staying organized. An very good points on how
useful it could be the have nested behaviors though you have not used it yet
this was an important observation :" If you use a library script you have to
pass a
model
Part of the reason is that it is a “script only stack” and as soon as you start
adding other things it is no longer script only. If you need to store other
things, then why not just use a binary stack file? Version control... use
ScriptTracker (or some other method of script export that
J. Landman Gay wrote:
> On December 27, 2018 2:36:16 PM Richard Gaskin via use-livecode
> wrote:
>>
>> Sounds like one more reason to allow stack properties as YAML
>> frontmatter in the file. Ever since I suggested that a couple
>> years back, the range of valuable use-cases keeps growing.
>
On 12/27/18 4:13 PM, Mark Wieder via use-livecode wrote:
Especially since there's already code in the engine to handle the
"metadata" keyword for LCS.
Er... I meant, of course, LCB.
--
Mark Wieder
ahsoftw...@gmail.com
___
use-livecode mailing
On 12/27/18 3:18 PM, J. Landman Gay via use-livecode wrote:
On December 27, 2018 2:36:16 PM Richard Gaskin via use-livecode
wrote:
Sounds like one more reason to allow stack properties as YAML
frontmatter in the file. Ever since I suggested that a couple years
back, the range of valuable
On December 27, 2018 2:36:16 PM Richard Gaskin via use-livecode
wrote:
Sounds like one more reason to allow stack properties as YAML frontmatter
in the file. Ever since I suggested that a couple years back, the range of
valuable use-cases keeps growing.
I wouldn't mind if you poked them
:-)
> On Dec 27, 2018, at 14:37 , J. Landman Gay via use-livecode
> wrote:
>
> It's to keep you safe, like the TSA. And if you complain they'll make you
> debug with your shoes and belt off.
___
use-livecode mailing list
I should have guessed why you wrote that. :)
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On December 27, 2018 2:40:30 PM Andre Alves Garzia via use-livecode
wrote:
Dear Jacque,
I know too well the rabbit holes that lies deep into
It's to keep you safe, like the TSA. And if you complain they'll make you
debug with your shoes and belt off.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On December 27, 2018 3:48:41 PM Bob Sneidar via use-livecode
wrote:
Wait,
Yeah, I know breakpoints don't hurt in standalones but during active
debugging you have to keep moving them around or deleting them to avoid
unintended breaks. At least with red dots you can zap them all at once with
a menu selection.
I've had more than one brush with the law you mentioned.
Wait, they made that into a law?? Can't I even just be free to screw up
anymore??? So oppressive!
Bob S
> On Dec 27, 2018, at 13:37 , Mark Wieder via use-livecode
> wrote:
>
> That said, it's probably good practice to remove them before shipping anyway
> because of the Law of Unintended
On 12/27/18 10:21 AM, J. Landman Gay via use-livecode wrote:
I've heard you can insert hard-coded breakpoint commands in the script
instead but I haven't tried that yet. (Then you need to track them down
and remove them when they are no longer needed.)
If you don't have remote debugging
Dear Jacque,
I know too well the rabbit holes that lies deep into some LC projects.
As Richard have guessed, by using a ton of behaviors and libraries, you
can end up with code that you can't easily trace and also which becomes
quite hard to debug. As Jacque and I worked on the same project,
J. Landman Gay wrote:
> The issue is remote debugging. Script only stacks save nothing but
> scripts.
> Breakpoints are stored as custom properties which are lost when the
> stack is saved as part of a standalone, so when testing a mobile app
> they are gone and the debugger is unavailable.
Ah,
The issue is remote debugging. Script only stacks save nothing but scripts.
Breakpoints are stored as custom properties which are lost when the stack
is saved as part of a standalone, so when testing a mobile app they are
gone and the debugger is unavailable.
I've heard you can insert
What I did to make this easier is I created a Development menu in the stack
menu that I remove in standalones. Openstack builds a submenu in the
Development menu for all the behavior buttons (but they could be script only
stacks) so that I can click Development/Scripts/ to edit the
script of
Precicely why I wanted to nest datagrid behaviors. This is working really well
for me by the way. I have about 8 datagrids on what I call the Main Form, all
running the same nested behavior inserted before the default datagrid behavior.
If I need grid-specific code called from the behaviors I
Ugh. I accidentally hit send before finishing the email. Here is the
finished version.
On Wed, Dec 26, 2018 at 1:09 PM Sannyasin Brahmanathaswami via use-livecode
wrote:
>
> With that in mind, though you say "Levure doesn't have a strong opinion
> one way or the other. There is no code that is
On Wed, Dec 26, 2018 at 1:09 PM Sannyasin Brahmanathaswami via use-livecode
wrote:
>
> With that in mind, though you say "Levure doesn't have a strong opinion
> one way or the other. There is no code that is designed specifically around
> the Model-view-controller (MVC)
> pattern." I want to
On Wed, Dec 26, 2018 at 2:42 PM J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:
> Besides the impact of my current workload, I'm afraid this complexity is
> what prevented me from continuing to work on Swami's project. There are
> now
> so many disparate parts and pieces
J. Landman Gay jacque at hyperactivesw.com
> I know there is enthusiasm for script only stacks and they are really
> helpful for those who use git. But when git isn't a target, the old
> fashioned way is really much easier to follow and debug.
Being script-only is just the storage format on
Besides the impact of my current workload, I'm afraid this complexity is
what prevented me from continuing to work on Swami's project. There are now
so many disparate parts and pieces that unless you have a firm knowledge of
every library and behavior script, there is no easy way to
Happy Holidays Trevor
Thank you for the thorough response. The Levure architecture, and what we came
up with SivaSiva app is very close. It would not really be to difficult to port
it one day to Levure.
With that in mind, though you say "Levure doesn't have a strong opinion one way
or the
On Wed, Dec 26, 2018 at 8:44 AM Sannyasin Brahmanathaswami via use-livecode
wrote:
> Always interest in improving (often terrifying beginning) my architecture,
> having read Andre's book on MVC. It comes to mind that we could use a
> standard structure, like
>
> 1) Card or Group
> 2) Assigned
Always interest in improving (often terrifying beginning) my architecture,
having read Andre's book on MVC. It comes to mind that we could use a standard
structure, like
1) Card or Group
2) Assigned in a unique view e.g. "behavior_viewHomeStory"
* handles the controls on the card and
46 matches
Mail list logo
