Re: LiveCode repo name change fixer

[Mark Waddingham]

On 2015-09-10 05:31, Monte Goulding wrote:
On 10 Sep 2015, at 1:06 pm, Richard Gaskin 
 wrote:


> I also saw the email notice on the fact that we can expect a lot more
> submodules in the future to deal with widgets. Not something I'm
> looking forward to.


I'm not sure we are looking forward to it either. We're getting to the 
point where we could start to split up various things into separate, 
independently maintainable pieces and as such it would probably make 
sense for them to inhabit their own repository however submodules do 
cause headaches at times for the reason Monte outlines below.



What are your concerns?


The issue with submodules is just a workflow thing. You’ve got to
remember to commit changes to the submodule before you commit to the
main repo because the commit on the main repo contains a reference to
the commit on the submodule. In general submodules that you don’t
maintain and just update every now and then are a godsend. Submodules
in the one project that share branch names etc like the ide and
thirdparty ones in the livecode repo not so much… I’m actually not all
that sure why these were made submodules in the first place. I’m
fairly sure we discussed it back when it was all originally pushed but
it I can’t remember…


I think there are various discussions about it from wayback when.

The prebuilt submodule (now defunct) was to prevent large binary blobs 
that would change periodically taking up repo space (remember that 
github history is perpetual - it monotonically increases in size). 
Eventually my original intention happened with this when we developed 7 
- the submodule got replaced by scripts which downloaded the necessary 
blobs.


The ide submodule was due to the fact we could not use a git work-flow 
in IDE components because of their binary nature. Indeed, for a long 
while, the IDE submodule was a facisimile of an SVN repository which was 
used to do a standard lock-update-unlock flow. Obviously, since then, 
we've get scriptified stacks and a reasonable process of editing the 
binary stacks via using PRs in GitHub so it is much better integrated. 
We periodically have discussions about folding it in to the main repo.


The thirdpary submodule, again, was meant to be a temporary thing - 
again with the point of view of not eternally inflating the size of the 
repository with stuff which is derived or comes from elsewhere. My 
original plan was that all our third-party library uses would be 
downloaded from source, and then patched with our changes at the point 
of build. The only thing stored in the LiveCode repo would then be the 
patches, and not code which is actually maintained elsewhere. 
Unfortunately, however, this is one project which we have never gotten 
around to (but it did come up again recently - so it hasn't been 
forgotten).


One option, in the future, if we move to a multi-submodule arrangement 
is to make it flat and not a tree - which I think is the main problem 
(if you mutate a leaf, you have to then change all ancestors of said 
leaf). Instead, we'll have a core repository which points to a list of 
all projects (as which are needed to build the product. We can use 
scripts to make the links at the top-level symbolic rather than hash 
based which would solve the having to update the parent problem. If this 
is then combined with a 'thirdparty libraries is download link + patch' 
type arrangement it should mean that all projects are leaves and don't 
require nested submodules. However, this is probably a way off, a fair 
bit more thought needs to go into it as we divide things up into 
separate extensions.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LiveCode repo name change fixer

[Monte Goulding]

> On 10 Sep 2015, at 7:13 pm, Mark Waddingham  wrote:
> 
> I'm still not sure my decision to require a UTF-8 BOM at the start to 
> differentiate from a native platform encoding file was a good idea though. I 
> probably should have just assumed UTF-8 regardless. (Hindsight being 20/20 of 
> course).

Would be nice if it doesn’t need to be there to make it easier to create them 
in external editors.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Embeded LiveCode -- a distant dream that is dead???

[David Bovill]

I second that question...

On Thursday, September 10, 2015, Mark Rauterkus 
wrote:

> Hi All,
>
> With v8 and beyond, is there any Embeded LiveCode in the future or is that
> vision terminated?
>
> Wondering.
>
> --
> Ta.
>
>
> Mark Rauterkus   m...@rauterkus.com
> PPS Summer Dreamers' Swim & Water Polo Camp Executive Coach
> Varsity Boys Swim Coach, Pittsburgh Obama Academy
> Recent Head Water Polo Coach, Carnegie Mellon University Women's Club Team
> Pittsburgh Combined Water Polo Team
>
> http://CLOH.org
>
> 412 298 3432 = cell
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com 
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: This Is Why We Can't Have Nice Things

[Ali Lloyd]

> I will say, though,
> that it's more than a bit frustrating that two and half years after the
> initial open source release there's still no mechanism in place for
> accepting arbitrary IDE stack changes. I would have thought that more
> resources devoted to scriptifying more of the IDE stacks would result in
> offloading tasks from the internal team, get more long-standing bugs
> fixed, and ease the process of adding new features.

We're in total agreement here. Unfortunately I did it prior to moving the
IDE to GitHub, so I can't give a link to prove how massive the task of
extracting all the scripts and custom properties from the revLibrary stack
and moving them to script-only stacks was (indeed it was doing this that
made it worthwhile moving the IDE to GitHub in the first place). Obviously
actually moving the code is trivial, but updating the references elsewhere
in the IDE, making it work with the standalone builder, and finding a new
home for the data stored in custom properties is not at all.

As much as possible of this was done in 6.7, but it did cause a number of
regressions, especially with standalone building - this is part of the
reason there have been so many releases since 6.7.4, when this took place.
But it has been worthwhile - even though we haven't yet had many community
contributions, there have been a great deal of benefits to our workflow,
and it has made it much easier for us to fix bugs in those stacks.

Scriptifying the IDE's palettes is a slightly different task, and one which
we haven't been pursuing for its own sake. But since the 8.0 IDE
necessitated many changes, we have made a point of scriptifying any palette
in which major changes were made. Hence the scriptified menubar, tools
palette, property inspector, script editor behaviors and dictionary. We
felt more comfortable making these changes in the 8.0 DP cycle than rocking
the boat in 6 / 7.

Having said that, it is worth noting that the engine in LC 8 is essentially
stable. The only real difference between it and the LC 7 engine is LiveCode
Builder, which is more of an addition than a change. The main reason 8 is
still DP is because of the changes to the IDE, and a stack without widgets
should behave exactly the same in 8 as in 7.


On Thu, Sep 10, 2015 at 7:23 AM Richmond 
wrote:

> On 09/10/2015 04:28 AM, Mark Wieder wrote:
> > On 09/09/2015 12:06 AM, Ali Lloyd wrote:
> >
> >> I'm sorry you felt it was passive-aggressively not accepted. It was
> >> meant
> >> neither as passive-agressively , nor  not accepted.
> >
> > Well, that was intended to be a flippant remark, the the posting
> > subject should have reinforced that.
> > Seems like I struck a nerve.
> > I was referring to the fact that my pull request wasn't rejected, but
> > it also was placed in a we're-not-going-to-accept-this category.
> > See my further comments to Mark's post, but otherwise my apology for
> > the unintended slight.
> >
>
> Mark, "*flippant*" remarks often seem to hit nerves over at the
> mother-ship, lest you haven't noticed.
>
> We could open a whole new thread about *intentionality* here . . .
>
> Richmond.
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: This Is Why We Can't Have Nice Things

[Mark Waddingham]

I just remembered why you thought that I had a binary diff in lcvcs.
Way back when I first started looking at it I was thinking of making a
diff driver which you can set in git’s config to generate a text
representation of a binary file just for the diff. This would be
almost perfect for the review process if we could come up with a file
format that was just a single file for a stack with the exception that
github won’t show the text diff so they would need to review a PR
locally. It won’t help them merge but will show them what’s changed
and if there’s no other branches with changes to that file they can
just accept or reject the changed file. For this I think it would be
acceptable to just have a script that looped over all the objects and
added their long name (with stack name instead of file path) and their
script to the file. It may be they want to diff properties and custom
properties too but that wouldn’t be that difficult to arrange. It
doesn’t need to be any special file format because it’s never going to
get read in and rebuilt into a stack.


I do wonder if a GitHub hook could be used here. Peter's done some great 
things with them in terms of PR review, CLA checking and CI via our 
'vulcanbot' build system.


If PRs which contain stacks were monitored by vulcan, it might be able 
to pick up when they aren't going to merge due to binary reasons and 
provide a link to a page which shows the diff so at least the review 
process could start and provide feedback to the submitter. It would 
still be a chunk of work to integrate such things (as if the target 
stack had changed since the submitted stack was modified, you can't just 
copy the submitted one over the target one) but at the very least that 
would give a list of changes that need to be applied.


Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: This Is Why We Can't Have Nice Things

[Mark Waddingham]

On 2015-09-10 08:23, Richmond wrote:

Mark, "*flippant*" remarks often seem to hit nerves over at the
mother-ship, lest you haven't noticed.


There's a difference between 'flippant' remarks and...

"Oh look what LiveCode have done now. How stupid is that. They obviously 
don't know what there doing. I know far better."


Which is, to be frank, quite a frequent apparent subtext in a lot of 
your posts :)



