valueDiff for arrays?

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

Re: valueDiff for arrays?

Clarence Martin via use-livecode
I guess I'll have to admit I had to do the line-by-line to see it, but once
I did I realized what the problem was.  Pointers and reference counting is
one thing that I still really need to think about when looking at lower
level code.  That is one thing that really does make LCS nice.  LCB too for
the most part, you can get into pointer stuff, but it is when you venture
there on purpose (FFI and/or using engine library code).
_______________________________________________
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: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
On Sat, Aug 4, 2018 at 1:06 PM, Mark Wieder via use-livecode <
[hidden email]> wrote:

> On 08/04/2018 09:36 AM, Mark Waddingham via use-livecode wrote:
>
>> On 2018-08-04 18:25, Mark Wieder via use-livecode wrote:
>>
>
> Heh - well your pseudo-code just essentially made my point for me - why
>> does any of that need to be in the engine, if the engine provides the
>> underlying wrappers around the OS functionality (as it is on the specific
>> OS) to be able to write them? :)
>>
>
> LOL. Well, OK. But by exposing *just* the mobileXXX function at the
> scripting level, the onus is no longer on the developer to have to script
> the utility function for each application. You have the opportunity at this
> point to expose a single function rather than two or three.
>

So maybe what is really needed is a split of the revcommonlibrary into 3
separate ones:  revdesktoplibrary, revmobilelibrary, and revcommonlibrary.
Then utility functions that are easily written in LCS could be placed in
the appropriate library and would be available to all apps that are built
for that platform.  (I actually looked into this when working on adding the
common library to mobile.)
_______________________________________________
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: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
On 2018-08-04 20:06, Mark Wieder via use-livecode wrote:
> LOL. Well, OK. But by exposing *just* the mobileXXX function at the
> scripting level, the onus is no longer on the developer to have to
> script the utility function for each application. You have the
> opportunity at this point to expose a single function rather than two
> or three.
>
> https://www.knowyourphrase.com/beating-a-dead-horse

LOL - perhaps - but its an important point which I perhaps did not make
entirely clear - my bad!

My intent was never to suggest that every developer would have to hack
their own together in every individual case... More that is gives us the
opportunity to write an engine-level 'script library' in LCS which
provides the functionality.

We have quite a rich extension system these days - and even before that
liburl was embedded as essentially an engine feature, written in LCS
because of the way it was handled in the IDE and Standalone Builder.

Basically these lower-level platform specific operations can be used to
create a mobile handler script library, which would be a script-library
in the open source repository - which can contain the cross-platform
'mobile' implementations.

It makes it visible, accessible and something which is much easier for
people to contribute to - or copy, rename and modify as they need to for
their specific project.

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: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
On 2018-08-04 20:15, Brian Milby via use-livecode wrote:

> So maybe what is really needed is a split of the revcommonlibrary into
> 3
> separate ones:  revdesktoplibrary, revmobilelibrary, and
> revcommonlibrary.
> Then utility functions that are easily written in LCS could be placed
> in
> the appropriate library and would be available to all apps that are
> built
> for that platform.  (I actually looked into this when working on adding
> the
> common library to mobile.)

Yes! In the first instance that would be more than sufficient.

However, over time I'd suggest we look at it sitting in a
mobile-permissions script library. Given the dynamic nature of handler
dispatch in LC, there's all kinds of things we can do to make it really
easy to adapt for particular projects.

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: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
On 08/04/2018 11:19 AM, Mark Waddingham via use-livecode wrote:

> Basically these lower-level platform specific operations can be used to
> create a mobile handler script library, which would be a script-library
> in the open source repository - which can contain the cross-platform
> 'mobile' implementations.
>
> It makes it visible, accessible and something which is much easier for
> people to contribute to - or copy, rename and modify as they need to for
> their specific project.

Got it. And yes, that speaks directly to my point, so we're on the same
page. Whew! Email is sometimes not the easiest way to communicate, even
when both sides are speaking the (more or less) same language.

--
  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: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
On 08/04/2018 11:23 AM, Mark Waddingham via use-livecode wrote:

