Re: LC7 and 8 - Non responsive processing large text files

2016-04-13 Thread Monte Goulding

> On 14 Apr 2016, at 3:25 PM, Mark Talluto  wrote:
> 
>> But reading something into memory using "read from file  UNTIL
>> " and doing this many times over in such large text file creates
>> non-responsiveness of LC (tested on 7 and 8).

It would be interesting to know if the engine were doing lots of encoding 
conversions in order to test for the string. I must have missed the first email 
but I’d be interested to know if the file was opened for text or binary read 
and if an encoding was provided in the command if it was text. If it was binary 
is performance any better if the until  a variable with the same 
encoding as the binary file? The other thing worth pointing out is if you are 
doing a text read on an 8 bit encoding the size of your data doubles once read 
because each character is represented by 16 bits. When you consider the amount 
of data we are talking about here that will cause a serious slowdown.

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: Volunteer github guru for documentation submissions?

2016-04-13 Thread Kay C Lan
Don't you hate it when you hit Send and immediately realise there is a
simpler solution. Don't need to ask for your fork name, I can just use the /
livecode/livecode/ fork to demonstrate the same thing:

on mouseUp
   put the htmltext of widget 1 of stack "revDictionary" into tText
   filter lines of tText with "**"
   get matchText(tText,".+>(.+?)",tName)
   replace " " with "-" in tName
   get matchText(tText,">type

Re: Volunteer github guru for documentation submissions?

2016-04-13 Thread Kay C Lan
On Thu, Apr 14, 2016 at 11:57 AM, Monte Goulding  wrote:

>
> That sounds complicated.


Getting to Heaven is never going to be easy... especially when it's my LC
Heaven ;-)

>
>  I’m not sure if it is easy to determine which doc is currently being
> viewed in the dictionary.
>

When I visit the LC Community Docs via the Web interface the URL always
start with:

https://github.com/lan-kc/livecode/

where 'lan-kc' is my fork name. If you enter in whatever your fork name is
when you run this script it should display in your browser the lcdoc of
whatever is currently showing in your Dictionary. Obviously this is just a
proof of concept and it wont work for EVERY entry, especially those Entry
names that have special characters - $, #, < etc that need encoding, or any
Glossary entries - but I think you'll agree that those are not
insurmountable.

on mouseUp
   put the htmltext of widget 1 of stack "revDictionary" into tText
   filter lines of tText with "**"
   get matchText(tText,".+>(.+?)",tName)
   replace " " with "-" in tName
   get matchText(tText,">type

Re: Bugs in 8.0.0 RC1 and trying to convince a colleague that LC is *not* flaky

2016-04-13 Thread RM
Well, I'm not going to show anything like 8.0.0 to "Steve": I'll either 
show him the latest of the 7 series

or wait until about 8.1.

As far as I can see "8" is so radically different to "7" that expecting 
8.0.0 to be stable is extremely unwise.


There are 2 schools of thought:

1. Too much too quickly.

2. Patience and a lot of community effort in find bugs will be well 
rewarded.


I'm at about 1.8.

However, I talk to my teddy bear (Henry), and not to my imaginary fried 
(Steve).


Richmond.


On 14.04.2016 01:18, RunRevPlanet wrote:

I know these are not show stoppers, but I suspect that bugs 15963 and 15964 will
both be present in the final 8.0.0 build, whenever that may be.

I understand that everyone has their favourite problem that needs fixing. And I
understand that the LiveCode team has worked, and is working very hard, but I
have a problem named Steve.

Steve, (a programming colleague) to whom I sing the praises of LiveCode to,
knows of these bugs. Unfortunately, I expect that when I ask him to give
LiveCode another try, when version 8.0.X has a "stable" release, the following
will happen.

He is going to download it. Open the script editor and search for some text that
doesn't exist and turn to me with a big grin and say, "Ha! This issue still
exists. You want me to have confidence in a tool when a command in the IDE can
be so easily broken?"

I love LiveCode and can live with an irritation like this. (And if you are
thinking, why are you searching for text that doesn't exist, it is quite easy to
accidentally do when refactoring code with many Script Editor tabs open.)

But for Steve, it makes him think that LiveCode is flaky.

--
Scott McDonald
"Components, Controls, Tools and Resources for LiveCode"
www.runrevplanet.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: LC7 and 8 - Non responsive processing large text files

2016-04-13 Thread Mark Talluto

> On Apr 13, 2016, at 3:03 AM, Roland Huettmann  
> wrote:

…snip
> But reading something into memory using "read from file  UNTIL
> " and doing this many times over in such large text file creates
> non-responsiveness of LC (tested on 7 and 8).
> 
> So, what do I do?
> 
> One more note: Additionally I find that it can take significant delays when
> placing large blocks of text into a field. Is there an idea of improving
> this?

Hi Roland,

This is more of a curiosity than a solution. What happens if you run your code 
in LC version 6? Do you still see the same timing issues? 

Version 7/8 are slower than version 6 in almost every way. Here are a couple of 
bug reports on the issue:

http://quality.livecode.com/show_bug.cgi?id=16387 

http://quality.livecode.com/show_bug.cgi?id=15711 


There are others out there. The team has been trying to make LC 8 more 
performant though. So our reports are being worked on.

Best regards,

Mark Talluto
livecloud.io 
canelasoftware.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: Volunteer github guru for documentation submissions?

2016-04-13 Thread Scott Rossi
I'm a GitHub novice, but I've used this with another client (OS X):
https://desktop.github.com/


Not sure I have it pointed at the right directory,  but I see a bunch of
pull requests from livecodeali and peter-b.

:-)

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 4/13/16, 3:44 PM, "use-livecode on behalf of Alex Tweedly"

wrote:

>Which do you recommend?
>If it's a git gui - any favourite(s) ?



___
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: Bugs in 8.0.0 RC1 and trying to convince a colleague that LC is *not* flaky

2016-04-13 Thread Monte Goulding
Hi Scott

I feel ya… we all have Steve's

I’ve worked out a fix for this but as you have probably already determined 
there will be resistance to including any non-critical bugfix in LC 8 now. The 
good news is I can submit a PR today that will be merged into 8.0.1 so don’t 
poke Steve until that’s released ok.

Cheers

Monte

> On 14 Apr 2016, at 8:18 AM, RunRevPlanet  wrote:
> 
> I know these are not show stoppers, but I suspect that bugs 15963 and 15964 
> will
> both be present in the final 8.0.0 build, whenever that may be.
> 
> I understand that everyone has their favourite problem that needs fixing. And 
> I
> understand that the LiveCode team has worked, and is working very hard, but I
> have a problem named Steve.
> 
> Steve, (a programming colleague) to whom I sing the praises of LiveCode to,
> knows of these bugs. Unfortunately, I expect that when I ask him to give
> LiveCode another try, when version 8.0.X has a "stable" release, the following
> will happen.
> 
> He is going to download it. Open the script editor and search for some text 
> that
> doesn't exist and turn to me with a big grin and say, "Ha! This issue still
> exists. You want me to have confidence in a tool when a command in the IDE can
> be so easily broken?"
> 
> I love LiveCode and can live with an irritation like this. (And if you are
> thinking, why are you searching for text that doesn't exist, it is quite easy 
> to
> accidentally do when refactoring code with many Script Editor tabs open.)
> 
> But for Steve, it makes him think that LiveCode is flaky.
> 
> --
> Scott McDonald
> "Components, Controls, Tools and Resources for LiveCode"
> www.runrevplanet.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: Volunteer github guru for documentation submissions?

2016-04-13 Thread Monte Goulding
> In the LC Dictionary you notice an error
> There is an Edit button to click on
> It retrieves the appropriate lcdoc file from the correct GitHub Branch

So here you could be opening a lcdoc file that is different to the one you 
noticed an error on which could be confusing but probably isn’t a deal breaker.

> It opens in a separate stack - an lcdoc Editor
> It opens in default WYSIWYG mode.

That sounds complicated. Some kind of split screen would be significantly 
simpler to implement and docs contributors really need to understand the lcdoc 
format because if there is an issue with a PR the comments will be against 
lcdoc lines which raises the point that such a system will need to allow you to 
go back and edit your changes further.

> You have a Submit button
> It creates the GitHub PR for you.

So we are missing some steps at the start here where you setup your clone and 
account on GitHub, a local repository is setup pointing to your clone and the 
upstream livecode repo and the GH account and api privileges are setup 
correctly but if that’s all done right then the GitHub API will allow this.

This can all be done as a plugin I think although I’m not sure if it is easy to 
determine which doc is currently being viewed in the dictionary.

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: Plugins vs. the Mac app bundle

2016-04-13 Thread Paul Hibbert

> On Apr 13, 2016, at 9:57 AM, Richard Gaskin  
> wrote:
> 
> If you want to share your code here I'll bet we can pin down which part 
> triggers the "dirty" flag.
> 
> Since you've already scripted your changes, having them run in a plugin on 
> startup rather than attempting to alter the bundle contents will make 
> everything work well, once we take care of that save prompt.
> 
> But I know it's doable:  my devolution plugin makes a lot of changes to 
> revMenubar on startup, and I've not seen a save prompt yet.  I'll bet we can 
> figure out how to tailor your script to do the same.


Thank you for the prompt Richard,

