Re: Developing first on android

[Brian Milby via use-livecode]

I can see that.  If using the export as a way to track where you made
changes, it would be good to have it in a text format.  I've not gotten far
enough into the object code to tell when/where it would be safe to edit
such an array.  This will need to be something considered when writing the
import code.

On Fri, Aug 18, 2017 at 5:48 PM, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I'll weigh in here. An array representation of a stack might be useful in
> ways, such as storing it as a property of another stack, or writing it as a
> binary file to disk as a backup of sorts after arrayEncoding it.
>
> Just so long as no one thinks they can do something like take the key that
> represents say a button and copy it to another stack array, or a different
> place in the first array, all will be well. All kinds of nasties happen
> with ID's and linked graphics and whatnot just copying a button with a
> linked graphic to another card.
>
> Bob S
>
>
> > On Aug 18, 2017, at 15:12 , Brian Milby via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > If I'm understanding correctly, a capability to export a stack as an
> array
> > (with the corresponding import) would get around the issue of the
> > non-public properties though.  The array would be the intermediate format
> > that would be used by the engine to construct the stack in memory.  LCS
> > could be used to serialize into a suitable disk format.  It would mean
> that
> > the only way to get a full representation of the object would be to use
> the
> > full import if there were properties like you described above (unless I'm
> > missing something).
> >
> > I've actually been mulling something along these lines over for the past
> > few weeks (but was thinking about a direct XML format).  I briefly looked
> > at the code to save a stack and noticed how it seems pretty straight
> > forward.  I'll take a look at the code for some of the objects this
> weekend
> > and see what I think.  Could be a good opportunity for the community to
> > contribute a useful new feature.
>
>
> ___
> 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: Applescript Fails in Standalone on Mac Built with 8.1.6

[Brian Milby via use-livecode]

I'll see if I can figure out a way to make a test like this work.

On Fri, Aug 18, 2017 at 12:01 PM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2017-08-18 18:14, Brian Milby via use-livecode wrote:
>
>> I'm so new I can't address the history but seeing where the fix was
>> implemented it should not fall out unless the build process is
>> significantly changed.It is in the same place all of the language
>> localization files are specified.
>>
>
> I can help fill in the history - yes we've broken it always accidentally
> on numerous occasions; and then fixed it, and the broken it again, or
> didn't really fix it properly or something (I can't make an excuse, or give
> a good reason here - other than it just seems to happen periodically!)
>
> The issue here is that we don't have a test for whether it is working in
> each built release - so that is the way to make sure it never happens again.
>
> @Brian: Would you be willing to write a test for this? It is going to be a
> little tricky as it requires IPC (unless you can use send apple event, to
> send one to the calling process), but there's an example of us doing that
> already in the private data clipboardData test:
>
> on TestClipboardPrivateKey
>set the clipboardData["private"] to "Hello World!"
>
>TestAssert "private key is present before external change", \
>   "private" is among the keys of the clipboardData
>
>local tHelperFilename
>set the itemDelimiter to slash
>put format("%s/_clipboard_private_setter.livecodescript", \
>  _TestPath()) into tHelperFilename
>if the environment is "command line" then
>   TestRunStack "-ui", tHelperFilename
>else
>   TestRunStack "", tHelperFilename
>end if
>
>TestAssert "helper changed clipboard externally", the result is 0
>
>if the platform is "Linux" then
>   TestAssertBroken "private key not present after external change", \
>  "private" is not among the keys of the clipboardData, \
>  "Bug 19117"
>else
>   TestAssert "private key not present after external change", \
>  "private" is not among the keys of the clipboardData
>end if
> end TestClipboardPrivateKey
>
> This basically uses a sub-process to do something to the clipboard so that
> the test process can check whether the private key disappears in this case.
>
> 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
>
___
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: lock screen gotcha revisited

[Mark Wieder via use-livecode]

On 08/18/2017 07:41 PM, J. Landman Gay via use-livecode wrote:
Except when it doesn't. There seems to be an override in the lock count 
if any unlock uses a visual effect. I'm not sure if that's on purpose or 
not.


Thanks. Good to know. I've just been using the barebones lock.

--
 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: Daybed 2.0 - A Library for Apache CouchDB

[Mike Kerner via use-livecode]

Greg,
That was a really cool talk, yesterday.  It got me thinking about Couch as
a maybe a new go-to option for cloud db's.

On Fri, Aug 18, 2017 at 7:36 PM, pink via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Apache has released CouchDB 2.1 and Daybed is still compatible.
>
> The library is available at:  https://github.com/madpink/couchdb4livecode
>
> This has been a big week for me...
> I had my talk about CouchDB for Livecode Global (that was fun)
>
> I was interviewd for the CouchDB blog where I did my best to plug Livecode:
> https://blog.couchdb.org/2017/08/15/a-couchdb-user-story-
> gregory-madpink-miller-shares-his-couchdb-udemy-course/
>
> I've created a coupon code for my CouchDB Udemy course for anyone
> interested:
> https://www.udemy.com/understanding-couchdb/?couponCode=LIVECODE
>
> As of now the Daybed library includes:
>
> 1. The main functions for GET, PUT, POST and DELETE to CouchDB
> 2. "Quick functions" which save the basic info (URL, authentication, db
> name) and let you quickly access docs
> 3. Sync functions which save documents to a database created for the user
> and saves locally as a "save stack"
>
> To-Do list:
> -continue updating/adding to the quick functions
> -add option to save to a per app database instead of per user (this will
> help make sync compatible with Cloudant)
> -toying with other save options besides the stack (open to suggestions)
>
>
>
> -
> ---
> Greg (pink) Miller
> mad, pink and dangerous to code
> --
> View this message in context: http://runtime-revolution.
> 278305.n4.nabble.com/Daybed-2-0-A-Library-for-Apache-
> CouchDB-tp4718601.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
>



-- 
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: lock screen gotcha revisited

[J. Landman Gay via use-livecode]

Except when it doesn't. There seems to be an override in the lock count if 
any unlock uses a visual effect. I'm not sure if that's on purpose or not.

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



On August 18, 2017 8:39:34 PM Mark Wieder via use-livecode 
 wrote:



On 08/18/2017 03:50 PM, Bob Sneidar via use-livecode wrote:
Hard to say. I'm almost done finding every place I lock the screen and 
adding an unlock screen in the same handler.


And that, of course, is the best procedure. Locking/unlocking the screen
works on sort of a reference-counting approach. In general, locking the
screen increments a counter, unlocking the screen decrements it. When
the counter reaches zero, the screen is unlocked and all the pending
updates take place.

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

Re: lock screen gotcha revisited

[Mark Wieder via use-livecode]

On 08/18/2017 03:50 PM, Bob Sneidar via use-livecode wrote:

Hard to say. I'm almost done finding every place I lock the screen and adding 
an unlock screen in the same handler.


And that, of course, is the best procedure. Locking/unlocking the screen 
works on sort of a reference-counting approach. In general, locking the 
screen increments a counter, unlocking the screen decrements it. When 
the counter reaches zero, the screen is unlocked and all the pending 
updates take place.


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

Daybed 2.0 - A Library for Apache CouchDB

[pink via use-livecode]

Apache has released CouchDB 2.1 and Daybed is still compatible.

The library is available at:  https://github.com/madpink/couchdb4livecode

This has been a big week for me...
I had my talk about CouchDB for Livecode Global (that was fun)

I was interviewd for the CouchDB blog where I did my best to plug Livecode:
https://blog.couchdb.org/2017/08/15/a-couchdb-user-story-gregory-madpink-miller-shares-his-couchdb-udemy-course/

I've created a coupon code for my CouchDB Udemy course for anyone
interested:
https://www.udemy.com/understanding-couchdb/?couponCode=LIVECODE

As of now the Daybed library includes:

1. The main functions for GET, PUT, POST and DELETE to CouchDB
2. "Quick functions" which save the basic info (URL, authentication, db
name) and let you quickly access docs
3. Sync functions which save documents to a database created for the user
and saves locally as a "save stack"

To-Do list:
-continue updating/adding to the quick functions
-add option to save to a per app database instead of per user (this will
help make sync compatible with Cloudant)
-toying with other save options besides the stack (open to suggestions)



-
---
Greg (pink) Miller
mad, pink and dangerous to code
--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Daybed-2-0-A-Library-for-Apache-CouchDB-tp4718601.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: lock screen gotcha revisited

[Bob Sneidar via use-livecode]

Hard to say. I'm almost done finding every place I lock the screen and adding 
an unlock screen in the same handler. 

Bob S


> On Aug 18, 2017, at 14:03 , J. Landman Gay via use-livecode 
>  wrote:
> 
> That doesn't sound right, though I've seen issues with nested locks too. What 
> happens if you call this handler:
> 
> on unlockReally
>  repeat until the lockscreen is false
>unlock screen
>  end repeat
> end unlockReally


___
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: Developing first on android

[Bob Sneidar via use-livecode]

I'll weigh in here. An array representation of a stack might be useful in ways, 
such as storing it as a property of another stack, or writing it as a binary 
file to disk as a backup of sorts after arrayEncoding it. 