> However, over time I'd suggest we look at it sitting in a
> mobile-permissions script library. Given the dynamic nature of handler
> dispatch in LC, there's all kinds of things we can do to make it really
> easy to adapt for particular projects.

Although I do have to bemoan the proliferation of script stacks in the
Project Browser list. This especially became onerous when the Navigator
plugin started using script-only stacks. It's a pain having to scroll
through all those stacks that I'm never going to edit, and it's a pain
having to remove the plugin each time a new build comes out so that I
don't have to scroll through them just to work on system stacks.

--
  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: valueDiff for arrays?

Clarence Martin via use-livecode
On 2018-08-04 20:41, Mark Wieder via use-livecode wrote:

> On 08/04/2018 11:23 AM, Mark Waddingham via use-livecode wrote:
>
>> However, over time I'd suggest we look at it sitting in a
>> mobile-permissions script library. Given the dynamic nature of handler
>> dispatch in LC, there's all kinds of things we can do to make it
>> really easy to adapt for particular projects.
>
> Although I do have to bemoan the proliferation of script stacks in the
> Project Browser list. This especially became onerous when the
> Navigator plugin started using script-only stacks. It's a pain having
> to scroll through all those stacks that I'm never going to edit, and
> it's a pain having to remove the plugin each time a new build comes
> out so that I don't have to scroll through them just to work on system
> stacks.

So - what can we do to solve that?

The IDE script libraries at least use a very strict naming convention -
if we can encourage others to do the same, then there's all kinds of
filtering options we can do quite easily.