After reading your reply I went through the stack I was using and realized that 
I was writing the changes back to the stack in the app bundle, which I think is 
why it was setting the revMenuBar stack as dirty, when I changed it to just 
updating the stack in memory everything is working fine now. I took the 
opportunity to clean up the script and made it into a new plugin and so far I’m 
happy with the result and no need to alter the app bundle permissions.

Thank you once again for the help pointing me in the right direction.

Kind Regards,

Paul
___
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: 8.0.0 RC1 - Which Xcode Version?

2016-04-13 Thread Sannyasin Brahmanathaswami
Thanks

I tried to kick myself, but knees are a little stiff: (smile)

Repeat after me 20 times:

“read the release notes, read the release notes, read the release notes….”

OK I got it now

Xcode 7.3 it is.


BR






On 4/13/16, 10:41 AM, "use-livecode on behalf of panagiotis merakos" 
 wrote:

>Taken from the Release Notes, page 6:
>http://downloads.livecode.com/livecode/8_0_0/LiveCodeNotes-8_0_0_rc_1.pdf
___
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: Volunteer github guru for documentation submissions?

2016-04-13 Thread Kay C Lan
On Thu, Apr 14, 2016 at 8:45 AM, Monte Goulding  wrote:

>
> There’s no productivity gains in using a LC docs specific git gui only a
> slightly reduced learning curve.


I my LC Heaven there would be both :-)

In the LC Dictionary you notice an error
There is an Edit button to click on
It retrieves the appropriate lcdoc file from the correct GitHub Branch
It opens in a separate stack - an lcdoc Editor
It opens in default WYSIWYG mode.
You type in your correction/addition.
Because LC knows ALL it's own keywords (commands, objects, etc) it can
automatically reference them
If you type in any ambiguous references it can ask which one you meant (and
markup accordingly)
You change to Check mode - where clicking around will cause the Dictionary
to open at the appropriate Entry
  - if clicking on a recently added word doesn't work or takes you to the
wrong Entry
You have Raw mode - because sometimes WYSIWYG doesn't get it right and you
just have to do the markup yourself.
Back to Check mode to confirm your Raw changes work.
If you type in an Example: - it can be colour coded - so less likely to
make a mistake
In Compile mode you can check that each Example: wont return a error, and
any result is placed in msg
You have a Submit button
It creates the GitHub PR for you.
The lcdoc Editor Stack vanishes and you continue to productively code away.

But I'm sure a reduced learning curve would be paradise for many ;-)
___
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: Indy Licensing

2016-04-13 Thread Robert Mann

maybe that  this 

Licensing questions are off-topic for this mailing list -- but our 
support team at [hidden email] would be delighted to answer your 
question. 

should be read as :

*Personnal licensing questions* are off-topic for this mailing list -- but
our 
support team at [hidden email] would be delighted to answer your 
question. 

This would be better understandable...
otherwise, one should enquire on the policy here, who does it? 
do users have some right to decide what is on or off list here?
i wonder!






--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Indy-Licensing-tp4703428p4703464.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: Volunteer github guru for documentation submissions?

2016-04-13 Thread Monte Goulding

> On 14 Apr 2016, at 9:53 AM, Kay C Lan  wrote:
> 
> You could say exactly the same thing about LiveCode users. Why hide
> ourselves from C or C++, they exist and 'almost' everyone else is using
> them?

Maybe you could say that but there’s clear productivity gains for using 
LiveCode. There’s no productivity gains in using a LC docs specific git gui 
only a slightly reduced learning curve. But hey if someone wants to do it 
there’s nothing stopping them.

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: Anyone have any LiveCode hooks to WordPress? And, are you following these Word Camp events

2016-04-13 Thread stephen barncard
Livecode server pages can always be shown via another (PHP) page using
iFrames in the html code

Stephen Barncard - Sebastopol Ca. USA -
mixstream.org

On Wed, Apr 13, 2016 at 11:38 AM, Mark Rauterkus 
wrote:

> Hi,
>
> These Word Camp events might be a great way to share some of the love for
> LiveCode, if you are a blogger and using WordPress, especially.
>
>
> https://2016.pittsburgh.wordcamp.org/
>
>
> I just went to my first a week long Steel City CodeFest in my town. Fun. No
> LiveCode. But next year, we'll gear up with some teams, I expect.
>
> Most of the show off stuff at CodeFest was only prototype stuff.
>
>
> --
> Ta.
>
>
> Mark Rauterkus   m...@rauterkus.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: Volunteer github guru for documentation submissions?

2016-04-13 Thread Kay C Lan
On Thu, Apr 14, 2016 at 6:13 AM, Monte Goulding  wrote:

>
> I’ve thought about this and yes it would be feasible to do however there
> are two things we know exist:
>  - good git gui’s - I like and often use SourceTree which is available for
> Windows and Mac
>  - good text editors - I use Atom these days
> 
> In the end I think our community will benefit from not creating our own
> thing to hide ourselves from using tools that almost everyone else on other
> platforms are using.


You could say exactly the same thing about LiveCode users. Why hide
ourselves from C or C++, they exist and 'almost' everyone else is using
them?

The fact is a git gui is a realisation that a gui is a better way to
interact with git than the command line. Yes some people like the command
line but plenty don't. SourceTree is not the only git gui in town, there
are many many others; if someone one was to make an LC Doc Git Gui, it
would just be another in an ever growing number of attempts to make git
easier.

And as I think you've realised, if we go down the git gui & text editor
path, now you have the trouble of writing Guides to support that. So it's
SourceTree, what about the Linux users, will there be a completely
different set of Guides for them and their gui? What if my preferred tool
is Eclipse which is both a text editor with a Git Gui interface extension?
Which team member is going to support those who choose a different tool set
up?

Now I tend to agree that spending time creating a LC Doc Git Interface may
not be time well spent; so given that many here are Objective-C adverse and
Gitphobic,  we know that the web interface works, and for noobs, means we
are all in the same boat - give or take browser differences - I can see
that it's the time LEAST spent by the Team to tweak the Web Guide and
support Web interaction for Doc ONLY contributions.

I can appreciate, for those who aren't adverse the many flavours of C and
wish to contribute to the Engine, the you'll already have your favourite
text editor and probably should be looking at a good Git Gui.
___
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: Volunteer github guru for documentation submissions?

2016-04-13 Thread Monte Goulding

> On 14 Apr 2016, at 8:44 AM, Alex Tweedly  wrote:
> 
> 
> 
> On 13/04/2016 22:45, Monte Goulding wrote:
>> GitHub <> git and you are using GitHub which has hacked on a web interface 
>> for working on stuff. I honestly think that if folks spent the same amount 
>> of time working out the web interface as working out how to use git locally 
>> using a good git gui then they would be finding things much simpler. The 
>> main issue is locally you need to actively switch branches so you always 
>> know where you are but on the web it is much easier to jump between branches 
>> and get confused.
> Monte, I'm probably just caffeine-deprived,

You and me both ;-)

> but I have trouble parsing that first sentence.

Sorry, hopefully my comments below will clarify

> I *think* you're recommending using a git gui, and not using the web 
> interface - but it could be just the inverse.

Yes, I think a good git gui would be about the same size learning curve but the 
end result would be a much faster and easier to understand procedure.
> 
> Which do you recommend?
> If it's a git gui - any favourite(s) ?

SourceTree sourcetreeapp.com for Windows and Mac.

> 
> Being old-fashioned, I started with the command-line interface :-) But even 
> then, Ali's document switched into the web interface at a couple of crucial 
> points.

If you are comfortable on the command line I would stay there as there’s stuff 
you can do on the command line that no git-gui will do for you. I tend to jump 
back and forth because I like to use the gui for more of an overview of what’s 
going on in the repo. I’m suggesting this more for folks struggling with the 
web interface. Yes you will need to use GitHubs UI to send a patch for review.
> 
> I do think there are some errors or omissions in the "git gui" section of his 
> document, but I don't know enough to be sure, far less to fix them ….

The biggest issue i see with it is there’s no upstream remote setup which is 
required in order to fetch changes that have been merged into the main repo but 
push changes to your fork. Probably the reason for this is unless the document 
talks specifically about a single git gui (possibly not a bad idea) then the 
process for adding a remote will be different. Alternatively we could just 
steal the command line from the command line section.
> 
> For example
>> 
>> Make sure both the docs change and the bugfix note are ready for commit in 
>> the GUI client.
>> 
>> In the summary and description section,
>> 
>> The title should be along the lines of
>> 
> 
> and later ...
>> 
>> Click commit to
>> 
>> Then click "Submit pull request"
>> 
> 
>> There is a way for others to work on things together and given that’s the 
>> point of git that’s a good thing! The way to do it is to go to your patch-4 
>> branch, edit and then submit a PR to you which you then incorporate and 
>> which would reflect the changes in your PR. In the past I have sent PRs to 
>> branches on other people’s forks on the team and had team members send PRs 
>> to my branches that I have had in review.
>> 
> What's a "patch-4 branch" ?
> I've only got as far as submitting a couple of trivial changes - but I'm 
> pretty sure I didn't have a patch-4 branch ?

OK, sorry for the confusion. This was specifically targeting Mike’s patch to 
the send command docs which on his fork github.com/macmikey/livecode is in a 
branch named patch-4. To do what I was suggesting on a git gui or command line 
you would add his fork as a remote, checkout the patch-4 branch, make a change, 
push to your fork then send a PR to his fork. This isn’t a normal part of the 
contribution process so I wouldn’t worry about it for now I just wanted to 
clarify that yes, people can collaborate outside the normal PR review process 
and their work can be combined into the one PR submitted to the team.