We could open a whole new thread about *intentionality* here . . .


And a whole new thread on ensuring that what you write actually comes 
across how you intend (indeed, I think this has come up on the list 
before).


Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LiveCode repo name change fixer

[Monte Goulding]

Thanks for explaining all that again Mark. It does sound vaguely familiar.
> 
> One option, in the future, if we move to a multi-submodule arrangement is to 
> make it flat and not a tree - which I think is the main problem (if you 
> mutate a leaf, you have to then change all ancestors of said leaf). Instead, 
> we'll have a core repository which points to a list of all projects (as which 
> are needed to build the product. We can use scripts to make the links at the 
> top-level symbolic rather than hash based which would solve the having to 
> update the parent problem. If this is then combined with a 'thirdparty 
> libraries is download link + patch' type arrangement it should mean that all 
> projects are leaves and don't require nested submodules. However, this is 
> probably a way off, a fair bit more thought needs to go into it as we divide 
> things up into separate extensions.

Hmm… I’ve wondered if one of the issues is the fact that the ide and engine 
repos are back to front in terms of the normal way you would use submodules. As 
the IDE depends on the engine and not the other way around it seems more 
logical to put it in a root repo and then have the engine be a submodule. That 
way there’s no issues like the engine guys checking out the most recent IDE to 
see if the engine fixed or broke something and that checkout dirtying the 
engine repo.

Personally I’d rather see more use of submodules and more hierarchy rather than 
less. Each thirdparty thing could be a submodule if there’s a public git repo 
for them so they can be updated easily.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LiveCode repo name change fixer

[Mark Waddingham]

On 09/09/2015 06:25 PM, Monte Goulding wrote:

Script only stacks work in 6. Not sure which version they were 
introduced but but in 6.7.7 there’s a bucket load of script only 
stacks in the IDE for libraries.


Huh. So they are. At least as far back as 6.7.5 anyway.
Somehow I missed that fact.


The history of script only stacks goes back to at least 6.7.0, maybe 
even later maintenance releases of 6.6.x.


The motivation was iOS SDK support. At that point there seemed to be 
constant changes being required to the iOS standalone builder to 
continue to support the bleeding edge iOS SDK - it was the most updated 
IDE component at the time.


As, at that point, we had essentially 2/3 IDE branches we had to keep in 
sync, it was becoming a real headache to manage the changes and ensure 
that the revSaveAsIOSStandalone stack was kept in-sync, up to date and 
working in all branches.


I hacked in something to allow a stack to be a text file since that was 
all (for all intents as purposes) what the revSaveAsIOSStandalone stack 
contained - a single stack script. It was a bit rough at first - I was 
trying to solve an immediate problem rather than produce a fully fledged 
feature.


Then someone else in the company noticed it for some other reason, and 
started using it, fed back so I could fix a few issues in it.


I was always slightly concerned about the data-loss potential - the 
reason we never presented it as a 'supported feature' in the first 
instance because I wasn't sure whether the engine should be more 
draconian about their use. i.e. Should the engine stop you from creating 
objects / setting custom props on such a stack?


As it turns out, however, my concerns about that aspect turned out not 
be concerns at all. The utility of script only stacks just as they are 
more than justified their existence and they've been growing in 
usefulness ever since.


I'm still not sure my decision to require a UTF-8 BOM at the start to 
differentiate from a native platform encoding file was a good idea 
though. I probably should have just assumed UTF-8 regardless. (Hindsight 
being 20/20 of course).


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LiveCode repo name change fixer

[Mark Waddingham]

On 2015-09-10 12:07, Monte Goulding wrote:

On 10 Sep 2015, at 7:13 pm, Mark Waddingham  wrote:

I'm still not sure my decision to require a UTF-8 BOM at the start to 
differentiate from a native platform encoding file was a good idea 
though. I probably should have just assumed UTF-8 regardless. 
(Hindsight being 20/20 of course).


Would be nice if it doesn’t need to be there to make it easier to
create them in external editors.


Indeed. I think this is actually something we can change without causing 
any problems:


If a script only stack file contains a BOM at the start then engine only 
processes it as UTF-8.


If a script only stack file does not contain a BOM, then it tries to 
decode as UTF-8 if this fails it decodes as native platform encoding.


This should work because it is incredibly unlikely that a native 
platform encoded textfile will appear as well-formed UTF-8.


Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LiveCode repo name change fixer

[Mark Waddingham]