Just so long as no one thinks they can do something like take the key that 
represents say a button and copy it to another stack array, or a different 
place in the first array, all will be well. All kinds of nasties happen with 
ID's and linked graphics and whatnot just copying a button with a linked 
graphic to another card. 

Bob S


> On Aug 18, 2017, at 15:12 , Brian Milby via use-livecode 
>  wrote:
> 
> If I'm understanding correctly, a capability to export a stack as an array
> (with the corresponding import) would get around the issue of the
> non-public properties though.  The array would be the intermediate format
> that would be used by the engine to construct the stack in memory.  LCS
> could be used to serialize into a suitable disk format.  It would mean that
> the only way to get a full representation of the object would be to use the
> full import if there were properties like you described above (unless I'm
> missing something).
> 
> I've actually been mulling something along these lines over for the past
> few weeks (but was thinking about a direct XML format).  I briefly looked
> at the code to save a stack and noticed how it seems pretty straight
> forward.  I'll take a look at the code for some of the objects this weekend
> and see what I think.  Could be a good opportunity for the community to
> contribute a useful new feature.


___
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

textbanner widget

[hh via use-livecode]

Some of you may find this new widget useful.

A textbanner widget that displays a text string, an "one-liner",
as running text right to left (optionally left to right) or static.
Has many documented options to set (font, size, colors, speed, ...).

Ready to use via the extension manager in LC 8.1.6.
For use in LC 9.0.0-dpx extract the lcb-file from the zip and build your own.

Download from here (you'll also find a demo-stack there):
http://forums.livecode.com/viewtopic.php?p=157192#p157192


___
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: Developing first on android

[Brian Milby via use-livecode]

If I'm understanding correctly, a capability to export a stack as an array
(with the corresponding import) would get around the issue of the
non-public properties though.  The array would be the intermediate format
that would be used by the engine to construct the stack in memory.  LCS
could be used to serialize into a suitable disk format.  It would mean that
the only way to get a full representation of the object would be to use the
full import if there were properties like you described above (unless I'm
missing something).

I've actually been mulling something along these lines over for the past
few weeks (but was thinking about a direct XML format).  I briefly looked
at the code to save a stack and noticed how it seems pretty straight
forward.  I'll take a look at the code for some of the objects this weekend
and see what I think.  Could be a good opportunity for the community to
contribute a useful new feature.

On Fri, Aug 18, 2017 at 11:56 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2017-08-18 18:05, Brian Milby via use-livecode wrote:
>
>> What about a non-binary stack file format?  Something XML based and
>> derived
>> from the actual in-memory stack object (would need to be integrated with
>> the IDE/engine to be really useful though - to allow seamless/native
>> import/export).
>>
>
> I think Monte's lcVCS might well be a good starting point for that -
> there's no real need to have engine support as long as we make sure all the
> things you need to know to deconstruct / reconstruct a stackfile are
> accessible from script (which is where the engine support kicks in).
>
> That being said, there is one piece of engine functionality which would
> make lcVCS and similar tools much simpler - the ability to ask the engine
> for a LiveCode array representing the actual persistent state of any
> LiveCode object. If you have an array which contains a faithful
> representation of the persistent state, then you can write serializers /
> deserializers to whatever text (or other!) format you like in LiveCode
> Script (which is a much much better place for such things to be!).
>
> There is a starting point here for this. In order to allow lcVCS to
> support widgets (which can have arbitrary persistent state), we added a new
> form to the 'export' and 'import' commands:
>
> export  to array 
> import  from array 
>
> We also added 'is strictly' operators which allow you to detect the actual
> dynamic type of a value, rather than what values it could be:
>
>   put "100" is a number -- true
>   put "100" is strictly a number -- false
>
> This allows lcVCS to create a faithful representation (in JSON) of the
> values in LiveCode variables - in particular, in those returned from
> export/import widget.
>
> The reason I mention this is that this ability really is the precursor to
> eliminating the engine's dependence on a bespoke binary stackfile format
> (which is actually a huge problem - for all kinds of reasons) - if we had a
> fully faithful (in the strict mathematical sense!) import/export array
> ability - a stackfile could just become an array which has been encoded
> with any hierarchical data encoding format (of which the arrayEncode format
> is one, JSON is another, BSON is another, YAML is another, ...).
>
> It might be that the part of lcVCS which does the JSON mapping might well
> be completely sufficient - perhaps Monte could chime in here to comment and
> remind me of the issues he had / faced with it.
>
> I can recall one significant issue - the properties we set on objects (or
> widgets - lamentably) are not necessarily reflective of the persistent
> state. What I mean by this is that, in some case, you cannot directly set
> one of the internal persistent state variables of an object directly by a
> property - it can only be done by setting a combination, or by other
> actions (I'd need to look through the engine code to remind myself where
> this occurs).
>
> However *that* is fixable - we make sure that there are suitably human
> understandable properties for all objects which ensure you can easily
> import and export them using just those properties. For widgets, it comes
> to down to imposing a simple rule:
>
> Any piece of state which is saved into the state array (on OnSave) *must*
> be accessible by a public property.
>
> This would actually simplify widget creation - as you wouldn't need an
> OnLoad / OnSave handler at all then. It would just be a case of serializing
> the properties which are marked as 'persistent'. This is one case where I
> modelled the engine's behavior, and shouldn't have done - I should have
> ignored how the engine did things and just gone with 'what made more sense'!
>
> Anyway, I'd suggest we start looking at lcVCS (in terms of its object
> import/export - not the VC related aspects) and see what issues it has;
> then look at starting to fix those issues in the engine; then look to start
> adding array import/export 

Re: lock screen gotcha revisited

[J. Landman Gay via use-livecode]

That doesn't sound right, though I've seen issues with nested locks too. 
What happens if you call this handler:


on unlockReally
  repeat until the lockscreen is false
unlock screen
  end repeat
end unlockReally


On 8/18/17 3:54 PM, Bob Sneidar via use-livecode wrote:

okay after some testing it seems only the script that locked the screen, maybe 
only the actual handler can clear it's own lock. If this is not right I'd like 
to know it. Seems there ought to be an unlock all command or some such thing.

Bob S



On Aug 18, 2017, at 13:37 , Bob Sneidar via use-livecode 
 wrote:

Hi all.

I have some screen updates I do that take time because I query a database 
first, and it may not be local. To keep the screen from progressively updating, 
I lock the screen.



___
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




--
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: lock screen gotcha revisited

[Bob Sneidar via use-livecode]

okay after some testing it seems only the script that locked the screen, maybe 
only the actual handler can clear it's own lock. If this is not right I'd like 
to know it. Seems there ought to be an unlock all command or some such thing. 

Bob S


> On Aug 18, 2017, at 13:37 , Bob Sneidar via use-livecode 
>  wrote:
> 
> Hi all. 
> 
> I have some screen updates I do that take time because I query a database 
> first, and it may not be local. To keep the screen from progressively 
> updating, I lock the screen. 

 
___
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

lock screen gotcha revisited

[Bob Sneidar via use-livecode]

Hi all. 

I have some screen updates I do that take time because I query a database 
first, and it may not be local. To keep the screen from progressively updating, 
I lock the screen. 

I then decided to put a status message field at the bottom of each "form" 
(meaning card in a stack) so I have a handler that I pass a message and a long 
card id to, and it sets the text of the field and the background color (for 
visual clue) so the user has some idea of what is going on. 

Now the first message I send works because I have not locked the screen yet. 
the SECOND message I send AFTER the screen is locked never appears, which is 
expected. So I have a script which checks for the lockscreen property and if 
true, unlocks the screen, waits 10 milliseconds (to make sure the screen 
updates) then relocks the screen. 

The problem is that it doesn't. Unlock the screen that is. I set a breakpoint 
in the condition that checks for the lockscreen property and it indeed DOES 
trigger, but without the breakpoint I never see the second status message. I 
even set the wait 10 milliseconds to 5 seconds and I STILL do not see the 
second message. 

Since the unlock screen is in a handler in a backscript, I do not think it is 
actually cancellign the lock set by the datagrid on the card. There was some 
discussion about this in the past, that not all lockscreens are created equal. 
Is there a way to tell how many screenlocks are current and who set the lock? I 
suppose I could track it in a property then send unlockscreen to everything 
that locked it, but I'd like to not have to do that. Better yet would be a 
global unlock screen that cleared all screen locks. I thought that wait would 
do it. I tried wait with messages. No dice. I also unlocked the screen 5 times 
in a row in case there were multiple screen locks (I didn't think it worked 
that way but it's cheap to test) still no luck. 

It seems one handler cannot unlock the screen when another locks it. 

Anyone? 
___
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: Developing first on android

[J. Landman Gay via use-livecode]

On 8/17/17 8:31 PM, Mike Kerner via use-livecode wrote:

I liked what Pomegranate said,
which would also be a way to make apps even more levure/git-friendly, and
would, I think, solve some of the Android layout issues that she was
discussing - every object is created by a script, instead of using the LC
IDE to do it.


This method also works well, and I've used it in a couple of projects. 
But being basically lazy, I like to follow the rule to "let the engine 
do it" whenever possible. If you aren't using git or your layouts aren't 
dynamic, it's much easier to let the engine do the resizing and scaling 
for you, and the tricks I mentioned are an easy way to overcome a few 
limitations.


One other comment about my presentation: the problem with issuing the 
"quit" command was just fixed and is now awaiting merge. :) Now all we 
need is suspend/resume messages and the main Android issues will go away.