___
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: Volunteer github guru for documentation submissions?

2016-04-13 Thread Kay C Lan
On Thu, Apr 14, 2016 at 4:30 AM, Devin Asay  wrote:

>
> - A markdown previewer. I know Ali made a stab at this, but I wasn't able
> to get it to work.
>

Do you have Ali's latest version of the preview.livecode stack? Sorry I
tried to find a link to it but I can only find one to the previous version.

You know if you have the latest version if;

1) after clicking the 'Preview' button,
2) after it opens the webpage in your Browser which looks like the
Dictionary,
3) within the 'hits' field at the top there are two entries:
a) the top one 'click me first',and
b) the one below will be the name of the lcdoc you are amending
4) Click on 'Click me first'
5) Then click on the line below which is the name of the lcdoc you are
amending.

If you do not have the 'click me first' line then you have an earlier
version of the preview.livecode stack. Might need to ask Ali to post a link.

If that is still not working for you have you tried another Browser?

Works (with known issues) for me on OS X 10.9.5 with Firefox >= 42.x
___
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: Volunteer github guru for documentation submissions?

2016-04-13 Thread Alex Tweedly



On 13/04/2016 22:45, Monte Goulding wrote:

GitHub <> git and you are using GitHub which has hacked on a web interface for 
working on stuff. I honestly think that if folks spent the same amount of time 
working out the web interface as working out how to use git locally using a good git 
gui then they would be finding things much simpler. The main issue is locally you 
need to actively switch branches so you always know where you are but on the web it 
is much easier to jump between branches and get confused.
Monte, I'm probably just caffeine-deprived, but I have trouble parsing 
that first sentence.
I *think* you're recommending using a git gui, and not using the web 
interface - but it could be just the inverse.


Which do you recommend?
If it's a git gui - any favourite(s) ?

Being old-fashioned, I started with the command-line interface :-) But 
even then, Ali's document switched into the web interface at a couple of 
crucial points.


I do think there are some errors or omissions in the "git gui" section 
of his document, but I don't know enough to be sure, far less to fix 
them 


For example


Make sure both the docs change and the bugfix note are ready for 
commit in the GUI client.


In the summary and description section,

The title should be along the lines of



and later ...


Click commit to

Then click "Submit pull request"




There is a way for others to work on things together and given that’s the point 
of git that’s a good thing! The way to do it is to go to your patch-4 branch, 
edit and then submit a PR to you which you then incorporate and which would 
reflect the changes in your PR. In the past I have sent PRs to branches on 
other people’s forks on the team and had team members send PRs to my branches 
that I have had in review.


What's a "patch-4 branch" ?
I've only got as far as submitting a couple of trivial changes - but I'm 
pretty sure I didn't have a patch-4 branch ?



-- Alex.
P.S. I'm really struggling to avoid being a grumpy old man and saying 
"it's all been downhill since we switched from SCCS to RCS" :-)


___
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

Bugs in 8.0.0 RC1 and trying to convince a colleague that LC is *not* flaky

2016-04-13 Thread RunRevPlanet
I know these are not show stoppers, but I suspect that bugs 15963 and 15964 will
both be present in the final 8.0.0 build, whenever that may be.

I understand that everyone has their favourite problem that needs fixing. And I
understand that the LiveCode team has worked, and is working very hard, but I
have a problem named Steve.

Steve, (a programming colleague) to whom I sing the praises of LiveCode to,
knows of these bugs. Unfortunately, I expect that when I ask him to give
LiveCode another try, when version 8.0.X has a "stable" release, the following
will happen.

He is going to download it. Open the script editor and search for some text that
doesn't exist and turn to me with a big grin and say, "Ha! This issue still
exists. You want me to have confidence in a tool when a command in the IDE can
be so easily broken?"

I love LiveCode and can live with an irritation like this. (And if you are
thinking, why are you searching for text that doesn't exist, it is quite easy to
accidentally do when refactoring code with many Script Editor tabs open.)

But for Steve, it makes him think that LiveCode is flaky.

--
Scott McDonald
"Components, Controls, Tools and Resources for LiveCode"
www.runrevplanet.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: Volunteer github guru for documentation submissions?

2016-04-13 Thread Monte Goulding

> On 14 Apr 2016, at 12:42 AM, Richard Gaskin  
> wrote:
> 
> I wonder if the power and flexibility of LiveCode could be applied to making 
> a front-end for working with LiveCode documentation.
> 
> It would of course be ideal if the core dev team had time for that, but 
> looking at the queue of things I'd like them to do and things others want 
> them to do I can't say I'd want that to be a priority for them.

I’ve thought about this and yes it would be feasible to do however there are 
two things we know exist:
 - good git gui’s - I like and often use SourceTree which is available for 
Windows and Mac
 - good text editors - I use Atom these days

There really isn’t anything else we need other than some reasonable 
instructions on using said git gui and text editor. I really think that people 
would find using a local git gui and text editor much easier than the GitHub 
web interface.

In the end I think our community will benefit from not creating our own thing 
to hide ourselves from using tools that almost everyone else on other platforms 
are using. We can’t expect people to take a step in our direction if we aren’t 
prepared to take a step in theirs first. From a user centric perspective if I 
am going to learn to use something in order to do something for someone else 
I’d much rather the thing I’m learning be useful in other contexts I can apply 
it to. Neither the web interface nor some custom LC docs git gui will pass that 
test. Indeed a LC docs git gui is worse on that front.

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: selObj changed?

2016-04-13 Thread Richard Gaskin

Ali Lloyd wrote:

> Not a feature, and I can't reproduce it here. Is it Linux-specific?

Perhaps, haven't tested it elsewhere.  It seems to be related to how one 
of my plugins works, but it's behaving differently in v8 than before.


I'll pin down the recipe and submit an report.


> On 4/13/2016 4:13 PM, Richard Gaskin wrote:
> > RECIPE:
> > 1. Make a new stack
> > 2. With the Browse tool active, in the Message Box run:
> >
> >   put the selObj
> >
> > In versions prior to v8 the selObj is empty, but in v8 it returns
> > the name of the stack.
> >
> > Bug or feature?

--
 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: Volunteer github guru for documentation submissions?

2016-04-13 Thread Monte Goulding

> On 14 Apr 2016, at 1:07 AM, Mike Kerner  wrote:
> 
> The process for modifying code and the process for modifying documentation
> should be different.  Git, maybe intentionally, makes it difficult for
> people to work together on documents.  One of the things that Ali and I ran
> into is that he cannot easily make changes to my changes because that's not
> the way git is designed.  So, if I have something I screwed up (like some
> of the tags), his only option is to write a missive about it.  A few
> hundred words later, and he has spend a lot of time writing, but I don't
> understand so a few hundred words more, and I think I understand what he is
> saying, so I make a change but something else is messed up and so we go
> back and forth and all we have manged to do is write a lot of words but not
> fix anything.
> 
> And I'm in the wrong branch.  I won't be the only person to do that,
> either.
> 
> If git is going to be the tool, then there needs to be a pre-tool.  If that
> pre-tool is a mailing list, then so be it.  I'll send my last version of
> send, and y'all can have at it, if you choose.

GitHub <> git and you are using GitHub which has hacked on a web interface for 
working on stuff. I honestly think that if folks spent the same amount of time 
working out the web interface as working out how to use git locally using a 
good git gui then they would be finding things much simpler. The main issue is 
locally you need to actively switch branches so you always know where you are 
but on the web it is much easier to jump between branches and get confused.

There is a way for others to work on things together and given that’s the point 
of git that’s a good thing! The way to do it is to go to your patch-4 branch, 
edit and then submit a PR to you which you then incorporate and which would 
reflect the changes in your PR. In the past I have sent PRs to branches on 
other people’s forks on the team and had team members send PRs to my branches 
that I have had in review.

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: selObj changed?

2016-04-13 Thread Ali Lloyd
Not a feature, and I can't reproduce it here. Is it Linux-specific?

On Wed, Apr 13, 2016 at 10:12 PM Paul Dupuis  wrote:

> On 4/13/2016 4:13 PM, Richard Gaskin wrote:
> > RECIPE:
> > 1. Make a new stack
> > 2. With the Browse tool active, in the Message Box run:
> >
> >   put the selObj
> >
> >
> > In versions prior to v8 the selObj is empty, but in v8 it returns the
> > name of the stack.
> >
> > Bug or feature?
> >
>
> If it is a "feature", the change MUST be clearly documented in the
> Dictionary AND Release Notes for LC8 since it will likely break existing
> code.
>
> It could be useful to know what the "selected" stack is even if no
> control is selected on the stack, but is that "feature" worth breaking
> existing code. Probably not.
>
> ___
> 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: selObj changed?

2016-04-13 Thread Scott Rossi
I'd vote bug.

The name of the property (and its history) implies an object that can be
selected and unselected.  It's too much work to have to compare the
property value with the stack name to determine if nothing is selected.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 4/13/16, 1:13 PM, "use-livecode on behalf of Richard Gaskin"
 wrote:

>RECIPE:
>1. Make a new stack
>2. With the Browse tool active, in the Message Box run:
>
>   put the selObj
>
>
>In versions prior to v8 the selObj is empty, but in v8 it returns the
>name of the stack.
>
>Bug or feature?
>
>-- 
>  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



___
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: selObj changed?