Hmm… I’ve wondered if one of the issues is the fact that the ide and
engine repos are back to front in terms of the normal way you would
use submodules. As the IDE depends on the engine and not the other way
around it seems more logical to put it in a root repo and then have
the engine be a submodule. That way there’s no issues like the engine
guys checking out the most recent IDE to see if the engine fixed or
broke something and that checkout dirtying the engine repo.


That way round came about because of how we used to managed IDE changes 
- we used SVN behind the scenes and synched changes across. Therefore, 
the IDE submodule was (for a long time) only a mirror of another VCS 
system.


That's obviously not true anymore, which is why your suggested ordering 
might well make more sense :)



Personally I’d rather see more use of submodules and more hierarchy
rather than less. Each thirdparty thing could be a submodule if
there’s a public git repo for them so they can be updated easily.


I don't think I have anything particularly against submodules, as 
greater separation of things should make management of individual 
components easier. The only thing to solve is to make managing the 
submodule pointers easier - that could be resolved using some sort of 
symbolic reference system (which I think is possible via git integration 
scripts and such). Indeed, I think chromium does something along those 
lines to manage all of its third-party dependencies.


It's definitely something we'd like to sort out at some point after some 
planning, after all we don't want to play around with the repo structure 
too frequently... As things always break as a result of doing so, and 
getting back to where you started takes a while.


Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LiveCode repo name change fixer

[Mark Waddingham]

On 2015-09-10 12:40, Monte Goulding wrote:

I wouldn’t worry about the native encoding. Just throw an error
mentioning utf8 and be done with it.


True enough - I guess it's easier enough for someone to convert a rogue 
file from platform -> UTF8 externally - should any platform encoded 
script only stacks actually exist!


Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LiveCode repo name change fixer

[Monte Goulding]

> On 10 Sep 2015, at 8:18 pm, Mark Waddingham  wrote:
> 
> Indeed. I think this is actually something we can change without causing any 
> problems:
> 
> If a script only stack file contains a BOM at the start then engine only 
> processes it as UTF-8.
> 
> If a script only stack file does not contain a BOM, then it tries to decode 
> as UTF-8 if this fails it decodes as native platform encoding.
> 
> This should work because it is incredibly unlikely that a native platform 
> encoded textfile will appear as well-formed UTF-8.

I wouldn’t worry about the native encoding. Just throw an error mentioning utf8 
and be done with it.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: BBEdit/Textwrangler LCM for livescript

[jameshale]

Updated livecodeBuilder CLM to adjust function regex so that function names
appear in BBEdit's function popup

https://dl.dropboxusercontent.com/u/8212901/LiveCodeBuilder.plist
 

James



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/BBEdit-Textwrangler-LCM-for-livescript-tp4696091p4696217.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: This Is Why We Can't Have Nice Things

[Richmond]

On 09/10/2015 07:59 PM, Richard Gaskin wrote:

Dirk prive wrote:

> I tend to stay quiet a lot, and prefer being silent on the side
> lines

...but when you finally did write here it was very valuable, so I hope 
you'll do so more often.



> but I have noticed that there is a difference between what was
> expected from an open sourced LiveCode and what is actually possible
> with the open source version of LiveCode.
> When people hear "open source", I think it is completely normal that
> they expect to read the source, make adjustments, and give them back
> to the project. This way the project can be improved by anyone that
> wants to help.
> That's how open source works generally.
> With LiveCode we apparently have binary stacks that can be edited,
> but the changes can't be merged back into the project.
> That completely goes against what you expect from an open source
> project.

You've identified the crux of the problem well:  LiveCode was never 
designed with modern FOSS methods in mind.   Indeed, it predates most 
modern FOSS workflows we take for granted today. This is one reason 
LiveCode Builder is being designed as it is.


But LiveCode Script remains very valuable for all the reasons we enjoy 
using it, and given that its nature is inherently incompatible with 
some aspects of current FOSS tools we have to invent alternatives to 
bridge the gap, things beyond what Github or any other off-the-shelf 
system could ever have anticipated.


I'll write more on that later today. I just had a very productive 
meeting with the team in which they raised this very issue and we 
brainstormed some options for handling it, and I look forward to 
sharing where we are with that as soon as I get some other emails out 
of the way.


Here, the dynamic you describe applies in both directions:

> When some people vent frustration over this, others on the list
> attack the messenger for the message.

Having read nearly every post on this list since its inception, I 
believe it's fair to say that conversations tend to go south when a 
post becomes more about presumption than productivity.


I believe pretty much every team member, and members of the community 
who enjoy using LiveCode, have all expressed very explicitly at one 
time or another that ALL discussions aimed at improving LiveCode are 
valuable, even when they involves criticism, noting the challenges 
involving the product or the usage experience.


When things become less productive here it's often through the use of 
unnecessarily emotion-laden terms, or making presumptions about 
others' intentions.  Sometimes these go as far as including implicit 
(and even occasionally explicit) suggestions of incompetence or 
duplicity.  It's rare in any conversation on any topic in any venue 
that any good can come of that.


If we all just wrote here the way we'd discuss things over a dinner 
table there'd be much work done accomplished and little in the way of 
uncomfortable feelings.


This list is about making software, using and improving LiveCode. 
Anything that helps improve either LiveCode or our use of it is not 
merely acceptable, but essential, and that includes open and frank 
discussion of ways to improve the LiveCode experience.


All members of this list should expect to be treated with 
professionalism and respect.  That includes all members of the 
community, and the core dev team as well.


If we see exceptions to that we should address them, and rather than 
make more noise here I'm happy to help with any grievance process that 
might help move things forward through private email if preferred.


Hopefully there will be little occasion for any grievance as long as 
we all treat one another with courtesy and respect.


We have much work to do, on our own projects and with LiveCode itself. 
Let's try to keep conversations focused on meaningful outcomes for 
those goals, and the rest will take care of itself.




> I think more work should be done to make this a true open source
> project.
> That is my opinion, and I don't expect LiveCode to listen to me.

You are the reason LiveCode exists.   A software is valuable to the 
degree that it satisfies its users.  Your presence, and the presence 
of the others here, makes LiveCode possible.


The ever-more-frequent posts from core team members suggests they're 
not only listening, but actively engaged.


A code base like LiveCode is complex stuff, and the process needed to 
make it happen no less so.  It takes all of us working together to 
pull it off.


My own modest contribution is to donate chunks of my time to help 
coordinate activities between the community and the core team. Where 
there's friction, or even just any lack of ease, that's among the 
things a good Community Manager will be available to help with 
whenever possible.


Later today I'll share some of the things I've been discussing with 
the core team on behalf of the community, but it needn't be limited to 
that.


Let's please 

Re: This Is Why We Can't Have Nice Things

[Mark Waddingham]

I should point out that my post was more a comment on the tone and purpose of 
some of the posts on the list rather than attempting to 'shoot the messenger'.

