Re: site scraper

[Simon Smith]

Hi

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

Simon

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

> anyone write a site scraper?  Feel like sharing it so I don't have to write
> it?
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>and did a little diving.
> And God said, "This is good."
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 

Carpe diem

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

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

[Richmond]

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

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

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

neither as passive-agressively , nor  not accepted.


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

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




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


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

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

Re: iOS9, AppleTV OS, WatchOS 2

[Richmond]

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

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


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

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

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

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

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

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

Best,

Steve MacLean



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

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


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

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


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


http://www.ubuntu.com/phone




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


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

to function and/or look appropriate on different platforms.


Knowing about support for these products makes decisions actionable.

Agreed.

~Roger
___



Richmond.

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

Re: LiveCode repo name change fixer

[Richard Gaskin]

Monte Goulding wrote:

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

Thanks for that background.

Ali, Peter: can you offer any insight on those submodules?

--
 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: This Is Why We Can't Have Nice Things

[Monte Goulding]

> On 10 Sep 2015, at 11:36 am, Monte Goulding  
> wrote:
> 
>> As an aside, I believe Monte's lcvcs system involves a binary diff mechanism 
>> for comparing two stacks.
> 
> No there’s no binary diff in lcvcs although it wouldn’t be hard to build 
> something that created a repo, export the original stack file and commit it 
> then export the new version and commit changes so you can review the diffs.

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

Hope this helps

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: LiveCode repo name change fixer

[Monte Goulding]

> On 10 Sep 2015, at 1:06 pm, Richard Gaskin  wrote:
> 
> > I also saw the email notice on the fact that we can expect a lot more
> > submodules in the future to deal with widgets. Not something I'm
> > looking forward to.
> 
> What are your concerns?

The issue with submodules is just a workflow thing. You’ve got to remember to 
commit changes to the submodule before you commit to the main repo because the 
commit on the main repo contains a reference to the commit on the submodule. In 
general submodules that you don’t maintain and just update every now and then 
are a godsend. Submodules in the one project that share branch names etc like 
the ide and thirdparty ones in the livecode repo not so much… I’m actually not 
all that sure why these were made submodules in the first place. I’m fairly 
sure we discussed it back when it was all originally pushed but it I can’t 
remember… 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LiveCode repo name change fixer

[Richard Gaskin]

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

What are your concerns?

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

site scraper

[Mike Kerner]

anyone write a site scraper?  Feel like sharing it so I don't have to write
it?

-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Accessing the Foundation library with LiveCode Builder

[JB]

This is excellent!

Thank you and please let us
know when you post more
examples.

John Balgenorth


On Sep 8, 2015, at 11:35 PM, Peter TB Brett  wrote:

> Hi all,
> 
> Just taking a quick break from my holiday to let you know that I wrote 
> another LiveCode Builder-centric blog post. This one's about using LCB 
> "foreign" handlers to access functions in LiveCode's libfoundation library.
> 
> http://blog.peter-b.co.uk/2015/09/foundation-library-livecode-builder.html
> 
> Peter
> -- 
> Dr Peter Brett 
> LiveCode Open Source 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
> 


___
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

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

[Mark Rauterkus]

Hi All,

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

Wondering.

--
Ta.


Mark Rauterkus   m...@rauterkus.com
PPS Summer Dreamers' Swim & Water Polo Camp Executive Coach
Varsity Boys Swim Coach, Pittsburgh Obama Academy
Recent Head Water Polo Coach, Carnegie Mellon University Women's Club Team
Pittsburgh Combined Water Polo Team

http://CLOH.org

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

Re: iOS9, AppleTV OS, WatchOS 2

[Stephen MacLean]

> On Sep 9, 2015, at 4:25 PM, Roger Eller  wrote:
> 
> On Wed, Sep 9, 2015 at 4:02 PM, Stephen MacLean 
> wrote:
> 
>> I mention this most every time after an Apple event, but it’s becoming
>> more and more relevant each time… LiveCode support?
>> 
>> How ready is LC for iOS9? It’s coming in a week. iOS 8 broke a lot of my
>> stuff, would have been nice to be able to test ahead of time.
>> 
>> AppleTV OS. New, based on iOS. Will there be support for it?
>> 
>> WatchOS 2. Now supports native apps. Will LC now support it? LCB only
>> style app?
>> 
>> This isn’t an Apple Vs. Android argument, everyone has their own opinions
>> and stats. It’s about new, relevant products and bringing your apps to
>> those products.
>> 
>> LiveCode’s write once - deploy anywhere model makes it desirable. Knowing
>> about support for these products makes decisions actionable.
>> 
>> Best,
>> 
>> Steve MacLean
>> 
> 
> 
> Since you mention these things while the event is still warm, I'll throw in
> my wishes for more mobile OS parity.
> 
> Windows 8.1 tablets/phones … LiveCode support?
> Android 5.1 … LiveCode support?
> Android Wear … LiveCode support?
> Android Wear 2 … LiveCode support?
> Build as an Android Widget … LiveCode support?
> Android Auto … LiveCode support?
> 

I would like these as well.

>> This isn’t an Apple Vs. Android argument...
> 
> No it's not.  But we need to be able to build for the sub-technologies of
> Android in addition to just phones.

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


I just want to know if we will have support for my above list and if the answer 
is yes, then when.

Best,

Steve MacLean



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

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

[Monte Goulding]

> On 10 Sep 2015, at 11:23 am, Mark Wieder  wrote:
> 
> As an aside, I believe Monte's lcvcs system involves a binary diff mechanism 
> for comparing two stacks.

No there’s no binary diff in lcvcs although it wouldn’t be hard to build 
something that created a repo, export the original stack file and commit it 
then export the new version and commit changes so you can review the diffs.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LiveCode repo name change fixer

[Mark Wieder]

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


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


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

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

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

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

[Mark Wieder]

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


I'm sorry you felt it was passive-aggressively not accepted. It was meant
neither as passive-agressively , nor  not accepted.


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

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


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

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

Re: LiveCode repo name change fixer

[Monte Goulding]

> On 10 Sep 2015, at 11:07 am, Mark Wieder  wrote:
> 
> It appears to be written as a script-only stack for LC8. Since I ran this in 
> LC6.7.5, I just copied the script minus the first line into the card script. 
> That almost ran properly, only causing a harmless error on the final line of 
> the preOpenCard handler. If I would have moved the preOpenCard handler into 
> the stack script that would have worked.
> 
> But it otherwise did the job on linux.

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

Cheers

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

Re: iOS9, AppleTV OS, WatchOS 2

[Roger Eller]

Multitasking is already present, and split screen layout is in dev preview
3.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[Mark Wieder]

On 09/09/2015 01:10 AM, Mark Waddingham wrote:


I think you should perhaps look at the title of your post for an example
of passive-aggressiveness, rather than Ali's perfectly measured and
appropriate response to your pull request :)





In regards to binary stackfile contributions - I'm sorry but we simply
cannot accept them at this time. I think the community would be rather
unhappy if we did accept a binary stackfile contribution in which
someone had planted something nefarious that we did not see and ended up
adversely affecting their local systems on install in some heinous way.