2016-04-13 Thread Paul Dupuis
On 4/13/2016 4:13 PM, Richard Gaskin wrote:
> RECIPE:
> 1. Make a new stack
> 2. With the Browse tool active, in the Message Box run:
>
>   put the selObj
>
>
> In versions prior to v8 the selObj is empty, but in v8 it returns the
> name of the stack.
>
> Bug or feature?
>

If it is a "feature", the change MUST be clearly documented in the
Dictionary AND Release Notes for LC8 since it will likely break existing
code.

It could be useful to know what the "selected" stack is even if no
control is selected on the stack, but is that "feature" worth breaking
existing code. Probably not.

___
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: errorDialog broken?

2016-04-13 Thread Richard Gaskin

Ralph DiMola wrote:

> It works in a library stack. In fact it also catches IDE errors.

Thanks.  I found the culprit:  I hadn't yet turned off "Debug Mode" 
(still don't know why the default is to create yet one more difference 
between IDE and runtime, but oh well...)


--
 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: Volunteer github guru for documentation submissions?

2016-04-13 Thread Ralph DiMola
You are correct. It made a difference in v6 at one point. I will try to nail
down when it changed.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of J. Landman Gay
Sent: Monday, April 11, 2016 7:48 PM
To: How to use LiveCode
Subject: RE: Volunteer github guru for documentation submissions?

I tested this in LC 8 and wasn't getting any difference when adding
"effective" so maybe it's been changed. I'm editing the two formatted
properties right now and wasn't sure I should add the effective distinction.
Do you get a difference in 8?

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



On April 11, 2016 5:25:53 PM "Ralph DiMola" 
wrote:

> The "Effective" modifier for "formattedheight". This modifier will
calculate
> the text height in a field allowing for maximum acenders and decenders in
> the field's current text. Without the "Effective" modifier the height is
> calculated for the maximum acenders and decenders in the entire font set.
>
> Ralph DiMola
> IT Director
> Evergreen Information Services
> rdim...@evergreeninfo.net
>
>
> -Original Message-
> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On
Behalf
> Of Mark Smith
> Sent: Monday, April 11, 2016 3:53 PM
> To: use-revolut...@lists.runrev.com
> Subject: Re: Volunteer github guru for documentation submissions?
>
> Does anyone have a documentation bug they would like to see fixed? I'd
like
> to give Ali's guide a try but don't have any documentation bugs top of
mind.
>
> Mark
>
>
>
> --
> View this message in context:
>
http://runtime-revolution.278305.n4.nabble.com/Volunteer-github-guru-for-doc
> umentation-submissions-tp4703029p4703298.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



___
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: errorDialog broken?

2016-04-13 Thread Ralph DiMola
It works in a library stack. In fact it also catches IDE errors.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Richard Gaskin
Sent: Wednesday, April 13, 2016 4:22 PM
To: How to use LiveCode
Subject: errorDialog broken?

Many years ago I thought I could use the errorDialog message to catch throw
statements, but when I try that here in both v6 and v8 I find all
errorDialog handlers are ignored

- EXCEPT -

...for the one in LC's revbackscriptlibrary

1. Why?

2. How?

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


___
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: 8.0.0 RC1 - Which Xcode Version?

2016-04-13 Thread panagiotis merakos
Currently the supported versions of Xcode are:

Xcode 4.6 on OSX 10.7
Xcode 5.1 on OSX 10.8
Xcode 6.2 on OSX 10.9
Xcode 6.2 and 7.2 on OSX 10.10
Xcode 7.3 on OSX 10.11

Taken from the Release Notes, page 6:
http://downloads.livecode.com/livecode/8_0_0/LiveCodeNotes-8_0_0_rc_1.pdf

Best,
Panos
--

On Wed, Apr 13, 2016 at 9:39 PM, Mark Talluto 
wrote:

>
> > On Apr 13, 2016, at 10:08 AM, Sannyasin Brahmanathaswami <
> bra...@hindu.org> wrote:
> >
> > In dp 16… I had to turn off the auto updates in the App store, deleted
> the latest version of Xcode, and installed Xcode 7.2.1  after that the
> mobile provisioning in dp16 prefs was “green for go” with the SDK 9.2
> >
> > After loading RC1…it is “red for no go”  What version should we download
> now? Since the recent lightening storm fried some routers my connection
> bandwidth dropped here in our office… I only want to fetch Xcode once and
> get the right version.
>
> 7.3 should do it.
>
> Best regards,
>
> Mark Talluto
> livecloud.io 
> canelasoftware.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: Volunteer github guru for documentation submissions?

2016-04-13 Thread Devin Asay

> On Apr 13, 2016, at 11:52 AM, J. Landman Gay  wrote:
> 
> On April 13, 2016 7:58:21 AM Mike Kerner  wrote:
> 
>> I'm done.  I have better things to do than fight through trying to help
>> everybody by making the docs better.
> 
> I can so sympathize, but at least I don't feel so stupid now. I am going to 
> keep plugging away at it, doing only the most minimal changes until I know 
> what I'm doing. I plan to do only one or two a day to keep down the 
> frustration. Last night I forgot to add labels to my descriptive summaries 
> and when I tried to go back to do that I could find no way to edit them. 
> Peter put them in for me so there must be a way but it sure isn't obvious.

I sympathize, too, but after a few days of intensively trying to figure this 
out (and probably causing Ali and Peter some head-shaking), it’s starting to 
make sense. When I start into editing a dictionary entry now this is my process:

1 - Find the entry I want to work on by identifying errors or omissions in the 
LC Dictionary.

2 - Make extra, extra sure I go in at 
https://github.com/livecode/livecode/tree/community-docs/docs/dictionary. I 
really fouled this up my first couple of pull requests.

3 - Navigate to the category the dictionary entry belongs in; e.g. keyword, 
property, command, etc. and open the specific document.

4 - Once the doc is open hit the Edit button.

Once we’re at this point, I think a couple of tools could really make things 
easier:

- A style guide. When do you use block quoting? How thorough should we be at 
linking terms within the document and adding entries to the References: 
section? When to use a list? How and when do you create tables anyway?

- A markdown validator. Even though markdown is way simpler than something like 
html, it’s easy to miss things. (@peter-b, can something like this be done in 
Atom?)

- A markdown previewer. I know Ali made a stab at this, but I wasn't able to 
get it to work.

5 - I’ve found that once I get to this point, it’s straightforward to submit 
the pull request. Well, except that you have to Click about three times on 
different buttons before it’s really, really submitted. 

Finally, I think this effort could benefit by having a “traffic cop” who 
monitors documentation problems and invites people to fix them. No, I don’t 
want to be that guy. :)

These are mainly just musings on this process after a few days of deep diving 
into it. Fiddly but doable.

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

errorDialog broken?

2016-04-13 Thread Richard Gaskin
Many years ago I thought I could use the errorDialog message to catch 
throw statements, but when I try that here in both v6 and v8 I find all 
errorDialog handlers are ignored


- EXCEPT -

...for the one in LC's revbackscriptlibrary

1. Why?

2. How?

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


selObj changed?

2016-04-13 Thread Richard Gaskin

RECIPE:
1. Make a new stack
2. With the Browse tool active, in the Message Box run:

  put the selObj


In versions prior to v8 the selObj is empty, but in v8 it returns the 
name of the stack.


Bug or feature?

--
 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: [ANN] Release 8.0.0 RC 1

2016-04-13 Thread Peter TB Brett

On 13/04/2016 20:36, Jim Lambert wrote:

Here’s an issue I’m seeing with LC 8.0.0 RC 1 on OS X that I have not seen 
previously.

When I launch LC 8.0.0 RC 1 on OS X I get the 'You downloaded this application 
from the Internet…' security dialog.
Usually you just click OK and never see that dialog again. At least that was 
the case with earlier versions of LC.
However, I get it every time I launch LC 8.0.0.

If anyone else is experiencing this, here’s how to fix it.
Select the LC 8.0.0 RC 1 app in Finder.
Get Info (command-I).
Change the app’s security settings from ‘Read Only’ to 'Read & Write.'
The next time you launch LC 8 RC 1, you will again get the security dialog, but 
not on subsequent launches.


We're tracking this with bug 17385 [1].

   Peter

[1] http://quality.livecode.com/show_bug.cgi?id=17385

--
Dr Peter Brett 
LiveCode Open Source Team

LiveCode 2016 Conference https://livecode.com/edinburgh-2016/

___
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: [ANN] Release 8.0.0 RC 1

2016-04-13 Thread Mike Kerner
I'm not experiencing that, at least on 10.10.5

On Wed, Apr 13, 2016 at 3:36 PM, Jim Lambert  wrote:

> Here’s an issue I’m seeing with LC 8.0.0 RC 1 on OS X that I have not seen
> previously.
>
> When I launch LC 8.0.0 RC 1 on OS X I get the 'You downloaded this
> application from the Internet…' security dialog.
> Usually you just click OK and never see that dialog again. At least that
> was the case with earlier versions of LC.
> However, I get it every time I launch LC 8.0.0.
>
> If anyone else is experiencing this, here’s how to fix it.
> Select the LC 8.0.0 RC 1 app in Finder.
> Get Info (command-I).
> Change the app’s security settings from ‘Read Only’ to 'Read & Write.'
> The next time you launch LC 8 RC 1, you will again get the security
> dialog, but not on subsequent launches.
>
> Jim Lambert
> ___
> 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
>



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

Re: [ANN] Release 8.0.0 RC 1