Remember that this isn't a unique problem to LiveCode - script only
stacks (particularly how we've grown to use them) are akin to C source
files / projects (mainly because that is abstractly what they are /
represent). You get a similar problem managing the complexity of that in
any large scale native project - look at the LiveCode main xcodeproj for
an example of that.

Perhaps 'Show IDE Stacks in lists' (or whatever it is called) has become
far far too blunt an instrument...

For example, the PB could offer a new 'top-level' - which is project. A
project being defined by a set of stacks which share a common name
prefix...

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: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
Mark Waddingham wrote:

 > Yes - so come up with LCS handlers which do that, share them, let's
 > work together to make them as efficient in LCS as possible and then
 > see what we can do in the engine to improve their performance (which
 > I'm guessing is as much the purpose for the proposition as the
 > syntax).

It is, primarily.  The minor convenience is nice too, but you know how
much I love to see performance enhancements in the engine.

As for implementation, Mark Wieder's looks good:
http://lists.runrev.com/pipermail/use-livecode/2018-August/248862.html

Thinking about performance, I wonder if there's anything from some of
the changes that have boosted PHP 7's performance so far above its
earlier versions which may be relevant for LC:
https://www.reddit.com/r/PHP/comments/3q2brz/how_is_php_7_twice_as_fast/

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.co

_______________________________________________
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: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
Plugins should probably be de-scriptified for distribution for this
reason.  A similar argument could be made for some IDE library code too.  I
have to wonder if there is any performance impact to the number of stacks
the IDE has to deal with now that so much is scriptified.  (The list of
stacks is a linked list and finding a stack by name goes through the list
at least in one spot.).  I've been thinking of how to test this sort of
thing to measure it

It would be similar to how copy-on-write does incur a small amount of
overhead when compared to pass-by-reference that was demonstrated in an
earlier discussion.  The result there was that if you need to optimize for
speed, reference is still helpful.  If you are purely concerned about
memory usage, then it isn't needed.

On Sat, Aug 4, 2018 at 1:41 PM, Mark Wieder via use-livecode <
[hidden email]> wrote:

> On 08/04/2018 11:23 AM, Mark Waddingham via use-livecode wrote:
>
> However, over time I'd suggest we look at it sitting in a
>> mobile-permissions script library. Given the dynamic nature of handler
>> dispatch in LC, there's all kinds of things we can do to make it really
>> easy to adapt for particular projects.
>>
>
> Although I do have to bemoan the proliferation of script stacks in the
> Project Browser list. This especially became onerous when the Navigator
> plugin started using script-only stacks. It's a pain having to scroll
> through all those stacks that I'm never going to edit, and it's a pain
> having to remove the plugin each time a new build comes out so that I don't
> have to scroll through them just to work on system stacks.
>
> --
>  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
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
On 2018-08-04 20:37, Mark Wieder via use-livecode wrote:

> On 08/04/2018 11:19 AM, Mark Waddingham via use-livecode wrote:
>
>> Basically these lower-level platform specific operations can be used
>> to create a mobile handler script library, which would be a
>> script-library in the open source repository - which can contain the
>> cross-platform 'mobile' implementations.
>>
>> It makes it visible, accessible and something which is much easier for
>> people to contribute to - or copy, rename and modify as they need to
>> for their specific project.
>
> Got it. And yes, that speaks directly to my point, so we're on the
> same page. Whew! Email is sometimes not the easiest way to
> communicate, even when both sides are speaking the (more or less) same
> language.

Heh - indeed - the thought in my mind was always that it would be a
common script-library - however, looking back I never actually
articulated that.

By the way @Richard - my suggestion for 'valueDiff' (or whatever variant
comes out of any discussion) was that after some fettling over the
details - such things like that could, too, become part of a common
'utility' script library in the engine repository (or a set of utility
libraries, after all not every project needs everything).

Indeed, internally we have already been building such a thing (for
various reasons - although mainly because I got bored hand-coding the
same lines of code again and again - which I'm sure we all do!) - its
not ready for public release yet, but we fully intend to do so when
we've dotted a few i's and crossed a few t's. (We need to support it
after all if it is the main repository - so I want to make sure it is in
a supportable state when it debuts).

One of the most useful things it has are LiveCode implementations of the
Python path functions - and, oh my god, do they make any code which
manipulates files soooo much easier.

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: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
On 2018-08-04 21:00, Brian Milby via use-livecode wrote:

> Plugins should probably be de-scriptified for distribution for this
> reason.  A similar argument could be made for some IDE library code
> too.  I
> have to wonder if there is any performance impact to the number of
> stacks
> the IDE has to deal with now that so much is scriptified.  (The list of
> stacks is a linked list and finding a stack by name goes through the
> list
> at least in one spot.).  I've been thinking of how to test this sort of
> thing to measure it

Indeed that would be interesting - I think @Monte proposed a patch to
make stack-by-filename lookups hash-table based recently (it was attempt
to fix an unrelated thing which was more important - and I'm not sure
the speed improvement necessarily justified the extra code complexity -
until we can abstract the whole caching things logic to a common
pattern). Certainly making the stack list hash-by-name (like control
id's per stack) would probably help. Although there are a few salient
details which make them quite a bit more complex than the id case - e.g.
substacks can have the same name as a mainstack.

> It would be similar to how copy-on-write does incur a small amount of
> overhead when compared to pass-by-reference that was demonstrated in an
> earlier discussion.  The result there was that if you need to optimize
> for
> speed, reference is still helpful.  If you are purely concerned about
> memory usage, then it isn't needed.

Again - interesting - can you pull out that exact case, it is a little
surprising (which makes me wonder whether there are some specific
details it which are actually exceptionally important). For example:

on foo @xValue
   return xValue[5]
end foo

on bar pValue
   return pValue[5]
end bar

on testFoo pArray
   put "baz" into pArray[1][2][3][4]
   repeat 10000 times
     foo pArray[1][2][3][4]
   end repeat
end testFoo

on testBar pArray
   put "baz" into pArray[1][2][3][4]
   repeat 10000 times
     bar pArray[1][2][3][4]
   end repeat
end testBar

You should find that whilst these two things do exactly the same thing
that testFoo will be a lot slower than testBar.

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: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
On 8/4/18 12:41 PM, Mark Waddingham via use-livecode wrote:
> Can you immediately see the error?

Who, me? LOL. Well, I did find the line that was different. Brian and
others who can read this stuff did better. But I did get the gist of
your post and feel sufficiently smug now.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
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: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
On 2018-08-04 21:00, Richard Gaskin via use-livecode wrote:

> Mark Waddingham wrote:
>
>> Yes - so come up with LCS handlers which do that, share them, let's
>> work together to make them as efficient in LCS as possible and then
>> see what we can do in the engine to improve their performance (which
>> I'm guessing is as much the purpose for the proposition as the
>> syntax).
>
> It is, primarily.  The minor convenience is nice too, but you know how
> much I love to see performance enhancements in the engine.

:)

The important thing you have to remember is that you only get a
performance advantage for hand-coding code like that in the engine *if*
the overhead of dispatching script dominates the processing being done.
That can actually be really hard to determine from inspection.

Especially if things require hash-key lookups (i.e. name creation) -
then you might find you get a speed up for things involving small
numbers of keys - but virtually none for large numbers of keys
(particularly as the key size goes up).

So you then have to balance whether its 'worth it' from a C++ code
maintenance point of view.

Certainly, I guess a metric could be 'how much is a particularly utility
function used'. i.e. If a utility function gets into a common library,
and we find that it is used 'all the time' across many different
projects *then* it should probably be put on the list for being
implemented in the engine (and deserve English-like syntax in the
process!).

>
> As for implementation, Mark Wieder's looks good:
> http://lists.runrev.com/pipermail/use-livecode/2018-August/248862.html
>
> Thinking about performance, I wonder if there's anything from some of
> the changes that have boosted PHP 7's performance so far above its
> earlier versions which may be relevant for LC:
> https://www.reddit.com/r/PHP/comments/3q2brz/how_is_php_7_twice_as_fast/

I'd actually be really interested in a direct speed comparison between
exactly equivalent operations in PHP7 and LC.

The reason is that (from my previous relatively terse, admittedly,
review of PHP7's implementation details) LC actually does mostly the
same things - and has done since 7. All of it related to the
introduction of libfoundation (which I actually started designing, and
started implemented about 7/8 years ago - long before it appeared in a
release - although the seeds for it were planted long before -
namification of handler names, and literals in the engine at version 5
or 6 being a key precursor).

There is actually (and always has been) quite a long list of things
which I've always wanted to do with libfoundation to improve its
performance vastly - pleasingly many of those ideas are more than
validated by PHP7 (as it actually does them!). However, most of them
have a huge ripple effect on a substantial portion of the code - and
that's a significant issue.

For example - MCNameRef which is a 'uniqued string' (IS_STR_INTERNED in
PHP7 speak) used for all literals, handler names, array keys etc. is a
separate value type to MCString. This was a design error (born of the
previous rendering of MCNameRefs pre-7) with hindsight - it should have
been a kind of MCString.

Similarly, integer array keys should be integers - and not rendered as
strings at all unless needed.

These two things are relatively easy to do at the libfoundation level,
but they require a significant API change - which I don't think can be
made backwards compatible which means updating all uses. None the
updating work is necessarily hard - but it needs to be done carefully
and needs to be exceptionally well planned so it can be done rapidly and
all in one go as it would be really difficult to maintain two separate
branches whilst it was being done (honestly 7 was a complete nightmare
from that point of view - I don't even want to think about the amount of
man hours that went into just keeping the 6 and develop-7 branches in
sync!!).

Other things (like storing short strings in the value memory block,
rather than in a separate array) I think could be done without any
changes to the libfoundation API.

I also experimented with (small) integers being 'tagged pointers' at one
point - which would eliminate the overhead of most integer operations.
However, as it turned out the idea on its own didn't really make a great
deal of difference - what did make a difference was a value pool
allocator - number values 'live fast and die young' which means that if
you cache the most recently freed number value, and re-use that you
eliminate their overhead. That same pattern worked exceptionally well
for other values too (short strings, for example).

Of course, tagged integers would probably make a substantial difference
if array keys didn't have to be names - the performance of even
hash-table based sequences would be far faster.

Anyway, I could probably go on at length about this but will stop there.

As a point of comparison, the reason why PHP7 has these things and LC
does not (yet) is simply because I think you'll find that PHP7 has (1)
taken a great deal longer to get any of it than LC did (LC started
getting these things at 7)... And PHP has quite a number more engineers
involved in it at the C++ level than I think we do...

Warmest Regards,

Mark.

P.S. I do need to dig into PHP7's exact details more - it is something
I've only had brief amounts of time to do so - at the very least it
should indicate what does and does not work and also help see how we
could do them better :)

--
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: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
On 2018-08-04 21:20, J. Landman Gay via use-livecode wrote:
> On 8/4/18 12:41 PM, Mark Waddingham via use-livecode wrote:
>> Can you immediately see the error?
>
> Who, me? LOL. Well, I did find the line that was different. Brian and
> others who can read this stuff did better. But I did get the gist of
> your post and feel sufficiently smug now.

Well you can share your smugness with all Python, JavaScript, Java, C#,
BASIC variants, and pretty much every other programmer who has chosen a
high-level language (in terms of ones which takes away the need to think
about memory management) as their main tool - at least in this regard.
(Here by 'high-level' I mean one which abstracts away memory management
and pointer manipulation entirely from your normal concerns).

However, I'd like to think that LiveCode actually sits in a slightly
better class... It does not rely on a 'garbage collector' - all memory
management is explicit - its just the engine does all the explicit work
for you. It manages high-level safety without resorting to what is
essentially a 'panic' solution to solving the problem (which actually
has profound and rather unpleasant side-effects and edge cases in all
kinds of ways most programmers who are used to relying on one don't even
realize - but find out pretty quickly about then their fail
catastrophically) ;)

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: valueDiff for arrays?