--
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: [ot] Richardevm pollution

[Richard Gaskin via use-livecode]

Mike Kerner wrote:

>> Mike Kerner wrote:
>>
>> > We have another abuser on the forums
>> > Admins!  Attack!
>>
>> The moderators that read this list regularly (Klaus and myself - are
>> there others here?) tend to read the forums with the same frequency.
>> So we'll see it there about as quickly as we see a note here.  But
>> our ability to handle it efficiently is limited, so unless we have a
>> pile of free time on our hands we'll likely just send a note to the
>> admins.
>>
>> The best way to reach forum admins is to send a support request to
>> on-rev.  If urgent, not that in the subject line.
>>
>> --
>>  Richard Gaskin
>>  Fourth World Systems
>
> Why not put a tag, note, etc. somewhere on the forums site, or in
> message footers to that effect so 15 weeks from now I don't have
> to try to remember that?

Good idea.  And now you have the address to submit it. :)

There is one downside to posting it there:  the same bots triggering the 
need for it can also pick it up.  If that email account gets overwhelmed 
with spam we have another problem on our hands.


In the meantime, most folks just use the "Report Post" icon in the 
upper-right of a post; flagging one is usually sufficient to get a 
moderator's attention if we haven't seen it already.


Relatively speaking (given the number of bots slamming forums around the 
world all day) the amount of *visible* spam on the LC forums is 
relatively low, certainly lower than the amount of spam that happens. 
Klaus hits most nearly as fast as they come in (Klaus, do you sleep?), 
and I or others tend to kill them as soon as we see them; I tend to 
check the forums a few times most days.  Most of the time we kill 'em 
before they get reported, sometimes probably before others even see them.


--
 Richard Gaskin
 Fourth World Systems


___
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: [ot] Richardevm pollution

[Mike Kerner via use-livecode]

Why not put a tag, note, etc. somewhere on the forums site, or in message
footers to that effect so 15 weeks from now I don't have to try to remember
that?
15 was also the number of forum posts that resulted in emails to me before
the massacare, this morning.

On Fri, Aug 18, 2017 at 11:33 AM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Mike Kerner wrote:
>
> > We have another abuser on the forums
> > Admins!  Attack!
>
> The moderators that read this list regularly (Klaus and myself - are there
> others here?) tend to read the forums with the same frequency.  So we'll
> see it there about as quickly as we see a note here.  But our ability to
> handle it efficiently is limited, so unless we have a pile of free time on
> our hands we'll likely just send a note to the admins.
>
> The best way to reach forum admins is to send a support request to
> on-rev.  If urgent, not that in the subject line.
>
> --
>  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
>



-- 
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: Using '@' to mark pass-by-reference (was Re: synonyms)

[Mike Kerner via use-livecode]

I was going to reply to something, but part way through the last message,
my brain melted and I stated thinking in 8088 assembler.  I HATE WHEN THAT
HAPPENS!
The reason for forgetting is because it is not something that I, at least,
will be tempted to use very often, on the order of "this me"
So if we're going to be stuck with "@", allowing the developer to put it in
both places in order to make code clearer makes sense.  What I meant was it
would be nice if ithere was the option to put it on the leading or the
trailing side of the name, because for as seldom as I use the syntax, I
usually screw it up.
The other thing that would be good for the purpose of making this
jargonist is to talk about it as an alias instead of a reference in the
docs and the dictionary, for the same reason that "container" was more
commonly used in HC than "variable" for the first n years.


On Fri, Aug 18, 2017 at 11:38 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2017-08-18 17:18, Bob Sneidar via use-livecode wrote:
>
>> That actually is a great explanation which solves a mystery I've often
>> wondnered about, which is how a handler with a different variable name
>> can contain the *actual* original variable. I thought the engine
>> actually created a new variable and copied the incoming value to it,
>> and then reversed this operation on return. Aliasing makes perfect
>> sense.
>>
>
> That's what would call 'inout' parameter mode.
>
> For most languages which exist today, the way you can specify to pass
> parameters to functions distills down into 4 types (generally these are
> called parameter 'modes'):
>
>   - by-ref
>   - by-value (also called 'in')
>   - copy-out (generally called 'out')
>   - copy-in-copy-out (generally called 'inout')
>
> Let us imagine we supported all these modes and we had a handler with
> signature:
>
>   command myHandler @yRef, in pIn, out rOut, inout xInOut
>
> Called with
>
>   myHandler tRef, tIn, tOut, tInOut
>
> The 'by-value'/'in' mode is what we are most familiar with. On entry to
> the handler the value in pIn is copied into the receiving variable tIn.
>
> The 'out' mode is similar to what you describe. On entry to the handler
> rOut contains nothing; on exit from the handler, the value in rOut is
> 'copied back' into the passed variable tOut.
>
> The 'inout' mode is a mixture of the two: on entry tInOut is copied into
> xInOut, and on exit xInOut is copied back into tInOut.
>
> In the 'by-ref' mode there is no copying at all - mutations to the
> receiving variable yRef are actually mutations to the passed variable tRef.
> i.e. yRef doesn't really exist at all.
>
> The by-ref mode can emulate all of the other modes - you just have to code
> with some rules:
>
> To use a by-ref parameter as 'in' - you must not change the value of the
> parameter in the handler being called.
>
> To use a by-ref parameter as 'out' - you must not read the parameter at
> all and only change the value of the parameter except just before you
> exit/return.
>
> To use a by-ref parameter as 'inout' - you can read the parameter at any
> point, but only change it just before you exit/return.
>
> In most languages, the 'copy-back' part of the 'out' and 'inout' modes
> only generally happen for normal handler exit - they don't happen if you
> throw an exception.
>
> Now, having said all of that - there is actually a fifth parameter mode
> 'call-by-name' which at least one language had - ALGOL. Basically this
> meant (IIRC) that you passed in the symbolic expression to the receiver so
> it acted as some kind of macro:
>
>   foo(tArray[I]) - inside foo, any reference to that parameter would
> re-evaluate tArray[I] in the context of the caller.
>
> The reason I mention this is because the way LiveCode does by-ref
> parameters for array elements is *almost* like this - but not quite as
> unwieldy. When you do:
>
>   command myHandler @xVar
> put 100 into xVar["baz"]
>   end myHandler
>
>   local tArray
>   myHandler tArray[tIndex1][tIndex2]
>
> What actually happens is somewhat equivalent to the following:
>
>   local tArrayPath
>   put tIndex1 into tArrayPath[1]
>   put tIndex2 into tArrayPath[2]
>   myHandlerModified tArray, tArrayPath -- a second parameter has been
> added here
>
> With
>
>   command myHandlerModified @xArray, pArrayPath
> put 100 into xArray[pArrayPath]["baz"]
>   end myHandlerModified
>
> Basically, the 'path' is frozen before the call, but implicitly used
> within the call when mutating the by-ref variable.
>
>
> 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
>



-- 
On the first day, God created the heavens 

Re: Applescript Fails in Standalone on Mac Built with 8.1.6

[Mark Waddingham via use-livecode]

On 2017-08-18 18:14, Brian Milby via use-livecode wrote:

I'm so new I can't address the history but seeing where the fix was
implemented it should not fall out unless the build process is
significantly changed.It is in the same place all of the language
localization files are specified.


I can help fill in the history - yes we've broken it always accidentally 
on numerous occasions; and then fixed it, and the broken it again, or 
didn't really fix it properly or something (I can't make an excuse, or 
give a good reason here - other than it just seems to happen 
periodically!)


The issue here is that we don't have a test for whether it is working in 
each built release - so that is the way to make sure it never happens 
again.


@Brian: Would you be willing to write a test for this? It is going to be 
a little tricky as it requires IPC (unless you can use send apple event, 
to send one to the calling process), but there's an example of us doing 
that already in the private data clipboardData test:


on TestClipboardPrivateKey
   set the clipboardData["private"] to "Hello World!"

   TestAssert "private key is present before external change", \
  "private" is among the keys of the clipboardData

   local tHelperFilename
   set the itemDelimiter to slash
   put format("%s/_clipboard_private_setter.livecodescript", \
 _TestPath()) into tHelperFilename
   if the environment is "command line" then
  TestRunStack "-ui", tHelperFilename
   else
  TestRunStack "", tHelperFilename
   end if

   TestAssert "helper changed clipboard externally", the result is 0

   if the platform is "Linux" then
  TestAssertBroken "private key not present after external change", 
\

 "private" is not among the keys of the clipboardData, \
 "Bug 19117"
   else
  TestAssert "private key not present after external change", \
 "private" is not among the keys of the clipboardData
   end if
end TestClipboardPrivateKey

This basically uses a sub-process to do something to the clipboard so 
that the test process can check whether the private key disappears in 
this case.


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: Developing first on android

[Mark Waddingham via use-livecode]