Yes. This has been one of the main problems with that monolithic stack 
structure from the very beginning. (Don't tell Kevin I mentioned *that* 
word)



Now, I'm not saying there is not a solution to this - but we don't have
one right now. How far off is a solution? I honestly don't know.

So, it seems to me, the best solution *right now* is that we all work on
the develop branch and therefore LC8. The develop branch IDE has a
substantial number of script only stacks which makes contribution (and
also in house changes - I should add!) a lot lot easier and more
transparent *and* it is only one branch to focus on so if a binary
change is required, a LiveCode engineer only has to go through and do
the necessary work once (which, I'd point out Ali quite happily did with
the contribution in question).


Well, I'm not going to try to manage the project for you. You all are in 
a much better position to decide what's best for us. I will say, though, 
that it's more than a bit frustrating that two and half years after the 
initial open source release there's still no mechanism in place for 
accepting arbitrary IDE stack changes. I would have thought that more 
resources devoted to scriptifying more of the IDE stacks would result in 
offloading tasks from the internal team, get more long-standing bugs 
fixed, and ease the process of adding new features.


As an aside, I believe Monte's lcvcs system involves a binary diff 
mechanism for comparing two stacks.


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

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

Re: LiveCode repo name change fixer

[Mark Wieder]

On 09/09/2015 05:20 PM, Monte Goulding wrote:

Hi Folks

Some of you may know that all the references to RunRev and Runtime revolution 
are being cleaned out and the github account has changed from runrev to 
livecode. This means all our clones are broken so to save everyone some time I 
made a stack that will fix it for you. Here it is:

https://gist.github.com/montegoulding/2cc4ca9f2df14100a2bf 



Thanks. Yeah, I saw a flurry of email notices.


It also fixes the submodules to point to your submodule forks as origin and the 
livecode one as upstream in case you ever want to contribute a change to those 
repos (ducks for cover).


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



Only tested on OS X but it will work on Linux and *should* work on Windows 
presuming you have installed git commands for the command line and not just 
under git bash.


It appears to be written as a script-only stack for LC8. Since I ran 
this in LC6.7.5, I just copied the script minus the first line into the 
card script. That almost ran properly, only causing a harmless error on 
the final line of the preOpenCard handler. If I would have moved the 
preOpenCard handler into the stack script that would have worked.


But it otherwise did the job on linux.

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

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

LiveCode repo name change fixer

[Monte Goulding]

Hi Folks

Some of you may know that all the references to RunRev and Runtime revolution 
are being cleaned out and the github account has changed from runrev to 
livecode. This means all our clones are broken so to save everyone some time I 
made a stack that will fix it for you. Here it is:

https://gist.github.com/montegoulding/2cc4ca9f2df14100a2bf 


It also fixes the submodules to point to your submodule forks as origin and the 
livecode one as upstream in case you ever want to contribute a change to those 
repos (ducks for cover).

Only tested on OS X but it will work on Linux and *should* work on Windows 
presuming you have installed git commands for the command line and not just 
under git bash.

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

FacebookLib and Facebook App

[Dan Friedman]

Greetings!

Has anyone successfully created a Facebook App that will run with Andre's 
FacebookLib?   I can't seem to get the Facebook App configured correctly.  I 
get errors and unsuccessful results.   I had a few eMails with Andre, and he 
suspects that the Facebook App is setup incorrectly.  Anyone know about this 
stuff?

ANY advice is greatly appreciated!

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

Re: iOS9, AppleTV OS, WatchOS 2

[Mike Kerner]

Will non-apple apps be able to do the multi-tasking/split screen?  That
would be nice...

On Wed, Sep 9, 2015 at 4:25 PM, Roger Eller 
wrote:

> On Wed, Sep 9, 2015 at 4:02 PM, Stephen MacLean 
> wrote:
>
> > I mention this most every time after an Apple event, but it’s becoming
> > more and more relevant each time… LiveCode support?
> >
> > How ready is LC for iOS9? It’s coming in a week. iOS 8 broke a lot of my
> > stuff, would have been nice to be able to test ahead of time.
> >
> > AppleTV OS. New, based on iOS. Will there be support for it?
> >
> > WatchOS 2. Now supports native apps. Will LC now support it? LCB only
> > style app?
> >
> > This isn’t an Apple Vs. Android argument, everyone has their own opinions
> > and stats. It’s about new, relevant products and bringing your apps to
> > those products.
> >
> > LiveCode’s write once - deploy anywhere model makes it desirable. Knowing
> > about support for these products makes decisions actionable.
> >
> > Best,
> >
> > Steve MacLean
> >
>
>
> Since you mention these things while the event is still warm, I'll throw in
> my wishes for more mobile OS parity.
>
> Windows 8.1 tablets/phones … LiveCode support?
> Android 5.1 … LiveCode support?
> Android Wear … LiveCode support?
> Android Wear 2 … LiveCode support?
> Build as an Android Widget … LiveCode support?
> Android Auto … LiveCode support?
>
> > This isn’t an Apple Vs. Android argument...
>
> No it's not.  But we need to be able to build for the sub-technologies of
> Android in addition to just phones.
>
> > LiveCode’s write once - deploy anywhere model makes it desirable.
> > Knowing about support for these products makes decisions actionable.
>
> Agreed.
>
> ~Roger
> ___
> 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: iOS9, AppleTV OS, WatchOS 2

[Roger Eller]

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

> I mention this most every time after an Apple event, but it’s becoming
> more and more relevant each time… LiveCode support?
>
> How ready is LC for iOS9? It’s coming in a week. iOS 8 broke a lot of my
> stuff, would have been nice to be able to test ahead of time.
>
> AppleTV OS. New, based on iOS. Will there be support for it?
>
> WatchOS 2. Now supports native apps. Will LC now support it? LCB only
> style app?
>
> This isn’t an Apple Vs. Android argument, everyone has their own opinions
> and stats. It’s about new, relevant products and bringing your apps to
> those products.
>
> LiveCode’s write once - deploy anywhere model makes it desirable. Knowing
> about support for these products makes decisions actionable.
>
> Best,
>
> Steve MacLean
>


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

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

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

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

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

Agreed.

~Roger
___
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

iOS9, AppleTV OS, WatchOS 2

[Stephen MacLean]

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

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

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

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

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

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

Best,

Steve MacLean



___
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: Window decorations and the effective rect issue

[Paul Dupuis]

On 9/9/2015 2:32 PM, Richard Gaskin wrote:
> Paul Dupuis wrote:
> > However, I have run into a puzzler. Under Windows 8 (and Win 7) when I
> > set the effective rect of a stack to 0,0,x,y or set the effective
> > topLeft of a stack to 0,0, that stack is NOT taking into account the
> > wider window borders of Windows 7 and 8 and is positioning the stack
> > with part of its borders off screen - it is like the stack thinks it's
> > window borders were the thinner ones back under Windows 2000 or XP!
> >
> > This only occur with old stacks in the application - i.e. stacks
> > originally migrated from HyperCard > SuperCard > Metacard >Revolution.
> > If I create a new "Untitled 1" substack in the old legacy mainstack
> > and set it's effective topLeft to 0,0, it renders exactly as expected.
>
> On Ubuntu difference there is a meaningless (though seemingly
> non-random) difference between a stack's "rect" and its "effective rect":
> 
>
> Maybe whatever made "effective rect" broken on Linux is related to
> what you're seeing in Windows?
>
> Possibly not, though:  the Linux bug is evident with all stacks, old
> or new.
>
Richard,