2016-04-13 Thread Jim Lambert
Here’s an issue I’m seeing with LC 8.0.0 RC 1 on OS X that I have not seen 
previously.

When I launch LC 8.0.0 RC 1 on OS X I get the 'You downloaded this application 
from the Internet…' security dialog.
Usually you just click OK and never see that dialog again. At least that was 
the case with earlier versions of LC.
However, I get it every time I launch LC 8.0.0. 

If anyone else is experiencing this, here’s how to fix it.
Select the LC 8.0.0 RC 1 app in Finder. 
Get Info (command-I).
Change the app’s security settings from ‘Read Only’ to 'Read & Write.'
The next time you launch LC 8 RC 1, you will again get the security dialog, but 
not on subsequent launches.

Jim Lambert
___
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: 8.0.0 RC1 - Which Xcode Version?

2016-04-13 Thread Mark Talluto

> On Apr 13, 2016, at 10:08 AM, Sannyasin Brahmanathaswami  
> wrote:
> 
> In dp 16… I had to turn off the auto updates in the App store, deleted the 
> latest version of Xcode, and installed Xcode 7.2.1  after that the mobile 
> provisioning in dp16 prefs was “green for go” with the SDK 9.2
> 
> After loading RC1…it is “red for no go”  What version should we download now? 
> Since the recent lightening storm fried some routers my connection bandwidth 
> dropped here in our office… I only want to fetch Xcode once and get the right 
> version.

7.3 should do it.

Best regards,

Mark Talluto
livecloud.io 
canelasoftware.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

Anyone have any LiveCode hooks to WordPress? And, are you following these Word Camp events

2016-04-13 Thread Mark Rauterkus
Hi,

These Word Camp events might be a great way to share some of the love for
LiveCode, if you are a blogger and using WordPress, especially.


https://2016.pittsburgh.wordcamp.org/


I just went to my first a week long Steel City CodeFest in my town. Fun. No
LiveCode. But next year, we'll gear up with some teams, I expect.

Most of the show off stuff at CodeFest was only prototype stuff.


--
Ta.


Mark Rauterkus   m...@rauterkus.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: Volunteer github guru for documentation submissions?

2016-04-13 Thread Ali Lloyd
That's correct, clipboardData, rawClipboardData and fullClipboardData are
all global properties, whereas clipboard is a function that returns the
type of data on the clipboard.

Now that I read it again though, those instances of  in the
summaries of all the clipboard entries should be links to the clipboard
glossary entry, not the clipboard function. So the following things should
probably happen:
- clipboard (property) should be removed from the references of
fullClipboardData and rawClipboardData
- clipboard (glossary) should be add to the references of
clipboardData, fullClipboardData and rawClipboardData
- The references to  in all of those entries should be audited
so that they link to  when the entry is talking about
the clipboard function, and  when, as in the
summaries, they are referring to the general concept of a clipboard.

On Wed, Apr 13, 2016 at 6:54 PM J. Landman Gay 
wrote:

> All the clipboard entries are listed in the Properties category on github
> also. Made me scratch my head.
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
>
>
> On April 13, 2016 2:18:20 AM Ali Lloyd  wrote:
>
> > I think the problem with  in those two entries is that
> clipboard
> > (property) is in the references, but it there is no clipboard property,
> > only a clipboard function. So removing that from the references should
> fix
> > it.
> >
> > On Wed, Apr 13, 2016 at 6:57 AM J. Landman Gay  >
> > wrote:
> >
> >> On 4/13/2016 12:51 AM, Monte Goulding wrote:
> >> >
> >> >> On 13 Apr 2016, at 3:47 PM, J. Landman Gay
> >> >>  wrote:
> >> >>
> >> >>> That must be a bug with the dictionary as  is
> >> >>> rendering fine on the clipboardData. Can you report that?
> >> >>
> >> >> It's a markdown issue I was thinking Mark Smith might want to
> >> >> tackle, since it's part of the community docs we're trying to edit.
> >> >> If he doesn't, then I'll try it.
> >> >
> >> > I can’t see anything different between the use in the summary of
> >> >  in the clipboardData and the fullClipboadData so I don’t
> >> > think it is markdown related but I could be wrong.
> >>
> >> Yeah, I was just looking at it again and I think you're right. I'll
> >> report it.
> >>
> >> --
> >> Jacqueline Landman Gay | jac...@hyperactivesw.com
> >> HyperActive Software   | http://www.hyperactivesw.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
>
>
>
> ___
> 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: Indy Licensing

2016-04-13 Thread JB
You can use the FREE VERSION.

But I have read you are not allowed
to develop for the Indy with it.

I guess you can discuss the licensing
of the free version and hw it relates.

JB





> On Apr 13, 2016, at 10:36 AM, Warren Samples  wrote:
> 
> On 04/13/2016 12:26 PM, John Dixon wrote:
>> I am surprised that this list has not been flooded with questions and 
>> complaints...
> 
> 
> Have you been away?
> 
> ___
> 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: Volunteer github guru for documentation submissions?

2016-04-13 Thread J. Landman Gay
All the clipboard entries are listed in the Properties category on github 
also. Made me scratch my head.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



On April 13, 2016 2:18:20 AM Ali Lloyd  wrote:


I think the problem with  in those two entries is that clipboard
(property) is in the references, but it there is no clipboard property,
only a clipboard function. So removing that from the references should fix
it.

On Wed, Apr 13, 2016 at 6:57 AM J. Landman Gay 
wrote:


On 4/13/2016 12:51 AM, Monte Goulding wrote:
>
>> On 13 Apr 2016, at 3:47 PM, J. Landman Gay
>>  wrote:
>>
>>> That must be a bug with the dictionary as  is
>>> rendering fine on the clipboardData. Can you report that?
>>
>> It's a markdown issue I was thinking Mark Smith might want to
>> tackle, since it's part of the community docs we're trying to edit.
>> If he doesn't, then I'll try it.
>
> I can’t see anything different between the use in the summary of
>  in the clipboardData and the fullClipboadData so I don’t
> think it is markdown related but I could be wrong.

Yeah, I was just looking at it again and I think you're right. I'll
report it.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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




___
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: Volunteer github guru for documentation submissions?

2016-04-13 Thread J. Landman Gay

On April 13, 2016 7:58:21 AM Mike Kerner  wrote:


I'm done.  I have better things to do than fight through trying to help
everybody by making the docs better.


I can so sympathize, but at least I don't feel so stupid now. I am going to 
keep plugging away at it, doing only the most minimal changes until I know 
what I'm doing. I plan to do only one or two a day to keep down the 
frustration. Last night I forgot to add labels to my descriptive summaries 
and when I tried to go back to do that I could find no way to edit them. 
Peter put them in for me so there must be a way but it sure isn't obvious.


Stuff like that makes you crazy.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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: Indy Licensing

2016-04-13 Thread Warren Samples

On 04/13/2016 12:26 PM, John Dixon wrote:

I am surprised that this list has not been flooded with questions and 
complaints...



Have you been away?

___
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: Indy Licensing

2016-04-13 Thread John Dixon

Why are Licensing questions off-topic for this mailing list ? 

With the changes that have been made to licensing and the massive hike in price 
that is being seen over the next few months to the end of the year, I am 
surprised that this list has not been flooded with questions and complaints...

hmm... the question put by Bob Sneidar is, to my mind, a perfectly reasonable 
question to ask ... and asking on the list allows others read the questions and 
comments on the current state of the hike in 'livecode' pricing, more than 
doubling the cost to just 'use', not 'own' the software for a twelve month 
period...




> On 13/04/2016 17:21, Bob Sneidar wrote:
> > Does the IDE functionality stop working once the indy license expires? In 
> > other words, do I have to pay each year to continue developing apps?
> 
> Hi Bob,
> 
> Licensing questions are off-topic for this mailing list -- but our 
> support team at supp...@livecode.com would be delighted to answer your 
> question.
> 
>Peter :-)
> 
> -- 
> Dr Peter Brett 
> LiveCode Open Source Team
> 
> LiveCode 2016 Conference: https://livecode.com/edinburgh-2016/

  
___
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


8.0.0 RC1 - Which Xcode Version?

2016-04-13 Thread Sannyasin Brahmanathaswami
In dp 16… I had to turn off the auto updates in the App store, deleted the 
latest version of Xcode, and installed Xcode 7.2.1  after that the mobile 
provisioning in dp16 prefs was “green for go” with the SDK 9.2

After loading RC1…it is “red for no go”  What version should we download now? 
Since the recent lightening storm fried some routers my connection bandwidth 
dropped here in our office… I only want to fetch Xcode once and get the right 
version.

BR
___
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: Plugins vs. the Mac app bundle

2016-04-13 Thread Richard Gaskin

Paul Hibbert wrote:

>> But frankly, even then I'd think twice about modifying signed files.
>> Bypassing security is rarely advantageous.
>
> I wasn’t making the changes to bypass any security issues, I just
> wanted to modify the menus slightly, I didn’t even think about code
> signing and didn’t see any problems after making the changes.

Not your intention of course, but very much the intention of Apple to 
prevent that.


But you're already exploring other means so it looks like you're set:

> When I found out how easy it is to add the shortcuts to the menus I
> just wrote a little routine to update the new version - run once then
> forget it.
>
>> Time and again, as we explore IDE customization we come back to
>> the same solution:  write scripts that modify things on the fly
>> in memory.
>
> I tried this too, but then when I quit the app it just asked me if I
> wanted to save the modified stack, if I agreed it just threw an error
> because of the permissions problem, maybe I approached it wrong.