On 2017-08-18 18:05, Brian Milby via use-livecode wrote:
What about a non-binary stack file format?  Something XML based and 
derived
from the actual in-memory stack object (would need to be integrated 
with

the IDE/engine to be really useful though - to allow seamless/native
import/export).


I think Monte's lcVCS might well be a good starting point for that - 
there's no real need to have engine support as long as we make sure all 
the things you need to know to deconstruct / reconstruct a stackfile are 
accessible from script (which is where the engine support kicks in).


That being said, there is one piece of engine functionality which would 
make lcVCS and similar tools much simpler - the ability to ask the 
engine for a LiveCode array representing the actual persistent state of 
any LiveCode object. If you have an array which contains a faithful 
representation of the persistent state, then you can write serializers / 
deserializers to whatever text (or other!) format you like in LiveCode 
Script (which is a much much better place for such things to be!).


There is a starting point here for this. In order to allow lcVCS to 
support widgets (which can have arbitrary persistent state), we added a 
new form to the 'export' and 'import' commands:


export  to array 
import  from array 

We also added 'is strictly' operators which allow you to detect the 
actual dynamic type of a value, rather than what values it could be:


  put "100" is a number -- true
  put "100" is strictly a number -- false

This allows lcVCS to create a faithful representation (in JSON) of the 
values in LiveCode variables - in particular, in those returned from 
export/import widget.


The reason I mention this is that this ability really is the precursor 
to eliminating the engine's dependence on a bespoke binary stackfile 
format (which is actually a huge problem - for all kinds of reasons) - 
if we had a fully faithful (in the strict mathematical sense!) 
import/export array ability - a stackfile could just become an array 
which has been encoded with any hierarchical data encoding format (of 
which the arrayEncode format is one, JSON is another, BSON is another, 
YAML is another, ...).


It might be that the part of lcVCS which does the JSON mapping might 
well be completely sufficient - perhaps Monte could chime in here to 
comment and remind me of the issues he had / faced with it.


I can recall one significant issue - the properties we set on objects 
(or widgets - lamentably) are not necessarily reflective of the 
persistent state. What I mean by this is that, in some case, you cannot 
directly set one of the internal persistent state variables of an object 
directly by a property - it can only be done by setting a combination, 
or by other actions (I'd need to look through the engine code to remind 
myself where this occurs).


However *that* is fixable - we make sure that there are suitably human 
understandable properties for all objects which ensure you can easily 
import and export them using just those properties. For widgets, it 
comes to down to imposing a simple rule:


Any piece of state which is saved into the state array (on OnSave) 
*must* be accessible by a public property.


This would actually simplify widget creation - as you wouldn't need an 
OnLoad / OnSave handler at all then. It would just be a case of 
serializing the properties which are marked as 'persistent'. This is one 
case where I modelled the engine's behavior, and shouldn't have done - I 
should have ignored how the engine did things and just gone with 'what 
made more sense'!


Anyway, I'd suggest we start looking at lcVCS (in terms of its object 
import/export - not the VC related aspects) and see what issues it has; 
then look at starting to fix those issues in the engine; then look to 
start adding array import/export methods for all LiveCode objects... 
Assuming this is an interesting project someone (not looking at anyone 
in particular ;)) would like to take up...


Warmest Regards,

Mark.


Mike Kerner wrote:

> I've been thinking of developing a deconstructor to use with Levure.
>  The idea is that you would lay out the objects, but then the
> deconstructor would pull all the properties of each object, put them
> in a YML, JSON, or other similar file, and then they would be built in
> the app by  script, when needed.

That would be handy.  I've considered making one, but the cost/benefit
relative to other commitments here has prevented me from diving in. I
appreciate your interest in this, and know you'll do a fine job with 
it.


While it's understandable that Git can't handle LC's binary files, one 
of

the strongest benefits of "The xTalk Way" is visual design.

This is why so many of us have written libraries to automatically
instantiate mobile-specific controls for us from LC-native objects, 
because
it lets us enjoy the fluid development workflow that characterizes 
xTalks,
rather than defining objects by typing long 

Re: Applescript Fails in Standalone on Mac Built with 8.1.6

[Brian Milby via use-livecode]

 
 

 I'm so new I can't address the history but seeing where the fix was 
implemented it should not fall out unless the build process is significantly 
changed.It is in the same place all of the language localization files are 
specified.
 

 
Thanks,
 
Brian
 

 
 

 
>  
> On Aug 18, 2017 at 9:58 AM,   (mailto:use-livecode@lists.runrev.com)>  wrote:
>  
>  
>  
>  Mark Wieder wrote:  >  On 08/17/2017 10:06 PM, Sannyasin Brahmanathaswami 
> wrote:  >   >>  So, why does apple script return execution error when run 
> from 8.1.6  >>  standalones?  >   >  Looks like the bugfix is on the way:  >  
>  >  http://quality.livecode.com/show_bug.cgi?id=16029 As far back as I can 
> recall, at least 15 years, the AppleScript dictionary periodically falls out 
> of the build process. Now and then we find yet another release where the AS 
> Dict is missing, later reinstated, and later absent. Is there something about 
> AS in the build process that makes that one resource uniquely difficult to 
> include consistently? -- Richard Gaskin Fourth World Systems Software Design 
> and Development for the Desktop, Mobile, and the Web 
>  
> ambassa...@fourthworld.com http://www.FourthWorld.com 
> ___ use-livecode mailing list 
> use-livecode@lists.runrev.com Please visit this url to subscr
ibe, 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: Developing first on android

[Brian Milby via use-livecode]

What about a non-binary stack file format?  Something XML based and derived
from the actual in-memory stack object (would need to be integrated with
the IDE/engine to be really useful though - to allow seamless/native
import/export).


> Mike Kerner wrote:
>
> > I've been thinking of developing a deconstructor to use with Levure.
> >  The idea is that you would lay out the objects, but then the
> > deconstructor would pull all the properties of each object, put them
> > in a YML, JSON, or other similar file, and then they would be built in
> > the app by  script, when needed.
>
> That would be handy.  I've considered making one, but the cost/benefit
> relative to other commitments here has prevented me from diving in. I
> appreciate your interest in this, and know you'll do a fine job with it.
>
> While it's understandable that Git can't handle LC's binary files, one of
> the strongest benefits of "The xTalk Way" is visual design.
>
> This is why so many of us have written libraries to automatically
> instantiate mobile-specific controls for us from LC-native objects, because
> it lets us enjoy the fluid development workflow that characterizes xTalks,
> rather than defining objects by typing long blocks of object definitions in
> scripts, which is a very C way of doing things.
>
> Automating use of Git through binary->script decomposers allows developers
> the full benefit of the best of both xTalk and lower-level workflows.
>
___
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: Using '@' to mark pass-by-reference (was Re: synonyms)

[Mark Waddingham via use-livecode]

On 2017-08-18 17:18, Bob Sneidar via use-livecode wrote:

That actually is a great explanation which solves a mystery I've often
wondnered about, which is how a handler with a different variable name
can contain the *actual* original variable. I thought the engine
actually created a new variable and copied the incoming value to it,
and then reversed this operation on return. Aliasing makes perfect
sense.


That's what would call 'inout' parameter mode.

For most languages which exist today, the way you can specify to pass 
parameters to functions distills down into 4 types (generally these are 
called parameter 'modes'):


  - by-ref
  - by-value (also called 'in')
  - copy-out (generally called 'out')
  - copy-in-copy-out (generally called 'inout')

Let us imagine we supported all these modes and we had a handler with 
signature:


  command myHandler @yRef, in pIn, out rOut, inout xInOut

Called with

  myHandler tRef, tIn, tOut, tInOut

The 'by-value'/'in' mode is what we are most familiar with. On entry to 
the handler the value in pIn is copied into the receiving variable tIn.


The 'out' mode is similar to what you describe. On entry to the handler 
rOut contains nothing; on exit from the handler, the value in rOut is 
'copied back' into the passed variable tOut.


The 'inout' mode is a mixture of the two: on entry tInOut is copied into 
xInOut, and on exit xInOut is copied back into tInOut.


In the 'by-ref' mode there is no copying at all - mutations to the 
receiving variable yRef are actually mutations to the passed variable 
tRef. i.e. yRef doesn't really exist at all.


The by-ref mode can emulate all of the other modes - you just have to 
code with some rules:


To use a by-ref parameter as 'in' - you must not change the value of the 
parameter in the handler being called.


To use a by-ref parameter as 'out' - you must not read the parameter at 
all and only change the value of the parameter except just before you 
exit/return.


To use a by-ref parameter as 'inout' - you can read the parameter at any 
point, but only change it just before you exit/return.


In most languages, the 'copy-back' part of the 'out' and 'inout' modes 
only generally happen for normal handler exit - they don't happen if you 
throw an exception.


Now, having said all of that - there is actually a fifth parameter mode 
'call-by-name' which at least one language had - ALGOL. Basically this 
meant (IIRC) that you passed in the symbolic expression to the receiver 
so it acted as some kind of macro:


  foo(tArray[I]) - inside foo, any reference to that parameter would 
re-evaluate tArray[I] in the context of the caller.


The reason I mention this is because the way LiveCode does by-ref 
parameters for array elements is *almost* like this - but not quite as 
unwieldy. When you do:


  command myHandler @xVar