We know there is a problem with binary stackfile contributions... We have a 
process to enable such things but the changes have to be presented in form 
where someone internally applies them manually - we have good reasons for this 
as I have I explained.

We also have a very well defined development process in place as all software 
projects do - features go into the next major release, bug fixes into 
maintenance releases.

No open source project is a free for all - everything has to managed 
appropriately.

The 6 and 7 branches are in maintenance mode, the develop branch (to be 8) is 
where the next major release is being worked on and so where we merge all new 
features.

Indeed much of the work which has been done on 8 in the IDE is to improve the 
possibility of easy contributions (eg scriptified stacks).

Unfortunately we do not have a magic wand - we cannot just clap our hands and 
solve difficult problems overnight - of which binary stackfile merging is one.

Due to this situation we do offer and do indeed do the manual merging that is 
required, but you have to forgive us for perhaps trying to ensure we don't do 
the same work twice which is what back porting things generally requires.

Whilst it might appear we are being dogmatic, we are not. We are just trying to 
ensure that major versions appear as rapidly and at as high a quality as we can 
manage so everyone can benefit from the improvements they bring.

The advantages brought by getting to a release quality 8 are far in excess of 
any previous version we have delivered and thus it seems reasonable (to me at 
least) that that is where as much effort should go as possible.

Mark


Sent from my iPhone

> On 10 Sep 2015, at 17:02, Dirk prive  wrote:
> 
> I tend to stay quiet a lot, and prefer being silent on the side lines, but
> I have noticed that there is a difference between what was expected from an
> open sourced LiveCode and what is actually possible with the open source
> version of LiveCode.
> When people hear "open source", I think it is completely normal that they
> expect to read the source, make adjustments, and give them back to the
> project. This way the project can be improved by anyone that wants to help.
> That's how open source works generally.
> With LiveCode we apparently have binary stacks that can be edited, but the
> changes can't be merged back into the project.
> That completely goes against what you expect from an open source project.
> When some people vent frustration over this, others on the list attack the
> messenger for the message.
> I think more work should be done to make this a true open source project.
> That is my opinion, and I don't expect LiveCode to listen to me.
> I do think that it is important for an open source project to listen to the
> community (that's much bigger than me) though, and I feel that instead of
> listening to the community, opposing voices seem to be either ignored, or
> sometimes people even try to stifle the complaint/opposing opinion. Seems
> to me to exactly the opposite of what you need in an open source community.
> That aside, I don't even use the community version myself, preferring being
> able to keep my source to myself for commercial projects. Not that I've
> never open sourced things (if it is code that could be used by and be
> helpful to others), but I tend to open source certain parts, but almost
> never my whole project.
> 
> Just my two cents.
> Dirk Cleenwerck
> 
> 
> 
>> On Thu, Sep 10, 2015 at 11:04 AM, Mark Waddingham  wrote:
>> 
>>> On 2015-09-10 08:23, Richmond wrote:
>>> 
>>> Mark, "*flippant*" remarks often seem to hit nerves over at the
>>> mother-ship, lest you haven't noticed.
>> 
>> There's a difference between 'flippant' remarks and...
>> 
>> "Oh look what LiveCode have done now. How stupid is that. They obviously
>> don't know what there doing. I know far better."
>> 
>> Which is, to be frank, quite a frequent apparent subtext in a lot of your
>> posts :)
>> 
>> We could open a whole new thread about *intentionality* here . . .
>> 
>> And a whole new thread on ensuring that what you write actually comes
>> across how you intend (indeed, I think this has come up on the list before).
>> 
>> Mark.
>> 
>> --
>> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
>> LiveCode: Everyone can create apps
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 

Re: This Is Why We Can't Have Nice Things

[Dirk prive]

I tend to stay quiet a lot, and prefer being silent on the side lines, but
I have noticed that there is a difference between what was expected from an
open sourced LiveCode and what is actually possible with the open source
version of LiveCode.
When people hear "open source", I think it is completely normal that they
expect to read the source, make adjustments, and give them back to the
project. This way the project can be improved by anyone that wants to help.
That's how open source works generally.
With LiveCode we apparently have binary stacks that can be edited, but the
changes can't be merged back into the project.
That completely goes against what you expect from an open source project.
When some people vent frustration over this, others on the list attack the
messenger for the message.
I think more work should be done to make this a true open source project.
That is my opinion, and I don't expect LiveCode to listen to me.
I do think that it is important for an open source project to listen to the
community (that's much bigger than me) though, and I feel that instead of
listening to the community, opposing voices seem to be either ignored, or
sometimes people even try to stifle the complaint/opposing opinion. Seems
to me to exactly the opposite of what you need in an open source community.
That aside, I don't even use the community version myself, preferring being
able to keep my source to myself for commercial projects. Not that I've
never open sourced things (if it is code that could be used by and be
helpful to others), but I tend to open source certain parts, but almost
never my whole project.

Just my two cents.
Dirk Cleenwerck



On Thu, Sep 10, 2015 at 11:04 AM, Mark Waddingham  wrote:

> On 2015-09-10 08:23, Richmond wrote:
>
>> Mark, "*flippant*" remarks often seem to hit nerves over at the
>> mother-ship, lest you haven't noticed.
>>
>
> There's a difference between 'flippant' remarks and...
>
> "Oh look what LiveCode have done now. How stupid is that. They obviously
> don't know what there doing. I know far better."
>
> Which is, to be frank, quite a frequent apparent subtext in a lot of your
> posts :)
>
> We could open a whole new thread about *intentionality* here . . .
>>
>
> And a whole new thread on ensuring that what you write actually comes
> across how you intend (indeed, I think this has come up on the list before).
>
> Mark.
>
> --
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: This Is Why We Can't Have Nice Things

[Richard Gaskin]

Dirk prive wrote:

> I tend to stay quiet a lot, and prefer being silent on the side
> lines

...but when you finally did write here it was very valuable, so I hope 
you'll do so more often.



> but I have noticed that there is a difference between what was
> expected from an open sourced LiveCode and what is actually possible
> with the open source version of LiveCode.
> When people hear "open source", I think it is completely normal that
> they expect to read the source, make adjustments, and give them back
> to the project. This way the project can be improved by anyone that
> wants to help.
> That's how open source works generally.
> With LiveCode we apparently have binary stacks that can be edited,
> but the changes can't be merged back into the project.
> That completely goes against what you expect from an open source
> project.

You've identified the crux of the problem well:  LiveCode was never 
designed with modern FOSS methods in mind.   Indeed, it predates most 
modern FOSS workflows we take for granted today.  This is one reason 
LiveCode Builder is being designed as it is.