Thanks for the tip on the bug entry. It led me to try the same message
box test. In this case 'put the effective rect of stack "hrMenubar" &&
the rect of stack "hrMenubar" returns numbers that are not nonsense:
0,0,1366,59 3,26,1363,56. It does illustrate that, even though it is
running under Windows 8, Livecode 6.7.6 thinks the border is only 3px!
For contrast, the same test in a new Untitled substack in same mainstack
as the "hrMenubar substack, produces 12,138,428,577 20,169,420,569 which
has the correct Windows 8 border width of 8px.

I think Mark is probably right, it may be some internal property set as
part of the imports of the stacks. I'll try to strip it down to just a
single substack to illustrate the issue and send it to LiveCode.

Thanks again,

___
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: Window decorations and the effective rect issue

[Scott Rossi]

Thanks Paul, good to know.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 9/9/15, 11:43 AM, "Paul Dupuis"  wrote:

>Scott,
>
>See the dictionary entry for "rectangle". There is a specific note that,
>as of LC6, the effective rect of a stack includes its decorations and
>window borders and is also settable. IMHO it was one of the best new
>features of LC6+. What I did nto realize, but discovered this week was
>that you can also get and set the effective topLeft, top, height, width,
>left, bottom, etc. etc, of a stack and the value will factor in the
>window decorations and borders. It is really handy!
>
>set the height of stack "X" to tSomevalue -- based on its contents i.e.
>it's inside dimensions
>get the effective height of stack "X" -- will now tell you the resulting
>outside dimensions after adjusting for the inside change!
>OR Vice Versa
>set the effective height of stack "X" to tSomevalue -- set the stack's
>outside height
>get the height of stack "X" -- will now tell you the resulting inside
>height you have to work with!
>
>
>On 9/9/2015 2:19 PM, Scott Rossi wrote:
>> Dumb comment/question on my part: I always thought the effective keyword
>> was for reading only -- didn't think it was settable.  From the docs:
>>
>> The effective keyword is implemented internally as a property and
>>appears
>> in the propertyNames. However, it cannot be used as a prop in an
>> expression, nor with the set com.
>>
>>
>> (Guessing that last word was supposed to be "command").
>>
>> Is there something that says explicitly you can set the "effective"
>> property of anything?
>>
>> Regards,
>>
>> Scott Rossi
>> Creative Director
>> Tactile Media, UX/UI Design
>>
>>
>>
>>
>> On 9/9/15, 11:11 AM, "Paul Dupuis"  wrote:
>>
>>> I have an application (main stack + many substacks + several external
>>> stacks) that is ancient (originally built in HyperCard, ported to
>>> Supercard, ported to Metacard, and on up to LiveCode 6.7.6.
>>>
>>> I was working on redoing some of the legacy screen layout code today -
>>> taking advantage of 'the working screenrect' (working didn't exist way
>>> back when) and 'the effective rect' of a stack (effective wasn't
>>> available either)
>>> A multi-window layout should now be as easy as get the working
>>> screenrect and divide it up and set the effective rect of the stacks
>>> (windows) to the divided up values. No more fudge factors for varying
>>>OS
>>> window borders and title bars and such. Yea!
>>>
>>> However, I have run into a puzzler. Under Windows 8 (and Win 7) when I
>>> set the effective rect of a stack to 0,0,x,y or set the effective
>>> topLeft of a stack to 0,0, that stack is NOT taking into account the
>>> wider window borders of Windows 7 and 8 and is positioning the stack
>>> with part of its borders off screen - it is like the stack thinks it's
>>> window borders were the thinner ones back under Windows 2000 or XP!
>>>
>>> This only occur with old stacks in the application - i.e. stacks
>>> originally migrated from HyperCard > SuperCard > Metacard >Revolution.
>>> If I create a new "Untitled 1" substack in the old legacy mainstack and
>>> set it's effective topLeft to 0,0, it renders exactly as expected.
>>>
>>> I tried cloning (as in "clone stack " one of the legacy stacks
>>>and
>>> it also thinks it has thinner window borders that it really does.
>>>
>>> All these stacks have been saved from LC676 in the latest stack format
>>> (the were previously in LC464). I created a new test mainstak and
>>> substack in LC676 and the effective keyword works exactly as expected
>>> with stacks. I also created an identical test stack under LC464 (the
>>> oldest version I have) and the tried that under LC676 and it works
>>> exactly as expected.
>>>
>>> I just appears to be really ancient stacks that have been
>>> imported/migrated rather than any new stacks. Has anyone seen anything
>>> like this?
>>>
>>> I'd rather not have to recreate each of these legacy stack by creating
>>>a
>>> new "Untitled" stack and populating all the objects, scripts,
>>> properties, etc, to fix this issue.
>>>
>>> Paul Dupuis
>>> Researchware
>>>
>>> ___
>>> 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: Window decorations and the effective rect issue

[Paul Dupuis]

Scott,

See the dictionary entry for "rectangle". There is a specific note that,
as of LC6, the effective rect of a stack includes its decorations and
window borders and is also settable. IMHO it was one of the best new
features of LC6+. What I did nto realize, but discovered this week was
that you can also get and set the effective topLeft, top, height, width,
left, bottom, etc. etc, of a stack and the value will factor in the
window decorations and borders. It is really handy!

set the height of stack "X" to tSomevalue -- based on its contents i.e.
it's inside dimensions
get the effective height of stack "X" -- will now tell you the resulting
outside dimensions after adjusting for the inside change!
OR Vice Versa
set the effective height of stack "X" to tSomevalue -- set the stack's
outside height
get the height of stack "X" -- will now tell you the resulting inside
height you have to work with!


On 9/9/2015 2:19 PM, Scott Rossi wrote:
> Dumb comment/question on my part: I always thought the effective keyword
> was for reading only -- didn't think it was settable.  From the docs:
>
> The effective keyword is implemented internally as a property and appears
> in the propertyNames. However, it cannot be used as a prop in an
> expression, nor with the set com.
>
>
> (Guessing that last word was supposed to be "command").
>
> Is there something that says explicitly you can set the "effective"
> property of anything?
>
> Regards,
>
> Scott Rossi
> Creative Director
> Tactile Media, UX/UI Design
>
>
>
>
> On 9/9/15, 11:11 AM, "Paul Dupuis"  wrote:
>
>> I have an application (main stack + many substacks + several external
>> stacks) that is ancient (originally built in HyperCard, ported to
>> Supercard, ported to Metacard, and on up to LiveCode 6.7.6.
>>
>> I was working on redoing some of the legacy screen layout code today -
>> taking advantage of 'the working screenrect' (working didn't exist way
>> back when) and 'the effective rect' of a stack (effective wasn't
>> available either)
>> A multi-window layout should now be as easy as get the working
>> screenrect and divide it up and set the effective rect of the stacks
>> (windows) to the divided up values. No more fudge factors for varying OS
>> window borders and title bars and such. Yea!
>>
>> However, I have run into a puzzler. Under Windows 8 (and Win 7) when I
>> set the effective rect of a stack to 0,0,x,y or set the effective
>> topLeft of a stack to 0,0, that stack is NOT taking into account the
>> wider window borders of Windows 7 and 8 and is positioning the stack
>> with part of its borders off screen - it is like the stack thinks it's
>> window borders were the thinner ones back under Windows 2000 or XP!
>>
>> This only occur with old stacks in the application - i.e. stacks
>> originally migrated from HyperCard > SuperCard > Metacard >Revolution.
>> If I create a new "Untitled 1" substack in the old legacy mainstack and
>> set it's effective topLeft to 0,0, it renders exactly as expected.
>>
>> I tried cloning (as in "clone stack " one of the legacy stacks and
>> it also thinks it has thinner window borders that it really does.
>>
>> All these stacks have been saved from LC676 in the latest stack format
>> (the were previously in LC464). I created a new test mainstak and
>> substack in LC676 and the effective keyword works exactly as expected
>> with stacks. I also created an identical test stack under LC464 (the
>> oldest version I have) and the tried that under LC676 and it works
>> exactly as expected.
>>
>> I just appears to be really ancient stacks that have been
>> imported/migrated rather than any new stacks. Has anyone seen anything
>> like this?
>>
>> I'd rather not have to recreate each of these legacy stack by creating a
>> new "Untitled" stack and populating all the objects, scripts,
>> properties, etc, to fix this issue.
>>
>> Paul Dupuis
>> Researchware
>>
>> ___
>> 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: Window decorations and the effective rect issue

[Richard Gaskin]

Paul Dupuis wrote:
> However, I have run into a puzzler. Under Windows 8 (and Win 7) when I
> set the effective rect of a stack to 0,0,x,y or set the effective
> topLeft of a stack to 0,0, that stack is NOT taking into account the
> wider window borders of Windows 7 and 8 and is positioning the stack
> with part of its borders off screen - it is like the stack thinks it's
> window borders were the thinner ones back under Windows 2000 or XP!
>
> This only occur with old stacks in the application - i.e. stacks
> originally migrated from HyperCard > SuperCard > Metacard >Revolution.
> If I create a new "Untitled 1" substack in the old legacy mainstack
> and set it's effective topLeft to 0,0, it renders exactly as expected.

On Ubuntu difference there is a meaningless (though seemingly 
non-random) difference between a stack's "rect" and its "effective rect":



Maybe whatever made "effective rect" broken on Linux is related to what 
you're seeing in Windows?


Possibly not, though:  the Linux bug is evident with all stacks, old or new.

--
 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: Window decorations and the effective rect issue

[Mark Waddingham]

This sounds like there's a legacy flag on those older stacks but I'm not sure 
what it might be.

If you file a bug report and attach one of the stacks or send one to Hanson 
we'll take a look.

Mark.

Sent from my iPhone

> On 9 Sep 2015, at 19:11, Paul Dupuis  wrote:
> 
> I have an application (main stack + many substacks + several external
> stacks) that is ancient (originally built in HyperCard, ported to
> Supercard, ported to Metacard, and on up to LiveCode 6.7.6.
> 
> I was working on redoing some of the legacy screen layout code today -
> taking advantage of 'the working screenrect' (working didn't exist way
> back when) and 'the effective rect' of a stack (effective wasn't
> available either)
> A multi-window layout should now be as easy as get the working
> screenrect and divide it up and set the effective rect of the stacks
> (windows) to the divided up values. No more fudge factors for varying OS
> window borders and title bars and such. Yea!
> 
> However, I have run into a puzzler. Under Windows 8 (and Win 7) when I
> set the effective rect of a stack to 0,0,x,y or set the effective
> topLeft of a stack to 0,0, that stack is NOT taking into account the
> wider window borders of Windows 7 and 8 and is positioning the stack
> with part of its borders off screen - it is like the stack thinks it's
> window borders were the thinner ones back under Windows 2000 or XP!
> 
> This only occur with old stacks in the application - i.e. stacks
> originally migrated from HyperCard > SuperCard > Metacard >Revolution.
> If I create a new "Untitled 1" substack in the old legacy mainstack and
> set it's effective topLeft to 0,0, it renders exactly as expected.
> 
> I tried cloning (as in "clone stack " one of the legacy stacks and
> it also thinks it has thinner window borders that it really does.
> 
> All these stacks have been saved from LC676 in the latest stack format
> (the were previously in LC464). I created a new test mainstak and
> substack in LC676 and the effective keyword works exactly as expected
> with stacks. I also created an identical test stack under LC464 (the
> oldest version I have) and the tried that under LC676 and it works
> exactly as expected.
> 
> I just appears to be really ancient stacks that have been
> imported/migrated rather than any new stacks. Has anyone seen anything
> like this?
> 
> I'd rather not have to recreate each of these legacy stack by creating a
> new "Untitled" stack and populating all the objects, scripts,
> properties, etc, to fix this issue.
> 
> Paul Dupuis
> Researchware
> 
> ___
> 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: Window decorations and the effective rect issue

[Scott Rossi]

Dumb comment/question on my part: I always thought the effective keyword
was for reading only -- didn't think it was settable.  From the docs:

The effective keyword is implemented internally as a property and appears
in the propertyNames. However, it cannot be used as a prop in an
expression, nor with the set com.


(Guessing that last word was supposed to be "command").

Is there something that says explicitly you can set the "effective"
property of anything?

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 9/9/15, 11:11 AM, "Paul Dupuis"  wrote:

>I have an application (main stack + many substacks + several external
>stacks) that is ancient (originally built in HyperCard, ported to
>Supercard, ported to Metacard, and on up to LiveCode 6.7.6.
>
>I was working on redoing some of the legacy screen layout code today -
>taking advantage of 'the working screenrect' (working didn't exist way
>back when) and 'the effective rect' of a stack (effective wasn't
>available either)
>A multi-window layout should now be as easy as get the working
>screenrect and divide it up and set the effective rect of the stacks
>(windows) to the divided up values. No more fudge factors for varying OS
>window borders and title bars and such. Yea!
>
>However, I have run into a puzzler. Under Windows 8 (and Win 7) when I
>set the effective rect of a stack to 0,0,x,y or set the effective
>topLeft of a stack to 0,0, that stack is NOT taking into account the
>wider window borders of Windows 7 and 8 and is positioning the stack
>with part of its borders off screen - it is like the stack thinks it's
>window borders were the thinner ones back under Windows 2000 or XP!
>
>This only occur with old stacks in the application - i.e. stacks
>originally migrated from HyperCard > SuperCard > Metacard >Revolution.
>If I create a new "Untitled 1" substack in the old legacy mainstack and
>set it's effective topLeft to 0,0, it renders exactly as expected.
>
>I tried cloning (as in "clone stack " one of the legacy stacks and
>it also thinks it has thinner window borders that it really does.
>
>All these stacks have been saved from LC676 in the latest stack format
>(the were previously in LC464). I created a new test mainstak and
>substack in LC676 and the effective keyword works exactly as expected
>with stacks. I also created an identical test stack under LC464 (the
>oldest version I have) and the tried that under LC676 and it works
>exactly as expected.
>
>I just appears to be really ancient stacks that have been
>imported/migrated rather than any new stacks. Has anyone seen anything
>like this?
>
>I'd rather not have to recreate each of these legacy stack by creating a
>new "Untitled" stack and populating all the objects, scripts,
>properties, etc, to fix this issue.
>
>Paul Dupuis
>Researchware
>
>___
>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

Window decorations and the effective rect issue

[Paul Dupuis]

I have an application (main stack + many substacks + several external
stacks) that is ancient (originally built in HyperCard, ported to
Supercard, ported to Metacard, and on up to LiveCode 6.7.6.

I was working on redoing some of the legacy screen layout code today -
taking advantage of 'the working screenrect' (working didn't exist way
back when) and 'the effective rect' of a stack (effective wasn't
available either)
A multi-window layout should now be as easy as get the working
screenrect and divide it up and set the effective rect of the stacks
(windows) to the divided up values. No more fudge factors for varying OS
window borders and title bars and such. Yea!

However, I have run into a puzzler. Under Windows 8 (and Win 7) when I
set the effective rect of a stack to 0,0,x,y or set the effective
topLeft of a stack to 0,0, that stack is NOT taking into account the
wider window borders of Windows 7 and 8 and is positioning the stack
with part of its borders off screen - it is like the stack thinks it's
window borders were the thinner ones back under Windows 2000 or XP!

This only occur with old stacks in the application - i.e. stacks
originally migrated from HyperCard > SuperCard > Metacard >Revolution.
If I create a new "Untitled 1" substack in the old legacy mainstack and
set it's effective topLeft to 0,0, it renders exactly as expected.

I tried cloning (as in "clone stack " one of the legacy stacks and
it also thinks it has thinner window borders that it really does.

All these stacks have been saved from LC676 in the latest stack format
(the were previously in LC464). I created a new test mainstak and
substack in LC676 and the effective keyword works exactly as expected
with stacks. I also created an identical test stack under LC464 (the
oldest version I have) and the tried that under LC676 and it works
exactly as expected.

I just appears to be really ancient stacks that have been
imported/migrated rather than any new stacks. Has anyone seen anything
like this?

I'd rather not have to recreate each of these legacy stack by creating a
new "Untitled" stack and populating all the objects, scripts,
properties, etc, to fix this issue.

Paul Dupuis
Researchware

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

Re: BBEdit/Textwrangler LCM for livescript

[Peter Haworth]

Hi Thierry,
I did as you suggested but not seeing any difference with code folding,
still just commands and functions are foldable.

On Wed, Sep 9, 2015 at 9:04 AM James Hale  wrote:

> Thierry wrote:
> >
> > Replace the key 'Function Pattern' with the one below
> > and you might have a surprise with code folding..
>
> Well I did and it works in BBEdit. Not sure what the surprise is though,
> unless you have something in mind with the two unused named patterns.
>
> I also used it in a modified LiveCode Builder CLM and it works a treat
> there (I couldn't get my mod to work correctly)
>
>
> Function Pattern
> 
>
> So thank you very much!
>
> I have now updated the livescript CLM with Thierry's mod and a fix for
> controls not appearing in the text color prefs.
>
> I have also added my modified LiveCode Builder CLM which includes many
> more keywords (thanks Ali) broken into their "Types" as specified in the
> docs.
> As with the livescript version due to the need to break keywords into
> single word entities some of my choices in eliminating duplicates may not
> be truly correct, but its a minor glitch.
>
> The files can be obtained...
>
> https://dl.dropboxusercontent.com/u/8212901/LiveCodeBuilder.plist <
> https://dl.dropboxusercontent.com/u/8212901/LiveCodeBuilder.plist>
>
> https://dl.dropboxusercontent.com/u/8212901/Livescript.plist <
> https://dl.dropboxusercontent.com/u/8212901/Livescript.plist>
>
>
>
> James
>
> (looking forward to Thierry's next post)
>
>
>
> ___
> 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: BBEdit/Textwrangler LCM for livescript

[James Hale]

Thierry wrote:
> 
> Replace the key 'Function Pattern' with the one below
> and you might have a surprise with code folding..

Well I did and it works in BBEdit. Not sure what the surprise is though, unless 
you have something in mind with the two unused named patterns.

I also used it in a modified LiveCode Builder CLM and it works a treat there (I 
couldn't get my mod to work correctly)


Function Pattern


So thank you very much!

I have now updated the livescript CLM with Thierry's mod and a fix for controls 
not appearing in the text color prefs.

I have also added my modified LiveCode Builder CLM which includes many more 
keywords (thanks Ali) broken into their "Types" as specified in the docs.
As with the livescript version due to the need to break keywords into single 
word entities some of my choices in eliminating duplicates may not be truly 
correct, but its a minor glitch.

The files can be obtained...

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


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




James

(looking forward to Thierry's next post)



___
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: curling twilio API

[David Williams]

Hi Jose,

Off the top of my head, this would probably look something like the  
following in LC:


post tPostString to  
url("https://AC0afb9e5c70c0fde47904a9a6ff:e6a1bdc2a7a7484d6cdc96e@api*twilio*com/2010-04-01/Accounts/AC0afb9e5c70c0fde47904a9a6ff/Messages.json";)


Where tPostString contains the post fields concatenated by & (for the  
example you posted):


To=5034554562&From=+1212022183&Body=test message

You can just sidestep this whole thing if you're on OSX/Linux by accessing  
curl directly with shell():


get shell("curl -X POST   
'https://api*twilio*com/2010-04-01/Accounts/AC0afb9e5c70c0fde47904a9a6ff/Messages.json'  
--data-urlencode 'To=5034554562' --data-urlencode 'From=+1212022183'  
--data-urlencode 'Body=test message' -u  
AC0afb9e5c70c0fde47904a9a6ff:e6a1bdc2a7a7484d6cdc96e")


I would also strongly advise against posting your API keys publicly and  
recommend you change the one you just posted, as there are bots which  
crawl the public-facing web for such keys.


-David

On Wed, 09 Sep 2015 12:24:19 +0100, Jose Damaso  wrote:


Hi all - can someone help me convert the following?

curl -X POST  
'https://api*twilio*com/2010-04-01/Accounts/AC0afb9e5c70c0fde47904a9a6ff/Messages.json'

\
--data-urlencode 'To=5034554562' \
--data-urlencode 'From=+1212022183' \
--data-urlencode 'Body=test message' \
-u AC0afb9e5c70c0fde47904a9a6ff:e6a1bdc2a7a7484d6cdc96e

I just don't have any experience working with http(s) APIs and I've been
working through the forum posts as best I can. The only thing I've  
gathered

so far is using urlEncode for the --data-urlencode lines. Are the -X POST
and -u parts done in httpheaders?

Any help would be greatly appreciated - thanks!
___
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



--
Using Opera's mail client: http://www.opera.com/mail/

___
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: Silly conference survey

[Richmond]

On 09/09/2015 01:41 PM, Mark Waddingham wrote:

The survey asked if one were likely to attend; but as the choice of
where one could attend was restricted the results would be
like a self-fulfilling prophecy.


Err - no - we had a shortlist of areas in which we know we could 
afford to run a conference based on the data that we have (i.e. get 
enough people to buy tickets to attend so that we can pay for the thing).


The survey was about finding out which of those was likely to be the 
most successful (in terms of a bums on seats metric).



Had you offered, say, Munich or somewhere on the Pacific rim
(Shanghai???) you might have got quite a few people to say they might
attend; but by restricting the choices you will never know.


Indeed, we could have given a list of an arbitrary number of places - 
Munich, Shanghai, Outer Hebrides, Tristan da Cunha, Nuaha...


However all that would have done would be to reduce the focus of the 
survey, meaning results would have been spread making it substantially 
less useful.


How do we know this? Because we've run surveys for conferences like 
that in the past and they didn't really give us the information we 
really needed because they were not focused and/or specific enough.


Mark.



Aha.

Thanks.

Richmond.

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

curling twilio API

[Jose Damaso]

Hi all - can someone help me convert the following?

curl -X POST 
'https://api*twilio*com/2010-04-01/Accounts/AC0afb9e5c70c0fde47904a9a6ff/Messages.json'
\
--data-urlencode 'To=5034554562' \
--data-urlencode 'From=+1212022183' \
--data-urlencode 'Body=test message' \
-u AC0afb9e5c70c0fde47904a9a6ff:e6a1bdc2a7a7484d6cdc96e

I just don't have any experience working with http(s) APIs and I've been
working through the forum posts as best I can. The only thing I've gathered
so far is using urlEncode for the --data-urlencode lines. Are the -X POST
and -u parts done in httpheaders?

Any help would be greatly appreciated - thanks!
___
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: Silly conference survey

[Ali Lloyd]

> Indeed, we could have given a list of an arbitrary number of places -
> Munich, Shanghai, Outer Hebrides, *Tristan da Cunha*, Nuaha...

LiveCode Conference to be held in Edinburgh*!









*of the seven seas

On Wed, Sep 9, 2015 at 11:41 AM Mark Waddingham  wrote:

> > The survey asked if one were likely to attend; but as the choice of
> > where one could attend was restricted the results would be
> > like a self-fulfilling prophecy.
>
> Err - no - we had a shortlist of areas in which we know we could afford
> to run a conference based on the data that we have (i.e. get enough
> people to buy tickets to attend so that we can pay for the thing).
>
> The survey was about finding out which of those was likely to be the
> most successful (in terms of a bums on seats metric).
>
> > Had you offered, say, Munich or somewhere on the Pacific rim
> > (Shanghai???) you might have got quite a few people to say they might
> > attend; but by restricting the choices you will never know.
>
> Indeed, we could have given a list of an arbitrary number of places -
> Munich, Shanghai, Outer Hebrides, Tristan da Cunha, Nuaha...
>
> However all that would have done would be to reduce the focus of the
> survey, meaning results would have been spread making it substantially
> less useful.
>
> How do we know this? Because we've run surveys for conferences like that
> in the past and they didn't really give us the information we really
> needed because they were not focused and/or specific enough.
>
> Mark.
>
> --
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Silly conference survey

[Mark Waddingham]

The survey asked if one were likely to attend; but as the choice of
where one could attend was restricted the results would be
like a self-fulfilling prophecy.


Err - no - we had a shortlist of areas in which we know we could afford 
to run a conference based on the data that we have (i.e. get enough 
people to buy tickets to attend so that we can pay for the thing).


The survey was about finding out which of those was likely to be the 
most successful (in terms of a bums on seats metric).



Had you offered, say, Munich or somewhere on the Pacific rim
(Shanghai???) you might have got quite a few people to say they might
attend; but by restricting the choices you will never know.


Indeed, we could have given a list of an arbitrary number of places - 
Munich, Shanghai, Outer Hebrides, Tristan da Cunha, Nuaha...


However all that would have done would be to reduce the focus of the 
survey, meaning results would have been spread making it substantially 
less useful.


How do we know this? Because we've run surveys for conferences like that 
in the past and they didn't really give us the information we really 
needed because they were not focused and/or specific enough.


Mark.

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

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

Re: Silly conference survey

[Richmond]

On 09/09/2015 11:30 AM, Mark Waddingham wrote:

I do think, even if only as a sop to those of us (like myself) who get
fed up how RunRev, for all their ballyhoo about China and so forth,
do seem to give the impression that they don't really seem to think
outside a North Atlantic box, the survey would have looked a bit
more friendly if it had left a chance open for participants to suggest
other cities in other states/countries than those forced as choices
on participants.


To be blunt Richmond, it doesn't take a great deal of thought to 
understand *why* there is a restricted choice. Indeed, I think people 
before me have already explained adequately why. However, let me 
reiterate in perhaps slightly more detail:


The point of a conference is that people attend.

If people are to go to a conference then they need to be able to 
afford to do so.


If you hold a conference somewhere where the cost to get there exceeds 
someone's ability to pay those costs, they won't go.


If you hold a conference somewhere where the ticket price has to 
exceed someone's ability to pay that cost, they won't go.


Therefore, you need to ensure that you hold the conference in a 
location where the most number of people who are likely to attend can 
attend.


Bearing in mind we have a pretty good map of the locations of the 
majority of LiveCode users who we would class as 'likely to attend if 
they can', it isn't a difficult thing to work out where the optimal 
places to hold it might be.


In regards to why Edinburgh (UK) and not somewhere else in Europe. 
Then, again, that is an economic imperative. Whilst getting to the 
main aviation hubs in the Western part of Western Europe (Amsterdam, 
Paris etc.) is perhaps no more difficult than getting to those in the 
UK, if we hold the conference in Europe rather than Edinburgh than we 
have to:

   1) Only take a restricted set of staff.
   2) Pay for transporting said staff to the European location.
   3) Pay for feeding, and housing said staff at the European location.

This latter cost means that (comparatively speaking) the ticket cost 
of the conference would have to be greater as it has to cover the 
costs of running the conference (the staff being there being quite an 
important aspect of this).


Now, of course, it costs more to transit staff to the US (although 
perhaps not to house!) than Europe; however, we have more users in the 
US who are 'likely to attend' so the expected tickets sales if we have 
the conference in the US is higher in the UK.


Basically, where a conference is held is entirely a numbers game.

Sure, we could throw in a couple of 'lets make people feel fluffy 
questions' into such a survey (which wouldn't really give any useful 
data at all) but that would just make the survey longer. The longer 
the survey, the less responses you get, thus the less accurate the 
results you get. Again, it all comes down to numbers.


Mark.



The survey asked if one were likely to attend; but as the choice of 
where one could attend was restricted the results would be

like a self-fulfilling prophecy.

Had you offered, say, Munich or somewhere on the Pacific rim 
(Shanghai???) you might have got quite a few people to say they might

attend; but by restricting the choices you will never know.

Richmond.

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

Re: Silly conference survey

[Jim sims]

A conference requires a lot of work, planning, and inevitably tons
of problem solving. Trust me.

Flights are one expense but lodging can be far far greater. Negotiating
with a hotel is usually a good idea.

European Perspective - it would currently cost me £50 to take Ryanair from
Malta to Edinburgh. Wicked Cheap. Other European cities might be more but
most likely reasonable.

Edinburgh lodging can be expensive compared to some places (way way
expensive in August!!) but is not too crazy especially with AirBNB.
Personally I use couch surfing (free) each time I go there.

Most Important - Given we want to keep LC people chained to desks working
as much as possible plus like to have funds channeled to code rather than
airlines it makes to me that they have (European) conferences in Edinburgh.

Maybe have alternating (or whatever timing) conferences in the USA if
that's where lots of their funds come from. But EDI seems a good one for
Europe.

sims









On Wednesday, September 9, 2015, Mark Waddingham  wrote:

> I do think, even if only as a sop to those of us (like myself) who get
>> fed up how RunRev, for all their ballyhoo about China and so forth,
>> do seem to give the impression that they don't really seem to think
>> outside a North Atlantic box, the survey would have looked a bit
>> more friendly if it had left a chance open for participants to suggest
>> other cities in other states/countries than those forced as choices
>> on participants.
>>
>
> To be blunt Richmond, it doesn't take a great deal of thought to
> understand *why* there is a restricted choice. Indeed, I think people
> before me have already explained adequately why. However, let me reiterate
> in perhaps slightly more detail:
>
> The point of a conference is that people attend.
>
> If people are to go to a conference then they need to be able to afford to
> do so.
>
> If you hold a conference somewhere where the cost to get there exceeds
> someone's ability to pay those costs, they won't go.
>
> If you hold a conference somewhere where the ticket price has to exceed
> someone's ability to pay that cost, they won't go.
>
> Therefore, you need to ensure that you hold the conference in a location
> where the most number of people who are likely to attend can attend.
>
> Bearing in mind we have a pretty good map of the locations of the majority
> of LiveCode users who we would class as 'likely to attend if they can', it
> isn't a difficult thing to work out where the optimal places to hold it
> might be.
>
> In regards to why Edinburgh (UK) and not somewhere else in Europe. Then,
> again, that is an economic imperative. Whilst getting to the main aviation
> hubs in the Western part of Western Europe (Amsterdam, Paris etc.) is
> perhaps no more difficult than getting to those in the UK, if we hold the
> conference in Europe rather than Edinburgh than we have to:
>1) Only take a restricted set of staff.
>2) Pay for transporting said staff to the European location.
>3) Pay for feeding, and housing said staff at the European location.
>
> This latter cost means that (comparatively speaking) the ticket cost of
> the conference would have to be greater as it has to cover the costs of
> running the conference (the staff being there being quite an important
> aspect of this).
>
> Now, of course, it costs more to transit staff to the US (although perhaps
> not to house!) than Europe; however, we have more users in the US who are
> 'likely to attend' so the expected tickets sales if we have the conference
> in the US is higher in the UK.
>
> Basically, where a conference is held is entirely a numbers game.
>
> Sure, we could throw in a couple of 'lets make people feel fluffy
> questions' into such a survey (which wouldn't really give any useful data
> at all) but that would just make the survey longer. The longer the survey,
> the less responses you get, thus the less accurate the results you get.
> Again, it all comes down to numbers.
>
> Mark.
>
> --
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>


-- 
Sent from my iPodo - it makes weird spelling sometimes :-P
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LiveCode fix for \\UNC paths coming...

[Mark Waddingham]

On 2015-09-03 14:28, Roger Eller wrote:

That's great news!  Thank you.


After a bit of to-ing and fro-ing (the Win32 path behavior is quite 
subtle...) we've got a patch ready for this. It's currently scheduled 
for 6.7.8-rc-1:


https://github.com/runrev/livecode/pull/2832

Warmest Regards,

Mark.

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

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

Re: BBEdit/Textwrangler LCM for livescript

[Thierry Douez]

Hi,

Replace the key 'Function Pattern' with the one below
and you might have a surprise with code folding..

Function Pattern



Tested successfully but very quickly with TextWrangler 4.5.12 ( the latest)

I have another option, but let comments arise before going further..

Regards,

Thierry


Thierry Douez - http://sunny-tdz.com
sunnYrex - sunnYtext2speech - sunnYperl - sunnYmidi - sunnYmage

___
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: Silly conference survey

[Graham Samuel]

Well said Mark!

Graham


> On 9 Sep 2015, at 10:30, Mark Waddingham  wrote:
> 
>> I do think, even if only as a sop to those of us (like myself) who get
>> fed up how RunRev, for all their ballyhoo about China and so forth,
>> do seem to give the impression that they don't really seem to think
>> outside a North Atlantic box, the survey would have looked a bit
>> more friendly if it had left a chance open for participants to suggest
>> other cities in other states/countries than those forced as choices
>> on participants.
> 
> To be blunt Richmond, it doesn't take a great deal of thought to understand 
> *why* there is a restricted choice. Indeed, I think people before me have 
> already explained adequately why. However, let me reiterate in perhaps 
> slightly more detail:
> 
> The point of a conference is that people attend.
> 
> If people are to go to a conference then they need to be able to afford to do 
> so.
> 
> If you hold a conference somewhere where the cost to get there exceeds 
> someone's ability to pay those costs, they won't go.
> 
> If you hold a conference somewhere where the ticket price has to exceed 
> someone's ability to pay that cost, they won't go.
> 
> Therefore, you need to ensure that you hold the conference in a location 
> where the most number of people who are likely to attend can attend.
> 
> Bearing in mind we have a pretty good map of the locations of the majority of 
> LiveCode users who we would class as 'likely to attend if they can', it isn't 
> a difficult thing to work out where the optimal places to hold it might be.
> 
> In regards to why Edinburgh (UK) and not somewhere else in Europe. Then, 
> again, that is an economic imperative. Whilst getting to the main aviation 
> hubs in the Western part of Western Europe (Amsterdam, Paris etc.) is perhaps 
> no more difficult than getting to those in the UK, if we hold the conference 
> in Europe rather than Edinburgh than we have to:
>   1) Only take a restricted set of staff.
>   2) Pay for transporting said staff to the European location.
>   3) Pay for feeding, and housing said staff at the European location.
> 
> This latter cost means that (comparatively speaking) the ticket cost of the 
> conference would have to be greater as it has to cover the costs of running 
> the conference (the staff being there being quite an important aspect of 
> this).
> 
> Now, of course, it costs more to transit staff to the US (although perhaps 
> not to house!) than Europe; however, we have more users in the US who are 
> 'likely to attend' so the expected tickets sales if we have the conference in 
> the US is higher in the UK.
> 
> Basically, where a conference is held is entirely a numbers game.
> 
> Sure, we could throw in a couple of 'lets make people feel fluffy questions' 
> into such a survey (which wouldn't really give any useful data at all) but 
> that would just make the survey longer. The longer the survey, the less 
> responses you get, thus the less accurate the results you get. Again, it all 
> comes down to numbers.
> 
> Mark.
> 
> -- 
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: Silly conference survey

[Mark Waddingham]

I do think, even if only as a sop to those of us (like myself) who get
fed up how RunRev, for all their ballyhoo about China and so forth,
do seem to give the impression that they don't really seem to think
outside a North Atlantic box, the survey would have looked a bit
more friendly if it had left a chance open for participants to suggest
other cities in other states/countries than those forced as choices
on participants.


To be blunt Richmond, it doesn't take a great deal of thought to 
understand *why* there is a restricted choice. Indeed, I think people 
before me have already explained adequately why. However, let me 
reiterate in perhaps slightly more detail:


The point of a conference is that people attend.

If people are to go to a conference then they need to be able to afford 
to do so.


If you hold a conference somewhere where the cost to get there exceeds 
someone's ability to pay those costs, they won't go.


If you hold a conference somewhere where the ticket price has to exceed 
someone's ability to pay that cost, they won't go.


Therefore, you need to ensure that you hold the conference in a location 
where the most number of people who are likely to attend can attend.


Bearing in mind we have a pretty good map of the locations of the 
majority of LiveCode users who we would class as 'likely to attend if 
they can', it isn't a difficult thing to work out where the optimal 
places to hold it might be.


In regards to why Edinburgh (UK) and not somewhere else in Europe. Then, 
again, that is an economic imperative. Whilst getting to the main 
aviation hubs in the Western part of Western Europe (Amsterdam, Paris 
etc.) is perhaps no more difficult than getting to those in the UK, if 
we hold the conference in Europe rather than Edinburgh than we have to:

   1) Only take a restricted set of staff.
   2) Pay for transporting said staff to the European location.
   3) Pay for feeding, and housing said staff at the European location.

This latter cost means that (comparatively speaking) the ticket cost of 
the conference would have to be greater as it has to cover the costs of 
running the conference (the staff being there being quite an important 
aspect of this).


Now, of course, it costs more to transit staff to the US (although 
perhaps not to house!) than Europe; however, we have more users in the 
US who are 'likely to attend' so the expected tickets sales if we have 
the conference in the US is higher in the UK.


Basically, where a conference is held is entirely a numbers game.

Sure, we could throw in a couple of 'lets make people feel fluffy 
questions' into such a survey (which wouldn't really give any useful 
data at all) but that would just make the survey longer. The longer the 
survey, the less responses you get, thus the less accurate the results 
you get. Again, it all comes down to numbers.


Mark.

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

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

Re: Silly conference survey

[Mark Waddingham]

On 2015-09-08 21:53, Richard Gaskin wrote:

Richmond wrote:

http://us7.campaign-archive2.com/?u=8404b344b09103bf489dd8a9a&id=cbaad904da&e=30cf6c38b4


Thanks.  The form won't accept input in Chrome, and since I didn't
receive an invitation to participate in the survey I'll wait until
it's ready and I get an invitation.


Works fine in (latest version of) Chrome here - so it's one of a local 
issue with your Chrome install (is it the latest version), a temporary 
glitch with survey monkey (which I'm sure will be fixed quite quickly as 
its quite a large service), or a case of PEBKAC :)