put 100 into xVar["baz"]
  end myHandler

  local tArray
  myHandler tArray[tIndex1][tIndex2]

What actually happens is somewhat equivalent to the following:

  local tArrayPath
  put tIndex1 into tArrayPath[1]
  put tIndex2 into tArrayPath[2]
  myHandlerModified tArray, tArrayPath -- a second parameter has been 
added here


With

  command myHandlerModified @xArray, pArrayPath
put 100 into xArray[pArrayPath]["baz"]
  end myHandlerModified

Basically, the 'path' is frozen before the call, but implicitly used 
within the call when mutating the by-ref variable.


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: [ot] Richardevm pollution

[Richard Gaskin via use-livecode]

Mike Kerner wrote:

> We have another abuser on the forums
> Admins!  Attack!

The moderators that read this list regularly (Klaus and myself - are 
there others here?) tend to read the forums with the same frequency.  So 
we'll see it there about as quickly as we see a note here.  But our 
ability to handle it efficiently is limited, so unless we have a pile of 
free time on our hands we'll likely just send a note to the admins.


The best way to reach forum admins is to send a support request to 
on-rev.  If urgent, not that in the subject line.


--
 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: [ot] Richardevm pollution

[Klaus major-k via use-livecode]

> Am 18.08.2017 um 17:13 schrieb Mike Kerner via use-livecode 
> :
> 
> We have another abuser on the forums
> Admins!  Attack!

DONE! :-)

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

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
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: Using '@' to mark pass-by-reference (was Re: synonyms)

[Bob Sneidar via use-livecode]

That actually is a great explanation which solves a mystery I've often 
wondnered about, which is how a handler with a different variable name can 
contain the *actual* original variable. I thought the engine actually created a 
new variable and copied the incoming value to it, and then reversed this 
operation on return. Aliasing makes perfect sense. 

Bob S


> On Aug 18, 2017, at 08:13 , Mark Waddingham via use-livecode 
>  wrote:
> 
> In fact, what is happening is aliasing of variables:
> 
>  myHandler @tFoo -- when tFoo is passed to myHandler, xFoo1 in myHandler is 
> aliased to tFoo
> 
>  command myHandler @xFoo1 -- xFoo1 as a variable does not exist, it is an 
> alias to the calling var
>myOtherHandler @xFoo -- xFoo *is* tFoo, we are passing by-ref again so use 
> @ which 'passes the alias on'
>  end myHandler
> 
>  command myOtherHandler @xFoo2 -- xFoo2 as a variable does not exist, it is 
> an alias to the calling var
>answer xFoo2 -- xFoo2 *is* tFoo
>  end myOtherHandler
> 
> Perhaps I'm not explaining this very well - or there is something I'm 
> missing...
> 
> 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: Using '@' to mark pass-by-reference (was Re: synonyms)

[Mark Waddingham via use-livecode]

On 2017-08-18 17:14, Bob Sneidar via use-livecode wrote:

Not sure I understand this allegory. Do you mean that there might be
dragons all over the place waiting to eat me? Or do you mean there may
be dragons waiting to eat different bits of me in different places? Or
do you mean they were about to eat the kettle of fish when a much more
appetizing meal walked into the cave i.e. me? And how did a kettle of
fish get into a dragon cave in the first place?


Lol! Any and all of those things I think...

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: Developing first on android

[Mike Kerner via use-livecode]

Sorry, I assumed everyone was at Global, yesterday.  During the keynote, an
interview with Digital Pomegranate was shown.  During that interview, there
was a lengthy explanation about building LC apps, and things that they do.

On Fri, Aug 18, 2017 at 11:04 AM, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I blame Spell Checker.
>
> Bob S
>
>
> > On Aug 18, 2017, at 07:56 , Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Who is "Pomegranate" and where was this message? In a quick search of
> recent posts here I was unable to turn up anything from that user.
>
>
> ___
> 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: Using '@' to mark pass-by-reference (was Re: synonyms)

[Bob Sneidar via use-livecode]

I did once. After that it was pretty easy. 

Bob S


> On Aug 18, 2017, at 06:53 , Mike Kerner via use-livecode 
>  wrote:
> 
> I understand the difference.  I'm just trying to help with the mental
> arithmetic.  I, and others, I'm sure, will constantly forget where the "@"
> goes, for instance.


___
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: Using '@' to mark pass-by-reference (was Re: synonyms)

[Bob Sneidar via use-livecode]

Not sure I understand this allegory. Do you mean that there might be dragons 
all over the place waiting to eat me? Or do you mean there may be dragons 
waiting to eat different bits of me in different places? Or do you mean they 
were about to eat the kettle of fish when a much more appetizing meal walked 
into the cave i.e. me? And how did a kettle of fish get into a dragon cave in 
the first place? 

Bob S