But LiveCode Script remains very valuable for all the reasons we enjoy 
using it, and given that its nature is inherently incompatible with some 
aspects of current FOSS tools we have to invent alternatives to bridge 
the gap, things beyond what Github or any other off-the-shelf system 
could ever have anticipated.


I'll write more on that later today. I just had a very productive 
meeting with the team in which they raised this very issue and we 
brainstormed some options for handling it, and I look forward to sharing 
where we are with that as soon as I get some other emails out of the way.


Here, the dynamic you describe applies in both directions:

> When some people vent frustration over this, others on the list
> attack the messenger for the message.

Having read nearly every post on this list since its inception, I 
believe it's fair to say that conversations tend to go south when a post 
becomes more about presumption than productivity.


I believe pretty much every team member, and members of the community 
who enjoy using LiveCode, have all expressed very explicitly at one time 
or another that ALL discussions aimed at improving LiveCode are 
valuable, even when they involves criticism, noting the challenges 
involving the product or the usage experience.


When things become less productive here it's often through the use of 
unnecessarily emotion-laden terms, or making presumptions about others' 
intentions.  Sometimes these go as far as including implicit (and even 
occasionally explicit) suggestions of incompetence or duplicity.  It's 
rare in any conversation on any topic in any venue that any good can 
come of that.


If we all just wrote here the way we'd discuss things over a dinner 
table there'd be much work done accomplished and little in the way of 
uncomfortable feelings.


This list is about making software, using and improving LiveCode. 
Anything that helps improve either LiveCode or our use of it is not 
merely acceptable, but essential, and that includes open and frank 
discussion of ways to improve the LiveCode experience.


All members of this list should expect to be treated with 
professionalism and respect.  That includes all members of the 
community, and the core dev team as well.


If we see exceptions to that we should address them, and rather than 
make more noise here I'm happy to help with any grievance process that 
might help move things forward through private email if preferred.


Hopefully there will be little occasion for any grievance as long as we 
all treat one another with courtesy and respect.


We have much work to do, on our own projects and with LiveCode itself. 
Let's try to keep conversations focused on meaningful outcomes for those 
goals, and the rest will take care of itself.




> I think more work should be done to make this a true open source
> project.
> That is my opinion, and I don't expect LiveCode to listen to me.

You are the reason LiveCode exists.   A software is valuable to the 
degree that it satisfies its users.  Your presence, and the presence of 
the others here, makes LiveCode possible.


The ever-more-frequent posts from core team members suggests they're not 
only listening, but actively engaged.


A code base like LiveCode is complex stuff, and the process needed to 
make it happen no less so.  It takes all of us working together to pull 
it off.


My own modest contribution is to donate chunks of my time to help 
coordinate activities between the community and the core team.  Where 
there's friction, or even just any lack of ease, that's among the things 
a good Community Manager will be available to help with whenever possible.


Later today I'll share some of the things I've been discussing with the 
core team on behalf of the community, but it needn't be limited to that.


Let's please continue to brainstorm here on this list any and 

Re: LiveCode and Yosemite

[Mark Waddingham]

Apologies - that should have been 'ageing' and 'fair'... Even though I've had 
an iPhone 6 for a year, I think my thumb still thinks it's an iPhone 5 in size!

Sent from my iPhone

> On 10 Sep 2015, at 18:53, Mark Waddingham  wrote:
> 
> Hi Devin,
> 
> I suspect you are being hit by the acing and non-maintained carbon nature of 
> pre 6.7. As Mac has evolved, carbon has become increasingly unstable - to be 
> far it was deprecated about 6 years ago!
> 
> I'd try in 6.7 first and see if that clears up the issues. If not file a bug 
> report or two :)
> 
> Mark
> 
> Sent from my iPhone
> 
>> On 10 Sep 2015, at 18:36, Devin Asay  wrote:
>> 
>> Hello all,
>> 
>> I recently switched both my main development station and my Mac labs to 
>> 10.10 Yosemite. I have noticed a couple of problems with LiveCode 
>> standalones, and I wonder if anyone here has noticed the same things on 
>> Yosemite.
>> 
>> - The initial connection to an online database tends to have a significant 
>> delay. Subsequent connections during the same session seem as fast as ever. 
>> I’m still trying to determine whether this problem is with LiveCode or with 
>> the server.
>> 
>> - I see screen flickering during the execution of visual effects or on 
>> buttons with various icon image states. For example on a button that has a 
>> “resting” icon and a hover icon there is some screen flickering on the 
>> button when I move my mouse cursor to it.
>> 
>> I should add that this is primarily with standalones built with LC 6.5 or 
>> earlier. I realize that I need to update these eventually, but I wonder, in 
>> light of these anomalies, if I need to accelerate that schedule?
>> 
>> Has anyone noticed similar things?
>> 
>> Thanks,
>> 
>> Devin
>> 
>> 
>> Devin Asay
>> Office of Digital Humanities
>> Brigham Young University
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LiveCode and Yosemite

[Devin Asay]

Thanks for the responses, Richard and Mark. I need to get over my reluctance to 
“rock the boat” on these older, but still working applications and just try a 
new build! I sometimes suffer from an overabundance of caution. :)

Regards,

Devin


> On Sep 10, 2015, at 11:56 AM, Richard Gaskin  
> wrote:
> 
> Devin Asay wrote:
> 
> > I’ve got a fair number of older, lower use standalone apps that
> > I don’t have time to update immediately, and was curious if anyone
> > else was seeing these problems. If I know what problems crop up
> > with older LC applications on newer OS’s that can help me
> > prioritize my update schedule.
> 
> LiveCode has a better history of backward compatibility than some other 
> languages (and many OSes ), so ideally updating the engine should be no 
> more work than choosing "Build Standalone" from the File menu.
> 
> If it turns out to be less than ideal, the sooner any issues are identified 
> the sooner a solid engine will be available for your app.
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

Devin Asay
Office of Digital Humanities
Brigham Young University

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LiveCode and Yosemite

[Mark Waddingham]

Hi Devin,

I suspect you are being hit by the acing and non-maintained carbon nature of 
pre 6.7. As Mac has evolved, carbon has become increasingly unstable - to be 
far it was deprecated about 6 years ago!

I'd try in 6.7 first and see if that clears up the issues. If not file a bug 
report or two :)

Mark

Sent from my iPhone