Mark.

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

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

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

[Mark Waddingham]

On 2015-09-09 05:38, Mark Wieder wrote:

4. My pull request was passive-aggressively not accepted because
"there's no way to review the changes".


I think you should perhaps look at the title of your post for an example 
of passive-aggressiveness, rather than Ali's perfectly measured and 
appropriate response to your pull request :)


We have been clear about what we can and cannot accept at this time as 
community contributions.


We have been clear about what branch we would pull feature additions 
into (that would be the develop branch which is 8).


We have been clear about the amount of work we have done on the IDE to 
improve the situation in 8 - i.e. turning as much of the IDE as possible 
into script only stacks.


In regards to binary stackfile contributions - I'm sorry but we simply 
cannot accept them at this time. I think the community would be rather 
unhappy if we did accept a binary stackfile contribution in which 
someone had planted something nefarious that we did not see and ended up 
adversely affecting their local systems on install in some heinous way.


Now, I'm not saying there is not a solution to this - but we don't have 
one right now. How far off is a solution? I honestly don't know.


So, it seems to me, the best solution *right now* is that we all work on 
the develop branch and therefore LC8. The develop branch IDE has a 
substantial number of script only stacks which makes contribution (and 
also in house changes - I should add!) a lot lot easier and more 
transparent *and* it is only one branch to focus on so if a binary 
change is required, a LiveCode engineer only has to go through and do 
the necessary work once (which, I'd point out Ali quite happily did with 
the contribution in question).