> On Aug 18, 2017, at 06:48 , Mark Waddingham via use-livecode 
>  wrote:
> 
> General references (I don't think using the term 'pointer' is appropriate) 
> are a whole different kettle of fish which come with dragons waiting to eat 
> you all over the place...


___
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

[ot] Richardevm pollution

[Mike Kerner via use-livecode]

We have another abuser on the forums
Admins!  Attack!

-- 
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: Using '@' to mark pass-by-reference (was Re: synonyms)

[Mark Waddingham via use-livecode]

On 2017-08-18 15:53, Mike Kerner via use-livecode wrote:

I understand the difference.  I'm just trying to help with the mental
arithmetic.  I, and others, I'm sure, will constantly forget where the 
"@"

goes, for instance.


Okay so - the question to ask is - what would make you forget where to 
put the "@"?


In this case, if you want a by-ref parameter you have to put '@' before 
it in the signature, the proposal is to allow '@' to also be placed 
before the argument in a handler call for by-ref parameters... So it is 
entirely symmetric:


  command myHandler @xFoo
  end myHandler

  myHandler @tFoo

There is no 'de-referencing' operation as by-ref parameters implicitly 
de-reference on use - indeed, there's no need to have a de-reference 
operation because there is no such thing as a 'reference' which can be 
'put into' a variable (that would be general references - which this 
isn't about).


In fact, what is happening is aliasing of variables:

  myHandler @tFoo -- when tFoo is passed to myHandler, xFoo1 in 
myHandler is aliased to tFoo


  command myHandler @xFoo1 -- xFoo1 as a variable does not exist, it is 
an alias to the calling var
myOtherHandler @xFoo -- xFoo *is* tFoo, we are passing by-ref again 
so use @ which 'passes the alias on'

  end myHandler

  command myOtherHandler @xFoo2 -- xFoo2 as a variable does not exist, 
it is an alias to the calling var

answer xFoo2 -- xFoo2 *is* tFoo
  end myOtherHandler

Perhaps I'm not explaining this very well - or there is something I'm 
missing...


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: Developing first on android

[Bob Sneidar via use-livecode]

I blame Spell Checker. 

Bob S


> On Aug 18, 2017, at 07:56 , Richard Gaskin via use-livecode 
>  wrote:
> 
> Who is "Pomegranate" and where was this message? In a quick search of recent 
> posts here I was unable to turn up anything from that user.


___
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: Applescript Fails in Standalone on Mac Built with 8.1.6

[Richard Gaskin via use-livecode]

Mark Wieder wrote:

> On 08/17/2017 10:06 PM, Sannyasin Brahmanathaswami wrote:
>
>> So, why does apple script return execution error when run from 8.1.6
>> standalones?
>
> Looks like the bugfix is on the way:
>
> http://quality.livecode.com/show_bug.cgi?id=16029

As far back as I can recall, at least 15 years, the AppleScript 
dictionary periodically falls out of the build process.  Now and then we 
find yet another release where the AS Dict is missing, later reinstated, 
and later absent.


Is there something about AS in the build process that makes that one 
resource uniquely difficult to include consistently?


--
 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: Developing first on android

[Richard Gaskin via use-livecode]

Mike Kerner wrote:

> There might be another way to skin this cat.  I liked what Pomegranate
> said, which would also be a way to make apps even more levure/git-
> friendly, and would, I think, solve some of the Android layout issues
> that she was discussing - every object is created by a script, instead
> of using the LC IDE to do it.

Who is "Pomegranate" and where was this message? In a quick search of 
recent posts here I was unable to turn up anything from that user.


Was Jonathan's issue specific to layout? I had thought it was a 
reflection of a somewhat general sense that LC's feature set for Android 
is in some ways a subset of features found in LC's iOS engine.  To the 
degree that's true, Jacque's suggestion is a great one, since the range 
of things we can do in Android that aren't available on LC's iOS engine 
does seem smaller than the other way around.


If not limited to layout, how would the storage format of the objects 
affect that?  Whether rebuilt on the fly each time from script or 
instantiated from op codes in the binary stack file, an object is an object.


Even for layout, it seems the benefit of using Git-based workflows is 
for the benefits of using Git, in development, and would not seem to 
alter runtime behavior.  Have I missed some feature unique to 
script-only stacks?



The only downside I can think of to using any single OS for the majority 
of one's multi-platform development is to make sure you periodically run 
in each of the target OSes to ensure things look as they should.


For example on mobile, a menu button row/widget appears at the top of 
the layour in Android (not a bad choice, given that people tend to 
perceive layouts in reading order, left to right and top to bottom), but 
on iOS that main navigation control is placed below the region it 
affects, at the bottom of the card.


There aren't many things like that which differ so starkly, unless you 
get deeply into Android's Material Design.  But if we want to avoid 
having our apps look like something that was obviously designed for some 
other OS and hastily ported we want to learn those differences and 
support them in our layout code.



> I've been thinking of developing a deconstructor to use with Levure.
>  The idea is that you would lay out the objects, but then the
> deconstructor would pull all the properties of each object, put them
> in a YML, JSON, or other similar file, and then they would be built in
> the app by  script, when needed.

That would be handy.  I've considered making one, but the cost/benefit 
relative to other commitments here has prevented me from diving in. I 
appreciate your interest in this, and know you'll do a fine job with it.


While it's understandable that Git can't handle LC's binary files, one 
of the strongest benefits of "The xTalk Way" is visual design.


This is why so many of us have written libraries to automatically 
instantiate mobile-specific controls for us from LC-native objects, 
because it lets us enjoy the fluid development workflow that 
characterizes xTalks, rather than defining objects by typing long blocks 
of object definitions in scripts, which is a very C way of doing things.


Automating use of Git through binary->script decomposers allows 
developers the full benefit of the best of both xTalk and lower-level 
workflows.


--
 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: AW: htaccess rewrite rule to https let my apps stop working

[tbodine via use-livecode]

T.

Had a similar experience while migrating my site to https. What I found was
my standalones were missing the revsecurity.dll external. After rebuilding
those to include revsecurity.dll, the standalones were able to contact my
site and access stacks and other files there without changing my links from
http to https, since the htaccess was managing that.

Notes: On Windows, that must be at the same level as the standalone exe
itself rather than the externals folder. And codesign your externals as well
as standalones.

HTH,
Tom B.

 





--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/htaccess-rewrite-rule-to-https-let-my-apps-stop-working-tp4718561p4718572.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: htaccess rewrite rule to https let my apps stop working

[Matthias Rebbe via use-livecode]

Hi Tiemo,
although i was pretty sure that this works here i´ve checked again.
From the message box i called an .lc script  which exports db data. I used 
http:// as prefix and the data was returned w/o a problem.

Calling the same url from browser works the same. It isautomatically redirected 
by the server and the data is returned.

We are calling lc and php scripts on our server from our programs to fetch data 
and all is working.

Btw.: Maybe this is of interest for the one or the other.
Today we´ve created the first Rapidweaver page which uses a livecode server 
script for form processing and db access directly in a stack instead of showing 
that lc script in a frame. I´ve never have thought that this will work. It´s 
very simple to integrate.




> Am 18.08.2017 um 15:28 schrieb Tiemo Hollmann TB via use-livecode 
> :
> 
> Hi Matthias,
> Thanks for your example, I'll give it a try
> using these Rewrite rules, you could stay with plain http:// URLs in your LC 
> code? And LC doesn't notice the difference and everything works as before? Do 
> you call PHPs on your server? Could there be a difference between html and 
> php calls with return values?
> Tiemo
> 
> 
> -Ursprüngliche Nachricht-
> Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag 
> von Matthias Rebbe via use-livecode
> Gesendet: Freitag, 18. August 2017 14:42
> An: How to use LiveCode 
> Cc: Matthias Rebbe 
> Betreff: Re: htaccess rewrite rule to https let my apps stop working
> 
> Hi Tiemo,
> 
> it´s messed up.
> Please use the link
> https://dl.qck.nu//?dl=sample_htaccess.txt 
> 
> to download the textfile.
> 
> I´ve forgot to mention that you have to replace yourdomain.com 
>  with your domain.
> 
> Matthias
>> Am 18.08.2017 um 14:25 schrieb Matthias Rebbe via use-livecode 
>> >:
>> 
>> Hi Tiemo,
>> 
>> we are using the following code in the htaccess to redirect  http:// 
>> request (either with or without www) to https://www.multitronic.de 
>>  > >
>> 
>> RewriteEngine on
>> RewriteCond %{HTTPS} off
>> RewriteCond %{HTTP_HOST} ^yourdomain.com  
>> >$ [NC,OR] RewriteCond 
>> %{HTTP_HOST} ^www.yourdomain.com  
>> >$ [NC] 
>> RewriteRule (.*) https://www.yourdomain.com/$1 
>>  > > [R=301,L] RewriteCond %{HTTP_HOST} 
>> ^yourdomain.com  > >$ [NC] RewriteRule (.*) 
>> https://www.yourdomain.com/$1  
>> > 
>> [R=301,L]
>> 
>> 
>> if the sample code is mixed up then you´ll find it also here as text 
>> file for download
>> 
>> https://dl.qck.nu//?dl=sample_htaccess.txt 
>>  
>> > >
>> 
>> 
>> HTH
>> Matthias
>> 
> 
> ___
> 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: Using '@' to mark pass-by-reference (was Re: synonyms)

[Mike Kerner via use-livecode]

I understand the difference.  I'm just trying to help with the mental
arithmetic.  I, and others, I'm sure, will constantly forget where the "@"
goes, for instance.

On Fri, Aug 18, 2017 at 9:48 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2017-08-18 15:21, Mike Kerner via use-livecode wrote:
>
>> So how about trying to make it a little easier to read, and using "->"
>> instead (a 4D way of identifying pointers)?  The position of the symbol
>> indicates if we have are referencing or dereferencing.  ->a is a reference
>> to a (pointer to a), and a-> is dereferencing a (give me what a is
>> pointing
>> to).
>>
>
> Two reasons not to:
>
>   1) By-Reference parameters are not the same as pointers - in particular,
> dereferencing is implicit, and referencing is only allowed in the context
> of passing the parameter.
>
>   2) We already have a symbol '@' for marking by-ref parameters in handler
> signatures, so surely it makes more sense to use that in its directly
> equivalent position (on sending, as well as receiving).
>
> General references (I don't think using the term 'pointer' is appropriate)
> are a whole different kettle of fish which come with dragons waiting to eat
> you all over the place...
>
>
> 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
>



-- 
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: Using '@' to mark pass-by-reference (was Re: synonyms)

[Mark Waddingham via use-livecode]

On 2017-08-18 15:21, Mike Kerner via use-livecode wrote:

So how about trying to make it a little easier to read, and using "->"
instead (a 4D way of identifying pointers)?  The position of the symbol
indicates if we have are referencing or dereferencing.  ->a is a 
reference
to a (pointer to a), and a-> is dereferencing a (give me what a is 
pointing

to).


Two reasons not to:

  1) By-Reference parameters are not the same as pointers - in 
particular, dereferencing is implicit, and referencing is only allowed 
in the context of passing the parameter.


  2) We already have a symbol '@' for marking by-ref parameters in 
handler signatures, so surely it makes more sense to use that in its 
directly equivalent position (on sending, as well as receiving).


General references (I don't think using the term 'pointer' is 
appropriate) are a whole different kettle of fish which come with 
dragons waiting to eat you all over the place...


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

AW: htaccess rewrite rule to https let my apps stop working

[Tiemo Hollmann TB via use-livecode]

Hi Matthias,
Thanks for your example, I'll give it a try
using these Rewrite rules, you could stay with plain http:// URLs in your LC 
code? And LC doesn't notice the difference and everything works as before? Do 
you call PHPs on your server? Could there be a difference between html and php 
calls with return values?
Tiemo


-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag von 
Matthias Rebbe via use-livecode
Gesendet: Freitag, 18. August 2017 14:42
An: How to use LiveCode 
Cc: Matthias Rebbe 
Betreff: Re: htaccess rewrite rule to https let my apps stop working

Hi Tiemo,

it´s messed up.
Please use the link
https://dl.qck.nu//?dl=sample_htaccess.txt 

to download the textfile.

I´ve forgot to mention that you have to replace yourdomain.com 
 with your domain.

Matthias
> Am 18.08.2017 um 14:25 schrieb Matthias Rebbe via use-livecode 
> >:
> 
> Hi Tiemo,
> 
> we are using the following code in the htaccess to redirect  http:// 
> request (either with or without www) to https://www.multitronic.de 
>   >
> 
> RewriteEngine on
> RewriteCond %{HTTPS} off
> RewriteCond %{HTTP_HOST} ^yourdomain.com  
> >$ [NC,OR] RewriteCond 
> %{HTTP_HOST} ^www.yourdomain.com  
> >$ [NC] 
> RewriteRule (.*) https://www.yourdomain.com/$1 
>   > [R=301,L] RewriteCond %{HTTP_HOST} 
> ^yourdomain.com   >$ [NC] RewriteRule (.*) 
> https://www.yourdomain.com/$1  
> > 
> [R=301,L]
> 
> 
> if the sample code is mixed up then you´ll find it also here as text 
> file for download
> 
> https://dl.qck.nu//?dl=sample_htaccess.txt 
>  
>  >
> 
> 
> HTH
> Matthias
> 

___
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

AW: htaccess rewrite rule to https let my apps stop working

[Tiemo Hollmann TB via use-livecode]

Hi Mark,