Clarence Martin via use-livecode
On 2018-08-04 21:51, Mark Waddingham via use-livecode wrote:
> one don't even realize - but find out pretty quickly about then their

That should be 'when they' - not then their.

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: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
On 08/04/2018 11:55 AM, Mark Waddingham via use-livecode wrote:

> Remember that this isn't a unique problem to LiveCode - script only
> stacks (particularly how we've grown to use them) are akin to C source
> files / projects (mainly because that is abstractly what they are /

I do realize that. But now that we've opened that can of worms I don't
think we can just go on ignoring it. And the difference between LC
script-only stacks and C source files is that you don't get to
distribute a single compiled object in LC... you end up with a mainstack
and several text files to distribute, and they need to stay together and
in the same relative position. It's messy.

> Perhaps 'Show IDE Stacks in lists' (or whatever it is called) has become
> far far too blunt an instrument...

What I was thinking.

> For example, the PB could offer a new 'top-level' - which is project. A
> project being defined by a set of stacks which share a common name
> prefix...

Well, when the PB was first proposed, that's where I thought this was
heading.

One thing I'd like, since you're asking (place this in the 'watch what
you ask for' category) is to be able to use script-only stacks as
substacks. That way I could edit them with a text editor and still work
with only a single unified object. And the PB would hide the component
stacks within the mainstack until I chose to examine them, the same way
that substacks now work. Obviously there are script-only stacks that
would not need to be substacks, but that's no different from the way
stacks and substacks work now.

And btw, thanks for your input on this list. On a Saturday even. Much
appreciated.

--
  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: valueDiff for arrays?

Clarence Martin via use-livecode
On 2018-08-05 01:14, Mark Wieder via use-livecode wrote:
> I do realize that. But now that we've opened that can of worms I don't
> think we can just go on ignoring it. And the difference between LC
> script-only stacks and C source files is that you don't get to
> distribute a single compiled object in LC... you end up with a
> mainstack and several text files to distribute, and they need to stay
> together and in the same relative position. It's messy.

Yes - however, as @Brian already pointed out in another message which
distracted me in terms of a technical point of performance rather than
the more important' high-level point he made...

>> Perhaps 'Show IDE Stacks in lists' (or whatever it is called) has
>> become far far too blunt an instrument...
>
> What I was thinking.
>> For example, the PB could offer a new 'top-level' - which is project.
>> A project being defined by a set of stacks which share a common name
>> prefix...
>
> Well, when the PB was first proposed, that's where I thought this was
> heading.

Yes - 'projects' are a concept which LiveCode needs - although like lots
of things its a case of 'when' rather than 'if' (even if the 'when' has
been and still is measured in rather long timecales!).

> One thing I'd like, since you're asking (place this in the 'watch what
> you ask for' category) is to be able to use script-only stacks as
> substacks. That way I could edit them with a text editor and still
> work with only a single unified object. And the PB would hide the
> component stacks within the mainstack until I chose to examine them,
> the same way that substacks now work. Obviously there are script-only
> stacks that would not need to be substacks, but that's no different
> from the way stacks and substacks work now.

I think modifications to the PB and a stricter naming convention for
stacks could solve most of the problems which do exist here.

After all it doesn't matter if (in memory) all stacks are in a 'flat'
list (its up to the engine to optimize lookup) really - what matter is
the view of them which is presented in the IDE - which is almost purely
a PB concern.

The other side of this, is what Brian hinted at - when building for
distribution script-only stacks which are essentially 'children' of some
component should be built into a single stack with substacks.

This is essentially what scriptification and descriptification do: we
have code for this in the repository... For example, there is an
embedded UI stack in the engine which deals with licensing (the one
which really does anything is in the livecode-private - which you all
never see as that's the commercial side of the code). The environment
stack (whether public or private) exists as a collection of script-only
stacks and a single binary stack which holds the UI in the github
repository, and when building the engine those collection of files get
turned into a single mainstack.

This could be done for all the IDE components which are composed in this
way at the point we build the distribution - it would cut down the
number of mainstacks considerably, and again perhaps mean 'show LiveCode
UI elements' actually does the same as it did before things started to
be scriptified.

The other place this could come to bear is making the S/B (or some
variant there-of) not only work to produce an application, but also a
'component/extension' - i.e. a distributable 'compiled' (in some sense)
form of a collection of script only stacks which were much more easily
distributable.

The only thing we would lose by using this kind of process on the IDE
would be the easy ability to 'monkey-hack' the IDE - although not
significantly - it would just be slightly harder to pull out the changes
to submit as a PR if you wanted too...

However, that being said - we then just add a way you could just pull
the IDE repository and have it use an engine from a pre-installed
distribution.

Internally we tend to edit the IDE from engines built from the engine
repository - there's various redirection logic in the IDE and engine, so
that when a 'build-from-source' engine is run, it looks to see if it is
a github checkout, and if so loads and runs the IDE from the IDE
submodule checkout.

So upshot - in reality - we have most of the code and mechanisms already
to at least get a long way to the ideal (which is a much more
structured, built-in component architecture), it is 'just' a case of
plumbing it in in some of the ways outlined above. Admittedly, not a
small project, but certainly not one which would needed to be started
from ground-zero.

> And btw, thanks for your input on this list. On a Saturday even. Much
> appreciated.

Hehe - well it is a working day for me today, and tomorrow and the next
week - I'm currently in Dallas, Texas, for FileMaker DevCon.

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: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
On Sat, Aug 4, 2018 at 6:14 PM, Mark Wieder via use-livecode <
[hidden email]> wrote:

> On 08/04/2018 11:55 AM, Mark Waddingham via use-livecode wrote:
>
> Remember that this isn't a unique problem to LiveCode - script only stacks
>> (particularly how we've grown to use them) are akin to C source files /
>> projects (mainly because that is abstractly what they are /
>>
>
> I do realize that. But now that we've opened that can of worms I don't
> think we can just go on ignoring it. And the difference between LC
> script-only stacks and C source files is that you don't get to distribute a
> single compiled object in LC... you end up with a mainstack and several
> text files to distribute, and they need to stay together and in the same
> relative position. It's messy.


I don't think it has to be this way.  It would not be that difficult to
script the integration of all included behaviors into buttons of a resource
substack or even as substacks.  I actually envision something along these
lines for my Script Tracker as a way to include external library code in a
single file stack yet still have it be managed outside of the stack (my
code would sync the actual library code with a button that the stack would
use as the library or behavior). One advantage is that name resolution of
the behaviors would then be automatic.

One thing I'd like, since you're asking (place this in the 'watch what you
> ask for' category) is to be able to use script-only stacks as substacks.
>

Script Tracker could allow something like this now.  The substacks would
not be script only, but the exported script would look just like one.

And I've looked at how Trevor is having Sublime Text notify LiveCode that a
stack has been saved and believe that the same sort of thing is possible
with Atom.  Also, the code he uses to update a script only stack inside the
IDE could also be used in a folder watch script to do the same thing
without running a server process.  I'm sure that at a certain point the
number of files/folders watched would make it better to use his approach.

And I'm still looking for the code examples checking parameters.  I must
have deleted my stack since I don't see it.

Brian
_______________________________________________
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: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
On 2018-08-04 21:00, Richard Gaskin via use-livecode wrote:

> Mark Waddingham wrote:
>
>> Yes - so come up with LCS handlers which do that, share them, let's
>> work together to make them as efficient in LCS as possible and then
>> see what we can do in the engine to improve their performance (which
>> I'm guessing is as much the purpose for the proposition as the
>> syntax).
>
> It is, primarily.  The minor convenience is nice too, but you know how
> much I love to see performance enhancements in the engine.
>
> As for implementation, Mark Wieder's looks good:
> http://lists.runrev.com/pipermail/use-livecode/2018-August/248862.html

One important point here (which I think is something which is often
overlooked in LC as it is just something we deal with implicitly case by
case)...

In your use-case for 'valueDiff' - do you need to tell the difference
between a key value being the empty string and a key value not being
present at all?

[ i.e. using an array key absence to emulate 'nothing': meaning you are
actually storing nothing or a value (even the empty string). ]

It might seem like a minor detail, but does change the operation
somewhat (and potential implementations).

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: valueDiff for arrays?

Clarence Martin via use-livecode
Here is code that only uses LCS to accomplish the goal (only returning the
keys where they exist in both arrays but the values are different).  This
is made to be similar to the way the existing functions work (with the
option to mutate).

command valueDiff @pDestinationA, @pLeftA, pRightA
   local tMutate, tLeft, tRight, tNewRight
   if the paramCount is 3 then
      put false into tMutate
      put pLeftA into tLeft
      put pRightA into tRight
   else
      put true into tMutate
      put pDestinationA into tLeft
      put pLeftA into tRight
   end if
   repeat for each key tKey in tLeft
      if tKey is among the keys of tRight and \
            tLeft[tKey] is not tRight[tKey] then
         put tRight[tKey] into tNewRight[tKey]
         next repeat
      end if
      delete variable tLeft[tKey]
   end repeat
   if tMutate then
      put tLeft into pDestinationA
      put tNewRight into pLeftA
   else
      put tLeft into pDestinationA["1"]
      put tNewRight into pDestinationA["2"]
   end if
end valueDiff

My question from an engine perspective is whether it would be faster to
just generate both arrays instead of removing keys from tLeft.  I decided
to build the tNewRight to avoid iterating the keys of tRight.

I'd be pretty confident that Mark's solution will be faster, even with 3
iterations over the keys.

On Sat, Aug 4, 2018 at 6:52 PM, Mark Waddingham via use-livecode <
[hidden email]> wrote:

> On 2018-08-04 21:00, Richard Gaskin via use-livecode wrote:
>
>> Mark Waddingham wrote:
>>
>> Yes - so come up with LCS handlers which do that, share them, let's
>>> work together to make them as efficient in LCS as possible and then
>>> see what we can do in the engine to improve their performance (which
>>> I'm guessing is as much the purpose for the proposition as the
>>> syntax).
>>>
>>
>> It is, primarily.  The minor convenience is nice too, but you know how
>> much I love to see performance enhancements in the engine.
>>
>> As for implementation, Mark Wieder's looks good:
>> http://lists.runrev.com/pipermail/use-livecode/2018-August/248862.html
>>
>
> One important point here (which I think is something which is often
> overlooked in LC as it is just something we deal with implicitly case by
> case)...
>
> In your use-case for 'valueDiff' - do you need to tell the difference
> between a key value being the empty string and a key value not being
> present at all?
>
> [ i.e. using an array key absence to emulate 'nothing': meaning you are
> actually storing nothing or a value (even the empty string). ]
>
> It might seem like a minor detail, but does change the operation somewhat
> (and potential implementations).
>
> 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
12345 ... 7