> On 10 Sep 2015, at 18:36, Devin Asay  wrote:
> 
> Hello all,
> 
> I recently switched both my main development station and my Mac labs to 10.10 
> Yosemite. I have noticed a couple of problems with LiveCode standalones, and 
> I wonder if anyone here has noticed the same things on Yosemite.
> 
> - The initial connection to an online database tends to have a significant 
> delay. Subsequent connections during the same session seem as fast as ever. 
> I’m still trying to determine whether this problem is with LiveCode or with 
> the server.
> 
> - I see screen flickering during the execution of visual effects or on 
> buttons with various icon image states. For example on a button that has a 
> “resting” icon and a hover icon there is some screen flickering on the button 
> when I move my mouse cursor to it.
> 
> I should add that this is primarily with standalones built with LC 6.5 or 
> earlier. I realize that I need to update these eventually, but I wonder, in 
> light of these anomalies, if I need to accelerate that schedule?
> 
> Has anyone noticed similar things?
> 
> Thanks,
> 
> Devin
> 
> 
> Devin Asay
> Office of Digital Humanities
> Brigham Young University
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LiveCode and Yosemite

[Devin Asay]

> On Sep 10, 2015, at 11:43 AM, Richard Gaskin  
> wrote:
> 
> Devin Asay wrote:
> 
> > I should add that this is primarily with standalones built with LC
> > 6.5 or earlier. I realize that I need to update these eventually,
> > but I wonder, in light of these anomalies, if I need to accelerate
> > that schedule?
> 
> Changes are ongoing, both in the OS and in LiveCode.  I always recommend that 
> whenever a problem is found with any earlier version that the recipe be 
> checked in the latest Stable build, or if available the latest Release 
> Candidate build.  At the moment that's 7.1rc2:
> 

Well, I know that of course, but I was hoping to stave off the inevitable for a 
while longer. :)

I’ve got a fair number of older, lower use standalone apps that I don’t have 
time to update immediately, and was curious if anyone else was seeing these 
problems. If I know what problems crop up with older LC applications on newer 
OS’s that can help me prioritize my update schedule.

Devin


Devin Asay
Office of Digital Humanities
Brigham Young University

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

LiveCode and Yosemite

[Devin Asay]

Hello all,

I recently switched both my main development station and my Mac labs to 10.10 
Yosemite. I have noticed a couple of problems with LiveCode standalones, and I 
wonder if anyone here has noticed the same things on Yosemite.

- The initial connection to an online database tends to have a significant 
delay. Subsequent connections during the same session seem as fast as ever. I’m 
still trying to determine whether this problem is with LiveCode or with the 
server.

- I see screen flickering during the execution of visual effects or on buttons 
with various icon image states. For example on a button that has a “resting” 
icon and a hover icon there is some screen flickering on the button when I move 
my mouse cursor to it.

I should add that this is primarily with standalones built with LC 6.5 or 
earlier. I realize that I need to update these eventually, but I wonder, in 
light of these anomalies, if I need to accelerate that schedule?

Has anyone noticed similar things?

Thanks,

Devin


Devin Asay
Office of Digital Humanities
Brigham Young University

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LiveCode and Yosemite

[Richard Gaskin]

Devin Asay wrote:

> I should add that this is primarily with standalones built with LC
> 6.5 or earlier. I realize that I need to update these eventually,
> but I wonder, in light of these anomalies, if I need to accelerate
> that schedule?

Changes are ongoing, both in the OS and in LiveCode.  I always recommend 
that whenever a problem is found with any earlier version that the 
recipe be checked in the latest Stable build, or if available the latest 
Release Candidate build.  At the moment that's 7.1rc2:



--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

How We Can Have Nice Things

[Richard Gaskin]

Yesterday I wrote that I'd report back on my meeting with the core team 
regarding community contributions on binary LiveCode stack files.  Many 
good things came out of that and other recent meetings, but in the 
interest of time let me focus on that one task here:



Why It's Been Difficult To Have Nice Things
---
To recap the story thus far, one of the things we enjoy about LiveCode 
is that it give us the freedom to make our own decisions about how (or 
even if) we separate code, data, and content.  LiveCode stack files are 
enormously flexible, and can be used for any of those three, or any 
combination of them, as we choose for the task at hand.


Part of what keeps us choosing LiveCode is that most alternatives treat 
UIs as an afterthought, usually completely separate from the core 
language and almost always in files separated from code.


This has resulted in a world where other people's version control 
systems only account for those common ways of working, unable to 
anticipate something as uniquely valuable as LiveCode.


With LiveCode being open source we need to bridge any gaps between the 
tools that are available and the work we need to do.




Most Things Can Be Made Very Nice Right Now
---
Fortunately, as Monte pointed out this afternoon, most of what we need 
to do is well supported by Github already, allowing the core team and 
the community to collaborate on everything in the engine and the docs, 
and most of the libraries in the IDE (thanks for assembling those stats, 
Monte):



For the remainder, most of what we need to do has been well covered by 
what we affectionately call the FIX Protocol:  if a community member can 
fix an IDE bug and provide the fixed handler in the bug report, just 
changing the report's summary to be prefixed with "FIX:" allows it to be 
identified easily, and since the solution is already provided it can 
usually be incorporated quickly.  So far I believe 100% of FIX 
contributions submitted through the bug DB have been folded into the 
product (thanks to Mike Kerner, Mark Wieder, and others who've provided 
those).


Between these two mechanisms (Github and the "FIX" protocol) I agree 
with Monte's assessment that more than 90% of what comprises the 
LiveCode product is readily available for community contributions right now.




The Handful of Things That Can Be Made Nicer
-
This still leaves us with a relatively small but sometimes very useful 
subset of enhancements not covered by either Github or simple FIXes in 
the bug DB.


The one that started this thread was Charles Warwick's generous 
contribution of a nice Script Editor enhancement to add filtering to the 
handler list.


The core team recognized the value in that right away, and added it to 
the Development branch for v8.0.


But since work on IDE UI elements must be done manually, given the long 
queue of other things we want them to do it isn't practical for them to 
do such manual work twice so it can also be available in v7.x.


These are fairly rare occurrences, but it would be nice if we had a way 
for the community to make such enhancements and have them available 
right in the product so everyone can enjoy them in later 7.x releases.


And that's where we come in:



How We Can Have Nice Things
---
As dev lead Mark Waddingham noted this morning, the main concern with 
accepting complex stack files like the Script Editor from outside 
sources is that the company has a responsibility to ensure fitness and 
security for all LiveCode users.   And being binary files, there's 
nothing in Github to support the key steps needed for all such 
contributions:


- IDENTIFY specific changes between a master stack file
  and a modified one.

- REVIEW those changes to ensure fitness, compatibility,
  and security.

- MERGE those changes into the master, if for some reason the
  master has been altered since the changes were submitted.

That last step, Merge, would be the most complicated, but thankfully it 
may not be needed at all if we used a sort of check-in/check-out 
procedure.  Rather than build some system for that just for the few 
cases it would be needed, since we're talking about an older branch than 
Development most of the time it's not undergoing internal changes 
anyway, so it should be easy to arrange to communicate when you want to 
change a file, and the team can simply do something else for a couple 
hours until you're done and send the modified version back to Github.