I think the oldest version was build with LC 6.7. As far as I can see that
version supports https.
Is there any characteristic on the standalone, to identify the engine
version used?
I will give a redirect a try. Thanks for your ideas

Tiemo

-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag
von Mark Waddingham via use-livecode
Gesendet: Freitag, 18. August 2017 14:15
An: How to use LiveCode 
Cc: Mark Waddingham 
Betreff: Re: htaccess rewrite rule to https let my apps stop working

On 2017-08-18 13:58, Tiemo Hollmann TB via use-livecode wrote:
> Hello,
> 
> I attached a certificate to our domain and started switching our 
> domain / web from http to https, because of the security alerts of 
> some browsers saying that our site isn't safe. So far so good. Our web 
> hoster recommended to put a rewrite rule into the htaccess to redirect 
> all http calls on https.
> So far so good. That works fine with all URLs in a browser.

I wonder if using a URL redirect, rather than rewrite might work better:

https://www.digitalocean.com/community/tutorials/how-to-create-temporary-and
-permanent-redirects-with-apache-and-nginx

I might be wrong here but I think rewriting just changes the path which
apache uses to determine what to return; a redirect causes a 'Redirection'
return value to the client so the client can refetch at the (redirected)
URL.

> I can't just change all URLs in all my LC programs from http to https, 
> because my customers have lots of old version of my programs out 
> there, which are not anymore maintained, which were created with any 
> very old LC version I don't know anymore, etc.

Unless the distributed versions built with old versions of LiveCode were
built with HTTPS support built-in then they are very unlikely to work with
either a redirect or rewrite.

Even if you do a redirect/rewrite on the server, the client has to be able
to handle the protocol which the server produces correctly.

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


___
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: Using '@' to mark pass-by-reference (was Re: synonyms)

[Mike Kerner via use-livecode]

So how about trying to make it a little easier to read, and using "->"
instead (a 4D way of identifying pointers)?  The position of the symbol
indicates if we have are referencing or dereferencing.  ->a is a reference
to a (pointer to a), and a-> is dereferencing a (give me what a is pointing
to).

On Fri, Aug 18, 2017 at 9:15 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2017-07-04 17:39, Ben Rubinstein via use-livecode wrote:
>
>> May I hijack this thread to have another go at promoting my feature
>> request for a bit of syntax sugar around parameters which I _think_
>> would not have a very deep implementation requirement?
>>
>> http://quality.livecode.com/show_bug.cgi?id=8945
>>
>
> It is no longer a hijack - I've changed the name of the thread :)
>
> (Although I have hijacked your original post by rewriting the content
> slightly - I hope you don't mind too much!)
>
> The underlying problem here is that whether or not an argument passed to a
> handler is treated 'by value' or 'by reference' is determined by the
> handler at the point it is invoked - not at the point it is called
> (remember that the message path means that one call can end up invoking
> several handlers as it passes through the message path).
>
> This is the only way it can work at the moment because LiveCode Script
> does not require you to explicitly mark arguments that should be passed by
> reference - without that bit of information, the only thing you have to
> 'trust' is whether '@' is present in the signature of the parameter in the
> handler definition *when that handler is actually executed*.
>
> Ben's suggestion (which I think is a really good one - even though I've
> not commented on it at all up until now - including the original
> enhancement request) is that we use '@' as an explicit marker for whether
> an argument should be passed by reference.
>
> I can think of at least one other language which has a similar thing - C#.
> C# has both by-ref and by-value - and it requires 'ref' to be used on
> arguments to method parameters which are 'by-ref'. It requires this because
> C# allows method overloading - you can have two methods in a class with the
> same name as long as their parameters are different:
>
> class RefOverloadExample
> {
> public void SampleMethod(int i) { }
> public void SampleMethod(ref int i) { }
> }
>
> Because C# requires 'ref' on arguments it can disambiguate the call to
> 'SampleMethod' - SampleMethod(tFoo), SampleMethod(ref tFoo).
>
> [ For more details about this see https://docs.microsoft.com/en-
> us/dotnet/csharp/language-reference/keywords/ref ]
>
> The weak form of the proposal would not require @ before arguments to
> reference parameters, but would require that it is not present before
> arguments to value parameters:
>
>   command myHandler @xRef, pValue
>   end myHandler
>
>   myHandler tRefVar, tValueVar - fine
>   myHandler @tRefVar, tValueVar - fine
>   myHandler [@]tRefVar, @tValueVar - not fine: passing tValueVar by
> reference to by-value parameter
>
> The strong form of the proposal would require @ before arguments to
> reference parameters:
>
>   command myHandler @xRef, pValue
>   end myHandler
>
>   myHandler tRefVar, tValueVar - not fine: passing tRefVar by value to
> by-ref parameter
>   myHandler @tRefVar, tValueVar - fine
>
> The weak form would still allow you to make the 'accidentally passing the
> wrong argument to a reference parameter' coding fault, but at least if you
> used @ consistently then it would catch the 'passing the wrong argument to
> a value parameter' coding fault. The strong form would eliminate
> ref-parameter related coding faults entirely.
>
> Even in its weak form, there are a few other fringe benefits:
>
>   - we could allow @ to mean: I know this is a by-ref parameter,
> but I don't care about what it gets changed to, I just want it to be
>  on input
>   - we could allow 'put x into param(y)' if the y'th argument was marked
> with '@'
>   - if @ is used consistently then it solves the mismatched reference
> parameter markings in the message path problem:
>group: on myHandler @isRef
>card: on myHandler isRef -- oops, I forgot the '@'
>
> There is a very low risk, in my view, of breaking backwards
>>
>
> Ignoring lexical issues (i.e. @ being allowed in an identifier - which is
> only the case because of the way the parameter list of handlers is parsed -
> ick!), then the weak form has no backwards-compatibility issues as far as I
> can see.
>
> In terms of the lexical issue, then the change would mean that '@' would
> become a self-delimiting token - and not be allowed in identifiers.
>
> I can't imagine there is any reasonable code out there which uses '@' in
> identifiers, a bit like "'" is also allowed in identifiers - so changing
> that is probably 'completely' safe. Indeed, we are already considering
> removing various characters from the definition of identifier to allow a
> little more 

Using '@' to mark pass-by-reference (was Re: synonyms)

[Mark Waddingham via use-livecode]

On 2017-07-04 17:39, Ben Rubinstein via use-livecode wrote:

May I hijack this thread to have another go at promoting my feature
request for a bit of syntax sugar around parameters which I _think_
would not have a very deep implementation requirement?

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


It is no longer a hijack - I've changed the name of the thread :)

(Although I have hijacked your original post by rewriting the content 
slightly - I hope you don't mind too much!)


The underlying problem here is that whether or not an argument passed to 
a handler is treated 'by value' or 'by reference' is determined by the 
handler at the point it is invoked - not at the point it is called 
(remember that the message path means that one call can end up invoking 
several handlers as it passes through the message path).


This is the only way it can work at the moment because LiveCode Script 
does not require you to explicitly mark arguments that should be passed 
by reference - without that bit of information, the only thing you have 
to 'trust' is whether '@' is present in the signature of the parameter 
in the handler definition *when that handler is actually executed*.


Ben's suggestion (which I think is a really good one - even though I've 
not commented on it at all up until now - including the original 
enhancement request) is that we use '@' as an explicit marker for 
whether an argument should be passed by reference.


I can think of at least one other language which has a similar thing - 
C#. C# has both by-ref and by-value - and it requires 'ref' to be used 
on arguments to method parameters which are 'by-ref'. It requires this 
because C# allows method overloading - you can have two methods in a 
class with the same name as long as their parameters are different:


class RefOverloadExample
{
public void SampleMethod(int i) { }
public void SampleMethod(ref int i) { }
}

Because C# requires 'ref' on arguments it can disambiguate the call to 
'SampleMethod' - SampleMethod(tFoo), SampleMethod(ref tFoo).


[ For more details about this see 
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/ref 
]


The weak form of the proposal would not require @ before arguments to 
reference parameters, but would require that it is not present before 
arguments to value parameters:


  command myHandler @xRef, pValue
  end myHandler

  myHandler tRefVar, tValueVar - fine
  myHandler @tRefVar, tValueVar - fine
  myHandler [@]tRefVar, @tValueVar - not fine: passing tValueVar by 
reference to by-value parameter


The strong form of the proposal would require @ before arguments to 
reference parameters:


  command myHandler @xRef, pValue
  end myHandler

  myHandler tRefVar, tValueVar - not fine: passing tRefVar by value to 
by-ref parameter

  myHandler @tRefVar, tValueVar - fine

The weak form would still allow you to make the 'accidentally passing 
the wrong argument to a reference parameter' coding fault, but at least 
if you used @ consistently then it would catch the 'passing the wrong 
argument to a value parameter' coding fault. The strong form would 
eliminate ref-parameter related coding faults entirely.


Even in its weak form, there are a few other fringe benefits:

  - we could allow @ to mean: I know this is a by-ref 
parameter, but I don't care about what it gets changed to, I just want 
it to be  on input
  - we could allow 'put x into param(y)' if the y'th argument was marked 
with '@'
  - if @ is used consistently then it solves the mismatched reference 