Warmest Regards,

Mark.

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

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

Re: externals on Windows

[Thierry Douez]

> I know nothing about writing externals for Livecode on Windows.
> Are there any tutorials available?



http://newsletters.livecode.com/november/issue13/newsletter5.php

http://newsletters.livecode.com/november/issue14/newsletter3.php

http://newsletters.livecode.com/october/issue34/newsletter1.php


Kind regards,

Thierry



Thierry Douez - http://sunny-tdz.com
sunnYrex - sunnYtext2speech - sunnYperl - sunnYmidi - sunnYmage

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

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

[Ali Lloyd]

I'm sorry you felt it was passive-aggressively not accepted. It was meant
neither as passive-agressively , nor  not accepted.

Indeed I have used almost the exact same wording in the past:
https://github.com/runrev/livecode-ide/pull/9

In that case it was a one-line bugfix in a stack that was the same in all
versions of the IDE, and so it was absolutely no trouble at all to
incorporate. Also it is a stack to which almost no changes are ever made,
and a change with foreseeably no side-effects.

This is a more complex change, an enhancement, to a stack that is different
in two versions of the IDE, to a stack far more central to the IDE.
Incorporating the contribution there involves more work (it would make
sense to scriptify as much of the script editor as possible at the same
time). If an engineer here has time to do that, that would be great.
However the maintenance workload here is pretty immense, and personally all
my time is being spent on the develop branches.