If you want to share your code here I'll bet we can pin down which part 
triggers the "dirty" flag.


Since you've already scripted your changes, having them run in a plugin 
on startup rather than attempting to alter the bundle contents will make 
everything work well, once we take care of that save prompt.


But I know it's doable:  my devolution plugin makes a lot of changes to 
revMenubar on startup, and I've not seen a save prompt yet.  I'll bet we 
can figure out how to tailor your script to do the same.


--
 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: Indy Licensing

2016-04-13 Thread Peter TB Brett

On 13/04/2016 17:21, Bob Sneidar wrote:

Does the IDE functionality stop working once the indy license expires? In other 
words, do I have to pay each year to continue developing apps?


Hi Bob,

Licensing questions are off-topic for this mailing list -- but our 
support team at supp...@livecode.com would be delighted to answer your 
question.


  Peter :-)

--
Dr Peter Brett 
LiveCode Open Source Team

LiveCode 2016 Conference: https://livecode.com/edinburgh-2016/

___
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: Volunteer github guru for documentation submissions?

2016-04-13 Thread Richard Gaskin

Mike Kerner wrote:


The process for modifying code and the process for modifying documentation
should be different.


I agree that's it's very valuable to continually strive for ever-better 
workflow methods.


The challenge here is: what exactly does a better solution look like?

Even if we decide we don't want to use Git for part of the product, the 
rest of the product is maintained in Git so we'd then have the 
additional task of creating some means of integrating the new system to 
allow tracking and building within Git.


This is not impossible.  But it is also not trivial.  That much is known.

What's unknown is whether that additional work is more or less work than 
working within Git.


Anyone who came come up with a solution that answers that question 
favorably in terms of cost-effectiveness will be a hero.




Git, maybe intentionally, makes it difficult for people to work together
on documents.  One of the things that Ali and I ran into is that he
cannot easily make changes to my changes because that's not the way
git is designed.


I'd need to learn more about the specifics of that particular moment 
before I'd feel comfortable charactering Git as not being designed for 
collaborative workflows.  Indeed, Git's support for collaboration is the 
main reason people deal with its funkiness in other respects. :)




And I'm in the wrong branch.  I won't be the only person to do that,
either.


Yep, I've done that.  Happens, in any system that supports branching. 
Such an error is similar to the fact that many thousands of people will 
have automobile accidents today.  No one wants an automobile accident, 
but it's easy for humans to make mistakes.  We all have a lot going on.


Documenting how branching works can help, but then admittedly it adds to 
the knowledge one needs to acquire in order to help.


Perhaps this may reduce some of the overhead with contributing:



If git is going to be the tool, then there needs to be a pre-tool.

...

On Wed, Apr 13, 2016 at 10:42 AM, Richard Gaskin wrote:

...

Maybe this is an opportunity to raise the bar, for both Git and LiveCode,
to serve our own needs while showing the world how awesome LiveCode is:


Many years ago Ken Ray made a marvelous stack called Revzilla, a LiveCode
plugin that served as a front-end to Bugzilla.  At the time many found
Bugzilla's cumbersome UI off-putting, and Revzilla provided a way to submit
and review bug requests that was much simpler and more convenient.

(I don't think it's been maintained through the last two rounds of LC's
Bugzilla overhaul, but FWIW Revzilla can be downloaded here:
 )

I wonder if the power and flexibility of LiveCode could be applied to
making a front-end for working with LiveCode documentation.

It would of course be ideal if the core dev team had time for that, but
looking at the queue of things I'd like them to do and things others want
them to do I can't say I'd want that to be a priority for them.

And ideally it needn't be.  After all, the one thing we know about the
LiveCode community is that everyone in it knows how to program in LiveCode.

I could contribute to such a project, but I have to be realistic about
time commitments and admit that I can't take a lead role on that.

But just maybe someone here has the intersection of time, skills, and
interest to consider it.

If so, I'd be happy to help where I can.


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


Indy Licensing

2016-04-13 Thread Bob Sneidar
Does the IDE functionality stop working once the indy license expires? In other 
words, do I have to pay each year to continue developing apps?

Bob S
___
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: Volunteer github guru for documentation submissions?

2016-04-13 Thread Mike Kerner
Name: send

Type: command

Syntax: send  [ to  [in  [seconds | ticks
| milliseconds]] ]

Summary: Sends  to  immediately, or adds
 to the  queue.

Introduced: 1.0

OS: mac,windows,linux,ios,android

Platforms: desktop,server,web,mobile

Example:
send "mouseDown" to button "next"

Example:
send "mouseDown" to button "text" of stack "project2"

Example:
# A simple timer using send example

local sTime
on mouseUp
   put 0 into sTime
   send "timerIncrement" to me in 1 seconds
end mouseUp

on timerIncrement
   add 1 to sTime
   put sTime
   send "timerIncrement" to me in 1 seconds
end timerIncrement

Parameters:
message: An expression that evaluates to a message name, possibly including
parameters.
object: Any object reference. If you don't specify an object, the message
is set to the object whose  contains the send command. If you
specify a time, you must also specify an object.
time (integer): If you don't specify a unit of time, the default of ticks
is used.

The result: If you specify a ,  is the ID of the
 in the   queue.

Description:
Use the   to override the normal , or to delay
a  until after a specified time.

The  can be either the name of a  or a 
. If the  is a  containing more
than one  (for example, if it includes , or if
it is a multi-word command), it must be enclosed in .

Any parameters are evaluated before they are passed to the 
. For example, the following statement sends the 
 with 2 as the first parameter:

  send "mouseUp 1+1" to button "Example"

>*Important:* When the send command is used, the stack containing the
target  temporarily becomes the defaultStack. All object
references in the  are  in the current
context i. e. the defaultStack. Therefore references within the message
that refer to "this card" or "this stack" will be referring to the card or
stack where the target  is located.

>*Important:*  If you don't specify a , the  is sent
immediately, and any  it  is completed before
the rest of the current  is .  However, if you
specify a , even one of 0, the current  finishes
 before the  is sent.

>*Note:*  Using the   is slower than directly
 the  using the normal .
For best efficiency, use the   only when you want to delay
the  or when the  you want to execute is not in the
.

References: callbacks (property), backgroundBehavior (property), function
(control_st), mouseUp (message), word (keyword), object (object), literal
string (glossary), return (glossary), evaluate (glossary), execute
(glossary), command (glossary), LiveCode (glossary), double quote
(glossary), trigger (glossary), message path (glossary), message
(glossary), parameter (glossary), statement (glossary), 
(glossary), debugDo (command), dispatch (command), call (command), cancel
(command), result (function), pendingMessages (function)
___
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: Volunteer github guru for documentation submissions?

2016-04-13 Thread Mike Kerner
The process for modifying code and the process for modifying documentation
should be different.  Git, maybe intentionally, makes it difficult for
people to work together on documents.  One of the things that Ali and I ran
into is that he cannot easily make changes to my changes because that's not
the way git is designed.  So, if I have something I screwed up (like some
of the tags), his only option is to write a missive about it.  A few
hundred words later, and he has spend a lot of time writing, but I don't
understand so a few hundred words more, and I think I understand what he is
saying, so I make a change but something else is messed up and so we go
back and forth and all we have manged to do is write a lot of words but not
fix anything.

And I'm in the wrong branch.  I won't be the only person to do that,
either.

If git is going to be the tool, then there needs to be a pre-tool.  If that
pre-tool is a mailing list, then so be it.  I'll send my last version of
send, and y'all can have at it, if you choose.

On Wed, Apr 13, 2016 at 10:42 AM, Richard Gaskin  wrote:

> Mike Kerner wrote:
>
> I'm done.  I have better things to do than fight through trying to
>> help everybody by making the docs better.  Have a look at send and
>> the attempts to clarify what it does and how it works, and if
>> afterward you want a go at it, go for it.  What looks at first glance
>> like a tweak turns out to be a hornet's nest that still isn't done.
>>
>
> Writing good docs is hard work.  We used to see a lot of "If they just..."
> comments here about the docs, but the more we participate the more we can
> appreciate firsthand that writing good documentation is no more trivial a
> task than writing good code.
>
> I appreciate your effort in giving it a go, and there's no blame in taking
> a break from it, even if the break becomes a permanent one.
>
> Contributions from the community are very valuable, but not an
> obligation.  The most important task any of us can do is to make great
> software with LiveCode and let others know how LiveCode helped you do it.
> Anything beyond that is appreciated, but not required.
>
>
>  If I have realized anything in the last 24 hours it's a) Github is
>> completely the wrong tool to use for documentation.  We should be
>> using a wiki or something similar.  The complexity that git adds does
>> not make this better.  If the goal was to open the documentation so
>> that the team can spend less time working on it, and so the folks who
>> use the tool all the time can improve it, then making updating the
>> docs this difficult is not going to do that.  b) Trying to keep all
>> the branches straight, and the complexity this adds is only going
>> to make it more difficult, still.
>>
>
> In some ways Github is like what Winston Churchill said about democracy:
>
>  Indeed it has been said that democracy is the worst
>  form of government except for all those other forms
>  that have been tried from time to time.
>
> As I used to write here on this list, software development happened before
> Github, and it will continue to happen after Github.  Its UI/UX is
> horrifyingly opaque, designed in a fit of Dunning-Kruger Effect by people
> with IQs north of 180 who are apparently impatient with anyone working in a
> more normal range.
>
> But over time I've come to recognize that it's the world's leading choice
> for collaborative software development.
>
> It's no magic pony, but then again magic ponies don't exist.
>
> We might even say it's a mess, but millions of project managers have found
> it less messy than the alternatives.
>
> Wikis definitely simplify input, but are far less flexible with output.
> If you're producing a web site they're often an excellent choice, but LC
> docs need to be exportable for local install, something the malleability of
> Markdown offers in spades but can be very difficult to do with a tool
> dependent on LAMP.  And wikis don't handle code at all, while Git provides
> a single set of tools for everything that comprises LiveCode.
>
> One of the strengths of Git is also one of the sources of frustration
> here:  support for multiple branches.  Warts and all, Git is recognized by
> even people who dislike it as excelling at that aspect of collaborative
> workflows more than any other tool.
>
> Branching and many other useful features of Git do indeed add complexity.
> But projects requiring branching are complex in themselves, and it allows
> that complexity to be isolated.
>
> For relatively trivial projects branching may not unimportant, perhaps
> even distracting.  But today's LiveCode code base, needing to isolate the
> broad scope of changes in v6 and v7 on the way to v8, would not likely have
> been possible without it.
>
>
> Maybe this is an opportunity to raise the bar, for both Git and LiveCode,
> to serve our own needs while showing the world how awesome LiveCode is:
>
>
> Many years ago Ken Ray made a marvelous 