parameter markings in the message path problem:

   group: on myHandler @isRef
   card: on myHandler isRef -- oops, I forgot the '@'


There is a very low risk, in my view, of breaking backwards


Ignoring lexical issues (i.e. @ being allowed in an identifier - which 
is only the case because of the way the parameter list of handlers is 
parsed - ick!), then the weak form has no backwards-compatibility issues 
as far as I can see.


In terms of the lexical issue, then the change would mean that '@' would 
become a self-delimiting token - and not be allowed in identifiers.


I can't imagine there is any reasonable code out there which uses '@' in 
identifiers, a bit like "'" is also allowed in identifiers - so changing 
that is probably 'completely' safe. Indeed, we are already considering 
removing various characters from the definition of identifier to allow a 
little more flexibility in the symbols we can use (not that I 
particularly want to add that many symbols, however I fear that adding a 
few more is unavoidable if we want to keep the language ergonomic).


My general feeling is that the weak form is much better than we have 
now, but the strong form is actually how things should be. Indeed, as 
'by-ref' is a more complicated concept in many ways than 'by-value' it 
seems fitting that it should be explicitly marked - especially as if we 
were able to move to the strong form, we would eliminate the 

Re: htaccess rewrite rule to https let my apps stop working

[Matthias Rebbe via use-livecode]

Hi Tiemo,

it´s messed up.
Please use the link
https://dl.qck.nu//?dl=sample_htaccess.txt 

to download the textfile.

I´ve forgot to mention that you have to replace yourdomain.com 
 with your domain.

Matthias
> Am 18.08.2017 um 14:25 schrieb Matthias Rebbe via use-livecode 
> >:
> 
> Hi Tiemo,
> 
> we are using the following code in the htaccess to redirect  http:// request 
> (either with or without www) to https://www.multitronic.de 
>   >
> 
> RewriteEngine on
> RewriteCond %{HTTPS} off
> RewriteCond %{HTTP_HOST} ^yourdomain.com  
> >$ [NC,OR]
> RewriteCond %{HTTP_HOST} ^www.yourdomain.com  
> >$ [NC]
> RewriteRule (.*) https://www.yourdomain.com/$1 
>   > [R=301,L]
> RewriteCond %{HTTP_HOST} ^yourdomain.com  
> >$ [NC]
> RewriteRule (.*) https://www.yourdomain.com/$1 
>   > [R=301,L]
> 
> 
> if the sample code is mixed up then you´ll find it also here as text file for 
> download
> 
> https://dl.qck.nu//?dl=sample_htaccess.txt 
>  
>  >
> 
> 
> HTH
> Matthias
> 

___
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: htaccess rewrite rule to https let my apps stop working

[Matthias Rebbe via use-livecode]

Hi Tiemo,

we are using the following code in the htaccess to redirect  http:// request 
(either with or without www) to https://www.multitronic.de 


RewriteEngine on
RewriteCond %{HTTPS} off
RewriteCond %{HTTP_HOST} ^yourdomain.com $ [NC,OR]
RewriteCond %{HTTP_HOST} ^www.yourdomain.com $ [NC]
RewriteRule (.*) https://www.yourdomain.com/$1  
[R=301,L]
RewriteCond %{HTTP_HOST} ^yourdomain.com $ [NC]
RewriteRule (.*) https://www.yourdomain.com/$1  
[R=301,L]


if the sample code is mixed up then you´ll find it also here as text file for 
download

https://dl.qck.nu//?dl=sample_htaccess.txt 



HTH
Matthias


> Am 18.08.2017 um 13:58 schrieb Tiemo Hollmann TB via use-livecode 
> >:
> 
> Hello,
> 
> I attached a certificate to our domain and started switching our domain /
> web from http to https, because of the security alerts of some browsers
> saying that our site isn't safe. So far so good. Our web hoster recommended
> to put a rewrite rule into the htaccess to redirect all http calls on https.
> So far so good. That works fine with all URLs in a browser.
> 
> BUT all of my LiveCode programs with http:// calls for php programs on my
> server don't work anymore. I get different errors.
> 
> I am not good with what is happening behind the scenes of htaccess rewrite
> rules and have no idea if and what I could do, beside of changing all http
> calls in my LC programs to https. My thinking was, that the rewrite rule
> would just switch each http call to https on the server, but keeps finding
> all html and php files. That works obviously fine with all URLs in a
> browser. But why doesn't my LC program likes that rewriting? The PHP
> programs should be found the same with https and should return the wanted
> value as with http - or not? How is LiveCode affected by this rewrite?
> 
> I can't just change all URLs in all my LC programs from http to https,
> because my customers have lots of old version of my programs out there,
> which are not anymore maintained, which were created with any very old LC
> version I don't know anymore, etc.
> 
> Any light on what is going wrong to my LC URL calls and if there is anything
> I can do is highly appreciated.
> 
> Tiemo
> 
> 
> 
> 
> 
> ___
> 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: htaccess rewrite rule to https let my apps stop working

[Mark Waddingham via use-livecode]

On 2017-08-18 13:58, Tiemo Hollmann TB via use-livecode wrote:

Hello,

I attached a certificate to our domain and started switching our domain 
/

web from http to https, because of the security alerts of some browsers
saying that our site isn't safe. So far so good. Our web hoster 
recommended
to put a rewrite rule into the htaccess to redirect all http calls on 
https.

So far so good. That works fine with all URLs in a browser.


I wonder if using a URL redirect, rather than rewrite might work better:

https://www.digitalocean.com/community/tutorials/how-to-create-temporary-and-permanent-redirects-with-apache-and-nginx

I might be wrong here but I think rewriting just changes the path which 
apache uses to determine what to return; a redirect causes a 
'Redirection' return value to the client so the client can refetch at 
the (redirected) URL.



I can't just change all URLs in all my LC programs from http to https,
because my customers have lots of old version of my programs out there,
which are not anymore maintained, which were created with any very old 
LC

version I don't know anymore, etc.


Unless the distributed versions built with old versions of LiveCode were 
built with HTTPS support built-in then they are very unlikely to work 
with either a redirect or rewrite.


Even if you do a redirect/rewrite on the server, the client has to be 
able to handle the protocol which the server produces correctly.


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

htaccess rewrite rule to https let my apps stop working

[Tiemo Hollmann TB via use-livecode]

Hello,

I attached a certificate to our domain and started switching our domain /
web from http to https, because of the security alerts of some browsers
saying that our site isn't safe. So far so good. Our web hoster recommended
to put a rewrite rule into the htaccess to redirect all http calls on https.
So far so good. That works fine with all URLs in a browser.

BUT all of my LiveCode programs with http:// calls for php programs on my
server don't work anymore. I get different errors.

I am not good with what is happening behind the scenes of htaccess rewrite
rules and have no idea if and what I could do, beside of changing all http
calls in my LC programs to https. My thinking was, that the rewrite rule
would just switch each http call to https on the server, but keeps finding
all html and php files. That works obviously fine with all URLs in a
browser. But why doesn't my LC program likes that rewriting? The PHP
programs should be found the same with https and should return the wanted
value as with http - or not? How is LiveCode affected by this rewrite?

I can't just change all URLs in all my LC programs from http to https,
because my customers have lots of old version of my programs out there,
which are not anymore maintained, which were created with any very old LC
version I don't know anymore, etc.

Any light on what is going wrong to my LC URL calls and if there is anything
I can do is highly appreciated.

Tiemo

 

 

___
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: Developing first on android

[Jonathan Lynch via use-livecode]

I am not too worried about layout. I make extensive setlayout scripts to adjust 
to all screen sizes.

But it seems like Android is the pickiest platform for other reasons as well, 
so why not start there first? After I get Augmented Earth to work fully on 
Android, I think I am going to make future improvements starting on Android 
first.

I got a lot of good tips from her presentation - so thank you Jacqueline:)

Sent from my iPhone

> On Aug 17, 2017, at 9:31 PM, Mike Kerner via use-livecode 
>  wrote:
> 
> There might be another way to skin this cat.  I liked what Pomegranate said,
> which would also be a way to make apps even more levure/git-friendly, and
> would, I think, solve some of the Android layout issues that she was
> discussing - every object is created by a script, instead of using the LC
> IDE to do it.  I've been thinking of developing a deconstructor to use with
> Levure.  The idea is that you would lay out the objects, but then the
> deconstructor would pull all the properties of each object, put them in a
> YML, JSON, or other similar file, and then they would be built in the app
> by  script, when needed.  That may give you additional flexibility when
> doing Android or ios because you could build your own geometry manager for
> mobile.
> The other thing that I've been thinking about was doing the layouts in a
> tool like Sketch (which would also mean that I could use some of the
> interface design service companies like uichest and pixelbuddha more
> easily).  That might also make the Android interface simpler to build and
> manipulate, but I haven't played with the idea enough to really
> understand it, yet.
> 
> On Thu, Aug 17, 2017 at 7:24 PM, Jonathan Lynch via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> I really appreciate something Jacqueline said in her presentation. If we
>> start with Android deployment first, we can be pretty sure it will work on
>> iOS.
>> 
>> How do you guys feel about this?
>> 
>> Sent from my iPhone
>> ___
>> 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