We can and do accept user inputs to three quarters of the files in our
repositories. One of your pull requests was merged into the IDE a couple of
weeks ago.


On Wed, Sep 9, 2015 at 4:38 AM Mark Wieder  wrote:

> On 09/08/2015 05:37 PM, Richard Gaskin wrote:
>
> > If we can just get a review process in place for community enhancements
> > to the IDE to be included in the main install, everyone wins.
>
> And that's really the only unsolved part right now.
> 1. The script editor fix is now part of the LC8 develop branch.
> 2. Charles' script editor stack is now public and usable in LC6 and LC7.
> 3. Charles detailed the changes that need to be done in the existing
> script editor stack in his bug report.
> 4. I incorporated Charles' stack into my build repository, pushed, and
> submitted a pull request.
>
> So there are now four ways to get this integrated into LC6 and LC7.
>
> 1. I guess it's too much work to backport the changes that were made to
> the LC8 stack.
> 3. For some reason it must be too hard to incorporate the bug report
> changes, because the filter was implemented a different way.
> 4. My pull request was passive-aggressively not accepted because
> "there's no way to review the changes".
>
> That leaves #2, as in it's an exercise left to the user to incorporate
> locally, and has to be again with each new release.
>
> This would be ridiculous if it weren't so ridiculous... an open source
> project on its third major release that still can't accept user inputs?
>
> --
>   Mark Wieder
>   ahsoftw...@gmail.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
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