Re: Volunteer github guru for documentation submissions?

2016-04-13 Thread Richard Gaskin

Mike Kerner wrote:


I'm done.  I have better things to do than fight through trying to
help everybody by making the docs better.  Have a look at send and
the attempts to clarify what it does and how it works, and if
afterward you want a go at it, go for it.  What looks at first glance
like a tweak turns out to be a hornet's nest that still isn't done.


Writing good docs is hard work.  We used to see a lot of "If they 
just..." comments here about the docs, but the more we participate the 
more we can appreciate firsthand that writing good documentation is no 
more trivial a task than writing good code.


I appreciate your effort in giving it a go, and there's no blame in 
taking a break from it, even if the break becomes a permanent one.


Contributions from the community are very valuable, but not an 
obligation.  The most important task any of us can do is to make great 
software with LiveCode and let others know how LiveCode helped you do 
it.  Anything beyond that is appreciated, but not required.




 If I have realized anything in the last 24 hours it's a) Github is
completely the wrong tool to use for documentation.  We should be
using a wiki or something similar.  The complexity that git adds does
not make this better.  If the goal was to open the documentation so
that the team can spend less time working on it, and so the folks who
use the tool all the time can improve it, then making updating the
docs this difficult is not going to do that.  b) Trying to keep all
the branches straight, and the complexity this adds is only going
to make it more difficult, still.


In some ways Github is like what Winston Churchill said about democracy:

 Indeed it has been said that democracy is the worst
 form of government except for all those other forms
 that have been tried from time to time.

As I used to write here on this list, software development happened 
before Github, and it will continue to happen after Github.  Its UI/UX 
is horrifyingly opaque, designed in a fit of Dunning-Kruger Effect by 
people with IQs north of 180 who are apparently impatient with anyone 
working in a more normal range.


But over time I've come to recognize that it's the world's leading 
choice for collaborative software development.


It's no magic pony, but then again magic ponies don't exist.

We might even say it's a mess, but millions of project managers have 
found it less messy than the alternatives.


Wikis definitely simplify input, but are far less flexible with output. 
 If you're producing a web site they're often an excellent choice, but 
LC docs need to be exportable for local install, something the 
malleability of Markdown offers in spades but can be very difficult to 
do with a tool dependent on LAMP.  And wikis don't handle code at all, 
while Git provides a single set of tools for everything that comprises 
LiveCode.


One of the strengths of Git is also one of the sources of frustration 
here:  support for multiple branches.  Warts and all, Git is recognized 
by even people who dislike it as excelling at that aspect of 
collaborative workflows more than any other tool.


Branching and many other useful features of Git do indeed add 
complexity. But projects requiring branching are complex in themselves, 
and it allows that complexity to be isolated.


For relatively trivial projects branching may not unimportant, perhaps 
even distracting.  But today's LiveCode code base, needing to isolate 
the broad scope of changes in v6 and v7 on the way to v8, would not 
likely have been possible without it.



Maybe this is an opportunity to raise the bar, for both Git and 
LiveCode, to serve our own needs while showing the world how awesome 
LiveCode is:



Many years ago Ken Ray made a marvelous stack called Revzilla, a 
LiveCode plugin that served as a front-end to Bugzilla.  At the time 
many found Bugzilla's cumbersome UI off-putting, and Revzilla provided a 
way to submit and review bug requests that was much simpler and more 
convenient.


(I don't think it's been maintained through the last two rounds of LC's 
Bugzilla overhaul, but FWIW Revzilla can be downloaded here:

 )

I wonder if the power and flexibility of LiveCode could be applied to 
making a front-end for working with LiveCode documentation.


It would of course be ideal if the core dev team had time for that, but 
looking at the queue of things I'd like them to do and things others 
want them to do I can't say I'd want that to be a priority for them.


And ideally it needn't be.  After all, the one thing we know about the 
LiveCode community is that everyone in it knows how to program in LiveCode.


I could contribute to such a project, but I have to be realistic about 
time commitments and admit that I can't take a lead role on that.


But just maybe someone here has the intersection of time, skills, and 
interest to consider it.


If so, I'd be happy to help 

Re: Volunteer github guru for documentation submissions?

2016-04-13 Thread Ali Lloyd
Mike,
I'm sorry it ended up being a very tricky document to change - I think we
jointly suffered a sort of scope creep because that doc doesn't properly
distinguish between the notion of a message and the messageName parameter.

While it's true that what you were originally suggesting was a tweak, you
di say yourself in this comment
https://github.com/livecode/livecode/pull/3861#issuecomment-206918583 that
you wanted to make a more radical change. Such things are bound to take
more time and involve more discussion. Perhaps if you could articulate what
difficulties you are having with conducting that discussion on the pull
request itself, we can find a way to overcome it.


On Wed, Apr 13, 2016 at 1:55 PM Mike Kerner 
wrote:

> I'm done.  I have better things to do than fight through trying to help
> everybody by making the docs better.  Have a look at send and the attempts
> to clarify what it does and how it works, and if afterward you want a go at
> it, go for it.  What looks at first glance like a tweak turns out to be a
> hornet's nest that still isn't done.  If I have realized anything in the
> last 24 hours it's a) Github is completely the wrong tool to use for
> documentation.  We should be using a wiki or something similar.  The
> complexity that git adds does not make this better.  If the goal was to
> open the documentation so that the team can spend less time working on it,
> and so the folks who use the tool all the time can improve it, then making
> updating the docs this difficult is not going to do that.  b) Trying to
> keep all the branches straight, and the complexity this adds is only going
> to make it more difficult, still.
>
> On Wed, Apr 13, 2016 at 3:16 AM, Ali Lloyd  wrote:
>
> > I think the problem with  in those two entries is that
> clipboard
> > (property) is in the references, but it there is no clipboard property,
> > only a clipboard function. So removing that from the references should
> fix
> > it.
> >
> > On Wed, Apr 13, 2016 at 6:57 AM J. Landman Gay  >
> > wrote:
> >
> > > On 4/13/2016 12:51 AM, Monte Goulding wrote:
> > > >
> > > >> On 13 Apr 2016, at 3:47 PM, J. Landman Gay
> > > >>  wrote:
> > > >>
> > > >>> That must be a bug with the dictionary as  is
> > > >>> rendering fine on the clipboardData. Can you report that?
> > > >>
> > > >> It's a markdown issue I was thinking Mark Smith might want to
> > > >> tackle, since it's part of the community docs we're trying to edit.
> > > >> If he doesn't, then I'll try it.
> > > >
> > > > I can’t see anything different between the use in the summary of
> > > >  in the clipboardData and the fullClipboadData so I don’t
> > > > think it is markdown related but I could be wrong.
> > >
> > > Yeah, I was just looking at it again and I think you're right. I'll
> > > report it.
> > >
> > > --
> > > Jacqueline Landman Gay | jac...@hyperactivesw.com
> > > HyperActive Software   | http://www.hyperactivesw.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
> >
>
>
>
> --
> 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
___
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: LC 8.0 (rc 1) - Again script edtior window disappearing off-screen

2016-04-13 Thread Roland Huettmann
Yes, thanks to you, BUT:

Working for a little while now in LC 8.0 ( lc 1) it happened again:

Script editor window disappeared to location: -25162,-25296 . And this time
the preferences file was NEWLY created.

It started all well and fine. Then during work - out of a sudden - after
some script errors, the SE window disappeared and was not seen again.

In my (very simple) logic, the preferences file saves some location, and it
may be a wrong location saved from such off-screen-disappearing, but the
bug itself hides somewhere else.

I also noticed that sometimes it is not possible to even access the script
editor - even if it is in the bounds of the screen and potentially be
visible -  and my "work around" was opening another script editor and then
switching the tab of editors to the original script that I am working on.
Also then a right-click on a control such as a button will not show
anything and not allow to open a script.

Is there enough testing done on Windows?

Roland



On 13 April 2016 at 10:47, panagiotis merakos  wrote:

> @Peter
> Yes, Roland has already attached the old prefs in the bug report (
> http://quality.livecode.com/show_bug.cgi?id=16749) as requested
>
> Best,
> Panos
> --
>
> On Wed, Apr 13, 2016 at 9:13 AM, Peter TB Brett 
> wrote:
>
> >
> >
> > On 13/04/2016 08:43, Roland Huettmann wrote:
> >
> > - Move the file or files to some other folder (or delete if not needed
> any
> >> longer)
> >>
> >> - Restart LiveCode
> >>
> >> - A new Preferences file will be created (have a look)
> >>
> >
> > If moving your preferences file out of the way fixes incorrect IDE
> > behaviour, we'd like to look at it -- one of our ongoing tasks is to
> make a
> > collection of preferences files that break things, so we can stop the
> > brokenness from happening.
> >
> > Either attach the preferences file to a related bug report, or e-mail it
> > to supp...@livecode.com with a description of the problem that it was
> > causing!
> >
> >Peter
> >
> > --
> > Dr Peter Brett 
> > LiveCode Open Source Team
> >
> > LiveCode 2016 Conference https://livecode.com/edinburgh-2016/
> >
> >
> > ___
> > 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: Volunteer github guru for documentation submissions?

2016-04-13 Thread Mike Kerner
I'm done.  I have better things to do than fight through trying to help
everybody by making the docs better.  Have a look at send and the attempts
to clarify what it does and how it works, and if afterward you want a go at
it, go for it.  What looks at first glance like a tweak turns out to be a
hornet's nest that still isn't done.  If I have realized anything in the
last 24 hours it's a) Github is completely the wrong tool to use for
documentation.  We should be using a wiki or something similar.  The
complexity that git adds does not make this better.  If the goal was to
open the documentation so that the team can spend less time working on it,
and so the folks who use the tool all the time can improve it, then making
updating the docs this difficult is not going to do that.  b) Trying to
keep all the branches straight, and the complexity this adds is only going
to make it more difficult, still.

On Wed, Apr 13, 2016 at 3:16 AM, Ali Lloyd  wrote:

> I think the problem with  in those two entries is that clipboard
> (property) is in the references, but it there is no clipboard property,
> only a clipboard function. So removing that from the references should fix
> it.
>
> On Wed, Apr 13, 2016 at 6:57 AM J. Landman Gay 
> wrote:
>
> > On 4/13/2016 12:51 AM, Monte Goulding wrote:
> > >
> > >> On 13 Apr 2016, at 3:47 PM, J. Landman Gay
> > >>  wrote:
> > >>
> > >>> That must be a bug with the dictionary as  is
> > >>> rendering fine on the clipboardData. Can you report that?
> > >>
> > >> It's a markdown issue I was thinking Mark Smith might want to
> > >> tackle, since it's part of the community docs we're trying to edit.
> > >> If he doesn't, then I'll try it.
> > >
> > > I can’t see anything different between the use in the summary of
> > >  in the clipboardData and the fullClipboadData so I don’t
> > > think it is markdown related but I could be wrong.
> >
> > Yeah, I was just looking at it again and I think you're right. I'll
> > report it.
> >
> > --
> > Jacqueline Landman Gay | jac...@hyperactivesw.com
> > HyperActive Software   | http://www.hyperactivesw.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
>



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

LC7 and 8 - Non responsive processing large text files

2016-04-13 Thread Roland Huettmann
This issue was addressed before within another context, but I am running
into the same problems with all versions of 7 and 8 including the latest
rc1 (using Windows 8.1 to Windows 10).

The question is important as it is related to a planned project for very
serious development and a product to be developed with LiveCode 8.0 (stable
version).

Imagine Gibabytes big text files. Maybe even it could be Terabytes!

NON-RESPONSIVENESS USING "UNTIL" READ

I found opening a very large text file (my file is 26 GB), simply reading
from it up to 90 MB of data in each iteration, using an offset () function
processing the read junk of data, and iterating through the file, is not a
problem and performs acceptably.

But reading something into memory using "read from file  UNTIL
" and doing this many times over in such large text file creates
non-responsiveness of LC (tested on 7 and 8).

So, what do I do?

1. Open file in read only mode and for binary read
2. Reading until  (which separates pieces of data where each piece
is not bigger than 30 MB)
3. Repeating the reading 10x or 100,000x or more... (depends on file size)
4. Performing some additional processing on such read pieces of data in
memory
5. Eventually placing data into a field, or storing it away somewhere else
(max 30 MB in my case)
6. Closing the file

LC eventually turns back to normal state when user is waiting long enough
and the process is finished. But LC is completely locked away in such
non-responsive state, and it is not acceptable to our project.

Maybe with each loop I have to send a waiting message? I tried sending with
10 milliseconds, but nothing changed. I tried several other options.

One more note: Additionally I find that it can take significant delays when
placing large blocks of text into a field. Is there an idea of improving
this?

Kind greetings
Roland
___
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: LC 8.0 (rc 1) - Again script edtior window disappearing off-screen

2016-04-13 Thread panagiotis merakos
@Peter
Yes, Roland has already attached the old prefs in the bug report (
http://quality.livecode.com/show_bug.cgi?id=16749) as requested

Best,
Panos
--

On Wed, Apr 13, 2016 at 9:13 AM, Peter TB Brett 
wrote:

>
>
> On 13/04/2016 08:43, Roland Huettmann wrote:
>
> - Move the file or files to some other folder (or delete if not needed any
>> longer)
>>
>> - Restart LiveCode
>>
>> - A new Preferences file will be created (have a look)
>>
>
> If moving your preferences file out of the way fixes incorrect IDE
> behaviour, we'd like to look at it -- one of our ongoing tasks is to make a
> collection of preferences files that break things, so we can stop the
> brokenness from happening.
>
> Either attach the preferences file to a related bug report, or e-mail it
> to supp...@livecode.com with a description of the problem that it was
> causing!
>
>Peter
>
> --
> Dr Peter Brett 
> LiveCode Open Source Team
>
> LiveCode 2016 Conference https://livecode.com/edinburgh-2016/
>
>
> ___
> 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: LC 8.0 (rc 1) - Again script edtior window disappearing off-screen

2016-04-13 Thread Peter TB Brett



On 13/04/2016 08:43, Roland Huettmann wrote:


- Move the file or files to some other folder (or delete if not needed any
longer)

- Restart LiveCode

- A new Preferences file will be created (have a look)


If moving your preferences file out of the way fixes incorrect IDE 
behaviour, we'd like to look at it -- one of our ongoing tasks is to 
make a collection of preferences files that break things, so we can stop 
the brokenness from happening.


Either attach the preferences file to a related bug report, or e-mail it 
to supp...@livecode.com with a description of the problem that it was 
causing!


   Peter

--
Dr Peter Brett 
LiveCode Open Source Team

LiveCode 2016 Conference https://livecode.com/edinburgh-2016/

___
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: LC 8.0 (rc 1) - Again script edtior window disappearing off-screen

2016-04-13 Thread Roland Huettmann
Thank you Richard for your suggestion. ))).

And with the help of Panos the reason has been detected.
It has something to do with the Preferences file.
Now all is ok, script editor appears where is should appear.

WINDOWS: CHANGE OR REMOVE OR DELETE PREFERENCE FILE

If anybody experiencing something similar:

- Close LiveCode

- On Windows you need to make hidden folders visible (uncheck checkbox
"Hidden items" in the folders "View" tab)

- Go to "C:\Users\your_user_name\AppData/Roaming\RunRev\Preferences\"

- At this location you should find one or two files "livecode.rev" and/or
"livecode7.rev"

- Move the file or files to some other folder (or delete if not needed any
longer)

- Restart LiveCode

- A new Preferences file will be created (have a look)

- Again hide "hidden folders" on your machine if you do not want to see all
the clutter of available hidden folders and files

- Voila ! ) Done.
___
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: Volunteer github guru for documentation submissions?

2016-04-13 Thread Ali Lloyd
I think the problem with  in those two entries is that clipboard
(property) is in the references, but it there is no clipboard property,
only a clipboard function. So removing that from the references should fix
it.

On Wed, Apr 13, 2016 at 6:57 AM J. Landman Gay 
wrote:

> On 4/13/2016 12:51 AM, Monte Goulding wrote:
> >
> >> On 13 Apr 2016, at 3:47 PM, J. Landman Gay
> >>  wrote:
> >>
> >>> That must be a bug with the dictionary as  is
> >>> rendering fine on the clipboardData. Can you report that?
> >>
> >> It's a markdown issue I was thinking Mark Smith might want to
> >> tackle, since it's part of the community docs we're trying to edit.
> >> If he doesn't, then I'll try it.
> >
> > I can’t see anything different between the use in the summary of
> >  in the clipboardData and the fullClipboadData so I don’t
> > think it is markdown related but I could be wrong.
>
> Yeah, I was just looking at it again and I think you're right. I'll
> report it.
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.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: [ANN] Release 8.0.0 RC 1 (Linux)

2016-04-13 Thread Peter TB Brett

On 13/04/2016 05:40, Mark Wieder wrote:


The good news: I no longer am seeing a CEF segfault after closing the
dictionary and IDE. My guess is that we are no longer using the CEF
browser for the dictionary.


We are, in fact, still using the CEF-based browser widget for the 
dictionary.


  Peter

--
Dr Peter Brett 
LiveCode Open Source Team

LiveCode 2016 Conference https://livecode.com/edinburgh-2016/

___
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