That leaves us to focus on the first two tasks: How do we identify 
specific changes between two stack files, and make it easy to review 
those changes?


If we can come up with a sufficiently useful tool to help with that, the 
team is quite willing to consider accepting some changes like 

Re: LiveCode and Yosemite

[Roger Guay]

I and a few others have seen this problem since the release of Yosemite.And, 
there’s been no improvement with any of the stable releases of LC.

Thanks,

Roger

> On Sep 10, 2015, at 10:36 AM, Devin Asay  wrote:
> 
> - I see screen flickering during the execution of visual effects or on 
> buttons with various icon image states. For example on a button that has a 
> “resting” icon and a hover icon there is some screen flickering on the button 
> when I move my mouse cursor to it.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: This Is Why We Can't Have Nice Things

[Mark Wieder]

On 09/10/2015 02:18 PM, Monte Goulding wrote:


there’s roughly 99% of the repo files we can freely contribute to


Well, yes and no. Not all of us have the requisite C programming skills 
to read through, decipher, compile and add to the engine files, which 
are the majority of those files.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: This Is Why We Can't Have Nice Things

[Mark Wieder]

On 09/10/2015 12:39 AM, Mark Waddingham wrote:


I do wonder if a GitHub hook could be used here. Peter's done some great
things with them in terms of PR review, CLA checking and CI via our
'vulcanbot' build system.

If PRs which contain stacks were monitored by vulcan, it might be able
to pick up when they aren't going to merge due to binary reasons and
provide a link to a page which shows the diff so at least the review
process could start and provide feedback to the submitter. It would
still be a chunk of work to integrate such things (as if the target
stack had changed since the submitted stack was modified, you can't just
copy the submitted one over the target one) but at the very least that
would give a list of changes that need to be applied.


That's an interesting idea.
I wonder if it might make sense in that case to ask that pull requests 
not have more than x binary (non-script) changes or this might easily 
get to be an overwhelming task.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Embeded LiveCode -- a distant dream that is dead???

[Richard Gaskin]

Mark Rauterkus wrote:

> With v8 and beyond, is there any Embeded LiveCode in the future or
> is that vision terminated?

The embeddable engine has pretty specialized application - what are you 
working on?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: BBEdit/Textwrangler LCM for livescript

[Kay C Lan]

Thanks James, excellent work.

On Thu, Sep 10, 2015 at 10:35 PM, jameshale  wrote:

> Updated livecodeBuilder CLM to adjust function regex so that function names
> appear in BBEdit's function popup
>
> https://dl.dropboxusercontent.com/u/8212901/LiveCodeBuilder.plist
> 
>
> James
>
>
>
> --
> View this message in context:
> http://runtime-revolution.278305.n4.nabble.com/BBEdit-Textwrangler-LCM-for-livescript-tp4696091p4696217.html
> Sent from the Revolution - User mailing list archive at Nabble.com.
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LiveCode and Yosemite

[Peter Bogdanoff]

I see something similar in LC 7, including 7.1 dp 2, in IDE.

I see flickering as the mouse moves over a field which sets the background 
color of the line:

on mouseMove
   if the mouseLine is not empty then
  set the backgroundColor of the mouseLine() to 235,231,237
   end if
end mouseMove


Peter Bogdanoff
UCLA



> On Sep 10, 2015, at 7:01 PM, Roger Guay  wrote:
> 
> I and a few others have seen this problem since the release of Yosemite.And, 
> there’s been no improvement with any of the stable releases of LC.
> 
> Thanks,
> 
> Roger
> 
>> On Sep 10, 2015, at 10:36 AM, Devin Asay  wrote:
>> 
>> - I see screen flickering during the execution of visual effects or on 
>> buttons with various icon image states. For example on a button that has a 
>> “resting” icon and a hover icon there is some screen flickering on the 
>> button when I move my mouse cursor to it.
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: How We Can Have Nice Things

[Monte Goulding]

> On 11 Sep 2015, at 11:40 am, Richard Gaskin  
> wrote:
> 
> Anyone here interested in contributing to such a tool?

You could use lcVCS but you highlighted an issue before with the 5000+ changes 
for the handler filter. The problem is most of those changes were because the 
stack was resized or some other setting was changed and resizeStack handlers 
were run causing lots of objects to be updated. Other changes might be custom 
property guff that the IDE adds to the stacks. In lcVCS I handle all this stuff 
via scripts that reset things to defaults. However this means in order to start 
doing this someone needs to write those lcVCSExport handlers… 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Audio Delivery to Multiple Platforms

[Brahmanathaswami]

I posted this to the forums, but no replies

We want to deploy .mp3 file via standalones on all platforms.

I can't imagine that no one isn't doing this already.

Can you post a sample snippet?

I presume we need to test for each platform and then use a different 
method. I don't really need a controller, just allow the users to stop 
and star the audio... that would suffice.


in 7.1 RC1

play audioClip "someAudio.mp3"  # fails ... nothing but noise

setting "dontUseQT" to true and creating a player and assigning the file 
name works... so at least we are no longer dependent on QT... as I think 
the player is using the AVFoundation now...


But what about Windows, Android mobile and iOS.

If you have this done already, it would save me re-inventing the wheel. 
There are enough of our audience that will not have a smart phone, that 
I'll need to deploy this little app/audio module for desktop as well as 
for mobile.



Swasti Astu, Be Well!
Brahmanathaswami

Kauai's Hindu Monastery
www.HimalayanAcademy.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: How We Can Have Nice Things

[Kay C Lan]

I'll admit I don't fully understand all the ins and outs and the full
ramifications of how many straws are being piled on the LC Teams back, but
if the problem is binary vs text may not the simple solution be to shift
some of the weight back on the contributor to make it easier for the Team,
ie instead of just supply the amended stack, actually list out the amended
handlers, the added handlers, the amended objects and the added objects.

I'm thinking some sort of Template Form similar to what the QCC uses to
enter bugs.

A field to enter the full name of the effected script:

>The stack script of stack revscripteditor.rev

A field to enter the original hander,

>on extractHandlerNames
>...
>...
>end extractHandlerNames

A field to enter your amended handler.

>on extractHandlerNames
>...
>amended bits sprinkled throughout
>...
>end extractHandlerNames

[Makes it easy to copy and paste into a Text Editor for diff analysis]

Repeat above for as many handlers you've amended.

A field for entering Added handlers.

>on filterHandlerNames
>...
>...
>end filterHandlerNames

Repeat above for all your added handlers.

A field to enter the full name of any object you've amended

>Field 'handlerlist' of stack revscriptEditor.rev

A field to enter the original properties:
>height: 500
>loc: 60,250
[just the relevant ones]

A field to enter the amended values

>height: 480
>loc: 60,240

Repeat above until all amended objects are listed

A field to enter the full name of any object you've Added:

>Field 'filterHandlerList' of stack revscriptEditor.rev

A field to enter the properties of the new object which aren't default:

>height: 20
>width: 120
>Loc: 60, 490
>...
>...

Repeat as above for all added objects

Provide the recipe [text] for the cake, not just the cake [binary].

I guess Charles would be the one to comment on how difficult it would have
been for him to list out all the original
scripts/handlers/objects/properties he amended, along with the actual
amendments he made PLUS all the scripts/handlers/objects/properties he
added. If he considers it difficult and a deterrent to community additions
then it would certainly add weight to the comments that it is a burden for
the LC Team. If Charles considers it easy, then maybe it would help?

If the LC Team follow your recipe, but don't get the cake you sent, then
the contribution is rejected until you identify the amendments/additions
you made that were not correctly reported in your original submission.
Again placing the burden on the contributor not the LC team. In fact I
would suggest initially posting such recipes to the community:

1) so they can be checked by the community and no LC Team time is wasted.
2) because the community is sure to spot 1 or 2 improvements/enhancements
that can be added prior to submission.
3) certain Community members could be considered Quality Assurance Reps
(CQAR), and if they have built the recipe and confirmed it works, checked
the amendments/additions to confirm nothing nefarious exists, then rather
than the original author submitting the work, it's submitted by the CQAR
(Richard, Marks, Jacque, Monte...) which would reduce the amount of
checking the LC Team would need to do.

Maybe not so much a tool as you requested but a workflow.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: This Is Why We Can't Have Nice Things

[Monte Goulding]

> On 11 Sep 2015, at 2:59 am, Richard Gaskin  wrote:
> 
> You've identified the crux of the problem well:  LiveCode was never designed 
> with modern FOSS methods in mind.   Indeed, it predates most modern FOSS 
> workflows we take for granted today.  This is one reason LiveCode Builder is 
> being designed as it is.


Hey guys. Just to keep the discussion in a bit of perspective with regard to 
whether we are able to contribute to LiveCode I did some file counts. 

This counts the total number of files in the repo skipping those in the git 
directory
find . -not \( -path ./.git -prune \) -type f | wc -l
   20227

These two counts summed are the files we are worried about although I know 
there’s some files with the .rev extension that are actually plain text. Not 
sure how that came about...
find . -name "*.rev" | wc -l
 145
 find . -name "*.livecode" | wc -l
  56

Here’s the docs
find . -name "*.lcdoc" | wc -l
2611

And here’s the libraries written in LiveCode Script that you can contribute to
find . -name "*.livecodescript" | wc -l
  91

LiveCode Builder anyone?
find . -name "*.lcb" | wc -l
  61

Now given these counts and ignoring some other binaries counted in the repo 
count there’s roughly 99% of the repo files we can freely contribute to without 
encountering these issues. The 2611 lcdocs files that are very easy to write 
and maintain would be a good start. The livecodescript files are an obvious 
target and for the more adventurous there’s lcb to do something with.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: iOS9, AppleTV OS, WatchOS 2

[Richmond]

On 09/09/2015 11:25 PM, Roger Eller wrote:

On Wed, Sep 9, 2015 at 4:02 PM, Stephen MacLean 
wrote:


I mention this most every time after an Apple event, but it’s becoming
more and more relevant each time… LiveCode support?

How ready is LC for iOS9? It’s coming in a week. iOS 8 broke a lot of my
stuff, would have been nice to be able to test ahead of time.

AppleTV OS. New, based on iOS. Will there be support for it?

WatchOS 2. Now supports native apps. Will LC now support it? LCB only
style app?

This isn’t an Apple Vs. Android argument, everyone has their own opinions
and stats. It’s about new, relevant products and bringing your apps to
those products.

LiveCode’s write once - deploy anywhere model makes it desirable. Knowing
about support for these products makes decisions actionable.

Best,

Steve MacLean



Since you mention these things while the event is still warm, I'll throw in
my wishes for more mobile OS parity.

Windows 8.1 tablets/phones … LiveCode support?
Android 5.1 … LiveCode support?
Android Wear … LiveCode support?
Android Wear 2 … LiveCode support?
Build as an Android Widget … LiveCode support?
Android Auto … LiveCode support?


This isn’t an Apple Vs. Android argument...

No it's not.  But we need to be able to build for the sub-technologies of
Android in addition to just phones.


And it isn't a two-handed argument either; I started wondering about the 
Ubuntu hand-held devices . . .


http://www.ubuntu.com/phone




LiveCode’s write once - deploy anywhere model makes it desirable.


This has, almost always, been slightly inaccurate, and stacks sometimes 
need tweaking

to function and/or look appropriate on different platforms.


Knowing about support for these products makes decisions actionable.

Agreed.

~Roger
___



Richmond.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: This Is Why We Can't Have Nice Things

[Richmond]

On 09/10/2015 04:28 AM, Mark Wieder wrote:

On 09/09/2015 12:06 AM, Ali Lloyd wrote:

I'm sorry you felt it was passive-aggressively not accepted. It was 
meant

neither as passive-agressively , nor  not accepted.


Well, that was intended to be a flippant remark, the the posting 
subject should have reinforced that.

Seems like I struck a nerve.
I was referring to the fact that my pull request wasn't rejected, but 
it also was placed in a we're-not-going-to-accept-this category.
See my further comments to Mark's post, but otherwise my apology for 
the unintended slight.




Mark, "*flippant*" remarks often seem to hit nerves over at the 
mother-ship, lest you haven't noticed.


We could open a whole new thread about *intentionality* here . . .

Richmond.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: site scraper

[Simon Smith]

Hi

You could try - https://import.io/

Simon

On Thu, Sep 10, 2015 at 4:35 AM, Mike Kerner 
wrote:

> anyone write a site scraper?  Feel like sharing it so I don't have to write
> it?
>
> --
> 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
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 

Carpe diem

*Simon Smith*
m. +27 83 306 7862
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LiveCode and Yosemite

[Richard Gaskin]

Devin Asay wrote:

> I’ve got a fair number of older, lower use standalone apps that
> I don’t have time to update immediately, and was curious if anyone
> else was seeing these problems. If I know what problems crop up
> with older LC applications on newer OS’s that can help me
> prioritize my update schedule.

LiveCode has a better history of backward compatibility than some other 
languages (and many OSes ), so ideally updating the engine should be 
no more work than choosing "Build Standalone" from the File menu.


If it turns out to be less than ideal, the sooner any issues are 
identified the sooner a solid engine will be available for your app.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode