Re: propertyChanged?

[Mark Waddingham via use-livecode]

On 2017-06-12 20:23, Richard Gaskin via use-livecode wrote:

Thanks for that background, Mark.  If this message originates in the
engine, is there any chance it may one day become available as an
official message?


Yes - every chance - although I have to confess it is quite a bit lower 
than quite a large number of other things!



It would be enormously useful for apps like a web authoring system I
built recently, in which I had to keep track of all formatting changes
in each location they happened from in order to know when to update my
data store.

With a single message for that my code would be much simpler, just as
the IDE now has that opportunity with its private use of this message.


I'm not sure how long it might be before it becomes a fully supported, 
end-user feature (there's a great publish/subscribe model lurking there 
somewhere - at least tuned to an IDE-like applications needs - see 
further down) but we could evaluate moving the existing mechanism from 
IDE engine to all engines. The way it is implemented means that it has 
minimal performance impact if not used I believe (although I'd want to 
verify that).


Basically, whenever a property changes on an object a single bit is set 
on the object. Then at controlled intervals (via a 'throttle') the list 
of currently subscribed objects is iterated through and for each one 
which has been asked to dispatch a message, the message is sent. The 
messages always happen at a 'with messages' wait dispatch (either 
nested, or at the root event loop).


This approach was designed for IDE palettes - where immediate update 
(whilst script is running tight loops is never needed and would 
horrendously impact performance if it tried!), but is needed as soon 
after there is a small amount of 'idle' time so that what you see on 
screen is what is actually set internally.


So this may or may not work with your application - if you require 
knowing when things change at each step you'd be better off wrapping the 
calls which make the formatting changes with a handler which also 
dispatches a message (basically what the IDE front script does with some 
engine messages to make sure they are delivered in a uniform fashion).


I should point out that the goal of the IDE abstractions we've put in 
place since 8 is to eventually enable it to be something which 
introspects on a running LiveCode 'process' - whether that be in the 
same process or in a separate process. This changes design criteria a 
fair bit (and is also why the 8+ IDE is centered around using IDE APIs 
to wrap engine functionality, rather than trying to use the built-in 
engine functionality directly - the latter is not 'remoteable' in the 
way we might want it to be in the future - the former means you just 
change what the IDE APIs do, and then everything which uses them will 
work regardless however the underlying IDE decides to do things).


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: propertyChanged?

[Mark Waddingham via use-livecode]

On 2017-06-12 19:50, Richard Gaskin via use-livecode wrote:

Interesting pull request referenced in v8.0.5rc1's Release Notes:
https://github.com/livecode/livecode/pull/5570

When will the propertyChanged message be documented?  I didn't see it
in this latest build's Dictionary.


That probably shouldn't have had a release note as its an internal IDE 
engine only feature, for use by the IDE.


Due to this it is subject to change, so like most other things 
documenting it is not a high priority (people tend to complain about us 
changing even that kind of stuff regardless how much we say 'it might 
change in a future version'!). Also the engine functionality is provided 
by the _internal command namespace - which we do not document as a 
matter of rule.


Basically, these features are for the use by the IDE and only the IDE - 
if other things use them in the IDE then they might very well break the 
IDE which is not good for interoperation. Also we only test them as far 
as the IDE uses them - the value in having undocumented things like this 
which are only really meant to be used by the IDE is that it is far 
quicker to add the specific functionality needed which works perfectly 
when used in the correct way without having to consider dozens of 
potential edge-cases (which is generally true of virtually any public 
engine feature we add).


So they will bend and change to suit what we need to implement the IDE. 
If you want to use them you are free to do so, but generally the 
documentation is found by reading the source code - all of which is 
available on github - and you need to retest things in each new version 
to make sure something hasn't changed (of course, since all of this is 
open source code, a keen eye on the changes made to either IDE or engine 
can help here).


In many cases the internal engine features supporting the IDE are 
wrapped in LiveCode Script APIs (again subject to change but far less 
so) - and are easier to grok. Also many of the 'revIDE'/'ide' commands 
and functions have docs as comments in the 'revidelibrary'. (We should 
probably look into if we could suck these out into the dictionary for 
easier access...).


In this case, you can subscribe to the propertyChanged message by doing:

  revIDESubscribe "idePropertyChanged", the long id of 
tObjectIWantToWatch


This will then send the calling object an 'idePropertyChanged' message 
when one of tObjectIWantToWatch's properties changes. Unsubscription can 
be be done by using 'revIDEUnsubscribeAll' or 'revIDEUnsubscribe'.


Ali wrote this blog-post way back during the final DPs of 8 to help 
people start poking around in these APIs:



https://livecode.com/how-to-create-plugins-and-tools-with-the-livecode-8-0-ide/


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: Word delimiters

[Mark Waddingham via use-livecode]

On 2017-06-12 05:12, hlowe via use-livecode wrote:
Interestingly, there is no cross-refernce to TrueWord from the Word 
entry in
the 8.1.4 dictionary, though there is a cross-reference from TrueWord 
to

Word.


If you have a moment to file a bug in our quality center about that, it 
will get put on the list of docs amendments to make. We just need to 
make the xrefs symmetrical :)


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: LC 8.1.4 rc3 getting the rect of the videoPlayer returns different coords as in rc2

[Mark Waddingham via use-livecode]

Hi Tiemo,

On 2017-06-07 10:41, Tiemo Hollmann TB via use-livecode wrote:
I am resizing the videoPlayer object by script and export snapshots of 
the

videoPlayer.

In 8.1.2 or 8.1.3 I had to  adapt my scipt for placing and resizing the
videoplayer for Mac only by the hight of the menubar (before LC 8 the 
code

was on Win and Mac the same)

Now with LC 8.1.4 rc3 I again have to adapt the script for getting the 
rect
for the snapshot of the videoPlayer on Mac only by the hight of the 
manubar.


Has anybody encountered similar differences in getting rects depending 
on
the menubar? Is this wanted? Has anything changed in calculating the 
hight

of the menubar on Mac?


We've looked at your bug report and we think that there are two separate 
issues here.


The first is related to how the engine placed native layers - this was 
not quite right on Mac prior to 8.1.4-rc-2 - however should be fine in 
that release and later.


The second is related to using 'export snapshot from rect' - this is a 
screen-relative operation, which means the rect must be in screen 
co-ordinates. Appropriate application of 'globalLoc()' function should 
fix you up there - I've posted some sample code which corrects the 
sample stack in the bug report:


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

Warmest Regards,

Mark.

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

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

Re: livecode connect framework

[Mark Waddingham via use-livecode]

Indeed - that's why I put the day and date in my email.

Mark.

Sent from my iPhone

> On 9 Jun 2017, at 20:19, Richard Gaskin via use-livecode 
>  wrote:
> 
> Mark Waddingham wrote:
> 
> > On 2017-06-09 17:53, Richard Gaskin via use-livecode wrote:
> >> Tom Glod wrote:
> >>
> >>> hey everyone, I just learned about the livecode connect framework
> >>
> >> You're ahead of me - what is it?
> >
> > The talk is on Thursday 13th July - you can read the description here:
> >
> > https://livecode.com/global/#schedule
> >
> > To learn more about it you will need to wait until the conference!
> 
> The accordion layout prevents me from search all sections of the page at once.
> 
> What day is the LC Connect Framework on?
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: livecode connect framework

[Mark Waddingham via use-livecode]

Authentication is a key part of using web services, so I can safely say it will 
be touched upon.

If you can go into a bit more detail about what you'd like to know I can chat 
to Michael about potentially including something on that topic in his database 
/ cloud series of talks - he might have more time to cover oauth specifically. 
(He also knows much more about it than I do - which helps!).

Warmest Regards,

Mark.

Sent from my iPhone

> On 9 Jun 2017, at 20:05, Dan Brown via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
> Is the talk likely to touch on oauth strategies?
> 
> On 9 Jun 2017 7:56 pm, "Mark Waddingham via use-livecode" <
> use-livecode@lists.runrev.com> wrote:
> 
>>> On 2017-06-09 17:53, Richard Gaskin via use-livecode wrote:
>>> 
>>> Tom Glod wrote:
>>> 
>>> hey everyone, I just learned about the livecode connect framework
>>>> 
>>> 
>>> You're ahead of me - what is it?
>>> 
>> 
>> The talk is on Thursday 13th July - you can read the description here:
>> 
>>   https://livecode.com/global/#schedule
>> 
>> To learn more about it you will need to wait until the conference!
>> 
>> 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


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

Re: livecode connect framework

[Mark Waddingham via use-livecode]

On 2017-06-09 17:53, Richard Gaskin via use-livecode wrote:

Tom Glod wrote:


hey everyone, I just learned about the livecode connect framework


You're ahead of me - what is it?


The talk is on Thursday 13th July - you can read the description here:

   https://livecode.com/global/#schedule

To learn more about it you will need to wait until the conference!

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: [ANN] a gauge widget

[Mark Waddingham via use-livecode]

On 2017-06-09 20:46, Niggemann, Bernd via use-livecode wrote:

But I can not find what I did wrong in onSave. Still searching.


Check that all the vars which are saved into the props array have been 
assigned, and that the getRadiusAndCenterPoint() can't throw an error in 
that case.


I can't see anything wrong with your code either. File a bug if you 
don't get very far and I'll take a look on Monday to see what's going on 
in the engine :)


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: [ANN] a gauge widget

[Mark Waddingham via use-livecode]

On 2017-06-09 20:02, Matthias Rebbe via use-livecode wrote:

Another thing i noticed is that i cannot save the stack when the
widget is placed onto the stack.
I get the following error message:
“Can´t save stack … due to an error: Error writing stack (disk full?)"


That means that the OnSave handler in Bernd's widget is throwing an 
error in this case I think. What version of LiveCode are you trying the 
widget in?


The '?' at the end of the error message is important here - it is a 
suggestion that it *might* be that, but all the save methods in the 
engine only return a binary state IO_ERROR, or IO_NORMAL -  so by the 
time things unwind back up to where the error can be reported, it can 
only say it failed.


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: Price of LiveCode Global

[Mark Waddingham via use-livecode]

On 2017-06-09 16:44, Kaveh Bazargan via use-livecode wrote:
Oops, yes, VAT. It wasn't broken down on the page so not obvious. I had 
to

check how far the pound had dropped after election!!


Indeed, I've not looked since, but it dropped almost immediately after 
the exit polls were published.


[ Apparantly, in the UK, the exit polls for general elections have never 
been wrong by +/- 15 seats for the party which got the most seats - 
always nice to be reminded how large numbers of people's behavior can be 
reduced to very small random samples! ]


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: 64 bit desktop apps

[Mark Waddingham via use-livecode]

On 2017-06-08 21:16, Richmond Mathewson via use-livecode wrote:

I'm afraid you misread my question. When I stated I was running MacOS
10.4 PPC it was not in expectation of your leaping
up and down and say "Well, yes, Just for you, Richmond, we're going to
set things up for future versions of LiveCode to
build Mac PPC standalones."


Strictly speaking your question was (essentially) "So you don't believe 
in backwards compatibility then?" and then segued into a repeat about 
your usage of PowerPC based Macs... May I suggest you make your 
questions a little clearer (and perhaps less perjorative ;)) then you 
might actually get answers to what you actually meant to ask, instead of 
what it sounded like you asked.


In terms of upping the minimum version requirement for 9.0 to 10.9 then 
using this as reference:


   
http://www.everymac.com/systems/by_capability/maximum-macos-supported.html


Intel Macs fall into four categories:

   - Those which can only run up to 10.6

   - Those which can only run up to 10.7

   - Those which can only run up to 10.11

   - Those which can run current Mac versions

Continuing to support 10.6 and 10.7 is *extremely* difficult due to both 
Cocoa APIs and C++ support. Indeed, continuing to do so would mean two 
things:


  1) Leveraging new APIs on the Mac platform would be much harder, 
meaning that will happen even slower than it has done up until now.


  2) We can't use newer versions of the C++ standard which not only 
makes writing code for the engine harder, but also means that the 
chances of bugs and vulnerabilities increase (because new methods of 
writing C++ which are available in C++11 allow you to do so in much 
'safer' ways). Basically more regressions, more bugs, slower evolution.


I'd also point out (again) that we are talking about machines which are 
now > 10 years old (the last Mac which can only run up to 10.7 was 
released in 2007).


Furthermore, as people have reiterated several times, those OSes are not 
supported by Apple and are hugely insecure in the modern climate. Whilst 
I get what you are saying about 'reusing old hardware' it does seems a 
bit 'off' for 'us' to be palming off old machines onto 'developing' 
countries which we wouldn't use ourselves for those very reasons.


Richard's repeated suggestion that such machines should be 'Linux-ised' 
still always was and continues to be an excellent suggestion. Remember 
that as as time goes by the amount of up to date software which *can* 
run on them will dwindle to nothing - for the same reason as we have had 
to look long and hard at our platform support and make changes.


All Macs which can run 10.8 can also run 10.9 - which is the new minimum 
version for 9. So, yes, there is a set of Intel Macs released between 
2005 and 2007 which will not be able to run 9; but the number of Macs 
which fall outside of this group is many many times larger and will, of 
course, continue to grow year on year.


Warmest Regards,

Mark.

P.S. Please remember that LiveCode is open-source - 95% of changes we 
make to LiveCode as a whole go into the open-source repository. People 
are more than free to fork it and produce a 'legacy version' if they 
wish. A bit like a third-party group has done for FireFox.


--
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: Ben Beaumont jumps ship.

[Mark Waddingham via use-livecode]

On 2017-06-07 20:19, Bob Sneidar via use-livecode wrote:

I'm going to guess that is a Scottish colloquialism which involves
imbibing strong drink.


Hehe - https://en.wikipedia.org/wiki/Tilting_at_windmills

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: Changes to Msg Path from LC 7 to 8?

[Mark Waddingham via use-livecode]

tExt is all I'll say ;) (thanks to Ken Ray for that one)

Warmest Regards,

Mark.

Sent from my iPhone

> On 8 Jun 2017, at 22:07, J. Landman Gay via use-livecode 
>  wrote:
> 
>> On 6/8/17 3:19 PM, tbodine via use-livecode wrote:
>> Thanks for the encouragement, Richard. Looks like I'll be doing the "Humility
>> Workout" for quite some time.
>> For future list searchers who might have this same symptom, I found the
>> cause: One of my stack level scripts used "theme" as a parameter name, but
>> apparently that's a reserved term that is strictly enforced in LC 8.
>> Changing that allowed all my stack scripts to run normally.
> 
> That's the main reason I preface all variables with a letter, usually "t" for 
> handler-local variables, "g" for globals, "s" for script-locals, and "k" for 
> constants. You don't have to use the same letters but those have pretty much 
> become the standards (some people prefer "c" for constants, but I use that 
> for custom properties.)
> 
> If you adopt a system like this, you'll never have a naming conflict.
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: AW: 64 bit desktop apps

[Mark Waddingham via use-livecode]

On 2017-06-08 16:19, Paul Dupuis via use-livecode wrote:

On 6/8/2017 3:54 AM, Mark Waddingham via use-livecode wrote:

As a general request, can people let us know if they are relying on
externals on Mac which are currently 32-bit only?


Forgive the dumb question Mark, but how does someone tell whether
externals are 32 bit or 64 bit?


You can do it from the terminal:

otool -hv .bundle/Contents/MacOS/

Will list what executable 'slices' are in the external's executable.


In my first LC 8.1.3 64 bit build, I accidentally included
revVideoGrabber in my inclusions (we don;t use it, it had been checked
by accident). I discovered my OSX standalone would not even launch with
NO error messages or crash report. Only by opening the App bundle to
look around and double-clicking on the actual executable did I get a 
OSX

Terminal listing that showed error with LiveCode trying to start
revVideoGrabber and failing. Removing that from the Inclusion list
allowed creation of a Standalone that launched.


Could you file that as a bug? The S/B should ignore inclusions which are 
not available on the specified architecture and warn if there are 
mismatches.



Then we noticed that the default text font or text flow is different in
8.1.3 from 6.7.11 and test in our splash screen and a licensing dialog
is cut off under 8.1.3 vs 6.7.11. These are the details that add up to 
a

length migration time for large applications.


Yes - this is one thing which did change between 7 and 8 - unavoidably 
so as we moved to using CoreText to render text on Mac, rather than 
ATSUI.



As another example, in testing our LC6.7.11 app under LC8.1.4, I
discovered that the 'standaloneSaved pDestinationFolder' message 
returns:


 'C:/Users/Paul/Desktop/TestProject' under LC6.7.11. Note that the name
of the Standalone folder 'HyperRESEARCH' is not included and there is 
no

ending slash.

but

'C:/Users/Paul/Desktop/TestProject/HyperRESEARCH/" under LC8.1.3, Note
that the name of the Standalone folder 'HyperRESEARCH' is included and
there is a trailing slash


There has been a bit of churn in the SB messages since 6.7 - various 
attempts to fix various bugs. If you file a bug with this particular 
case, Panos will be able to check whether there is still a problem 
there.




On this topic, I applaud LiveCode for having 64 bit support. I curse
Apple for removing 32 bit support. I still have apps under LC6.7.11 and
LC 5.5.5 that now need to migrate to LC8.1.4+ in the next 6 months and 
I
am really annoyed at Apple for doing this. To be fair, we've known 
we've
need to catch up to current LiveCode releases for a good long while, 
but

between business pressures to add new features and fix customer visible
bugs, cleaning up code that needs fixing just due to engine changes
unfortunately always falls to last place. Now, fortunately or
unfortunately due to Apple's heavy handedness, it now moves to first
place for us.


Actually, things are not quite as they might appear from my reading.

Apple will not allow 32-bit slices in *new* apps submitted to the Mac 
App Store from January 2018, and will not accept updates to any app 
containing 32-bit slices from June 2018:


  https://9to5mac.com/2017/06/06/ios-11-32-bit-mac-app-store-64-bit/

Versions of Mac OS *after* High Sierra will no longer support 32-bit 
slices in apps:


   
https://www.imore.com/after-high-sierra-32-bit-games-mac-are-kicked-curb-0


So, right now, if you don't put your app into the MacAppStore - there is 
no need to worry.


If you are looking to submit a new app to MacAppStore then if you don't 
get it in before January 2018, it has to be 64-bit.


If you have an app in the MacAppStore, or will have before January 2018, 
then you have until June 2018 to make sure that it is 64-bit.


Everyone has until September 2018 (projected release date, based on 
history, for the version of mac after High Sierra) to make sure their 
apps can be 64-bit.


In regards to where LiveCode stands:

  - LiveCode started supporting 64-bit Mac from 8.x

  - In 9.0 we will be making 64-bit Mac mode the default for both IDE 
and Standalones


  - If you app works in 9.0, then the only thing blocking you from 
turning off the 32-bit slice is whether you use externals which are Mac 
32-bit only.


  - If you app works in 8.0, then the only thing blocking you from 
turning off the 32-bit slice is whether you use externals which are Mac 
32-bit only, or use QuickTime.


Hopefully this makes things a bit clearer.

We need to do a bit more research before deciding on the date of axing 
32-bit slices in LiveCode - however when we do this will *only* affect 
the 'develop' version at the time (i.e. 8.x will continue to be 
universal, as will all maintenance versions up to the axe date).


Again - please do contact me (off-list is fine, and better perhaps!) if 
any apps you have (and are intending to update / need to run on versions 
of Mac into the future) do rely on 32-bit Mac externals which we 
(Liv

Re: 64 bit desktop apps

[Mark Waddingham via use-livecode]

On 2017-06-08 12:34, Roger Eller via use-livecode wrote:
-- In a dark back office, Richmond, wearing dark glasses, a fedora, and 
a
tan trenchcoat, dumps a large bag of Monopoly money onto the table.  
Marks
eyes are now like saucers.  "Moot", Richmond says under his breath, 
then
leaves the room with a strut, as if he is carrying the world in his 
pocket.

--


If you could pay for things in Monopoly money, then that would be more 
than welcome! ;)


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: 64 bit desktop apps

[Mark Waddingham via use-livecode]

On 2017-06-08 12:28, hh via use-livecode wrote:

1) You are comparing 64bit and 32bit modes on a 64bit architecture.
This is the correct answer for my cheeky post above (by the way that
wasn't targeted, to the special case LiveCode and was a bit caused by
the fact that the first 64bit-Finder was 80-100% slower than the 32bit
variant).


The 32-bit Finder was Carbon and had been in development for years 
(moved forward from Arch to Arch).


The 64-bit Finder was completely rewritten in Cocoa - it would have 
taken a while for it to get optimized to the extent of the previous 
version - I suspect the performance differences were largely completely 
unrelated to even the move to Cocoa... Just the fact it was 'brand new 
code'.



2) My simple user experiences are that some 32bit apps perform on a
32bit architecture obviously faster than the 64bit variant on 64bit
architecture.

For example on Mac LC 6.5-standalones run the same optimized code (with
large imageData) on 32bit-architecture/slower CPU still 3-5 times 
faster

than the 64bit-LC 8.1.4 standalones variant on 64bit-architecture.


Heh - that's not comparing like with like though is it? ;)

The speed difference there is nothing to do with architecture of the 
CPU, but architecture of the engine. Which is a separate issue :)


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: 64 bit desktop apps

[Mark Waddingham via use-livecode]

On 2017-06-08 12:04, Richmond via use-livecode wrote:

So, backwards compatibility does not interest you?


Seriously - you ask that question?

LiveCode 9 still happily runs stacks which were written in the early 
days of MetaCard.


We are *extremely* careful not to break existing scripts and stacks - we 
either do accidentally (if that is so, we fix those issues with a high 
degree of priority); if intentionally then it is only for a very good 
reason.



I, for one, run Mac Machines running MacOS 10.4 PPC.


LiveCode 6.6.5 was the last version of LiveCode to support PowerPC on 
Mac - so given we are talking about LiveCode *9* you point is entirely 
moot.


A lot of these machine are being dumped in poor countries where they 
can be used

for good purposes.


I appreciate that, but since Apple haven't supported PowerPC for a very 
long time, and their toolchains (the things we need to use to build the 
engine) haven't for a very long time - there's little hope of PowerPC 
being resurrected in a future LiveCode version unless someone stumps up 
a very very large amount of cash (we are talking on the order of 
$100,000+ as a start, and then a significant amount for ongoing 
maintenance) and even then finding reliable hardware which has the specs 
needed to do engine development is becoming increasingly difficult, if 
not impossible.


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: 64 bit desktop apps

[Mark Waddingham via use-livecode]

On 2017-06-07 22:14, hh via use-livecode wrote:

64bit mode usually makes apps slower. So what's Apple's intention?
To make their own apps "relatively faster" by making all others slower?


Do you have some benchmarks to back that up? I'd be interested to know 
what sort of workloads the difference in processor affects.


For example, I ran the simple benchmarks we have in the engine source 
tree using Community 8.1.3 once for 32-bit and once for 64-bit. The 
first number is 64-bit, the second 32-bit:


Running RepeatForever...
3152 / 3136 ms
Running RepeatCount...
526 / 523 ms
Running RepeatWith...
407 / 412 ms
Running ArrayNameKeys...
Store[] 291 / 266 ms
Fetch[] 215 / 217 ms
Store[][] 465 / 413 ms
Fetch[][] 318 / 313 ms
Running ArrayIndexKeys...
Store[] 831 / 833 ms
Fetch[] 734 / 681 ms
Store[][] 1448 / 1403 ms
Fetch[][] 1278 / 1253 ms
Running ArrayStringKeys...
Store[] 309 / 313 ms
Fetch[] 215 / 261 ms
Store[][] 471 / 493 ms
Fetch[][] 345 / 387 ms
Running VariableFetchLocal...
Get Base 23 / 22 ms
Get Base[] 120 / 141 ms
Get Base[] 583 / 661 ms
Get Base[] 151 / 171 ms
Get Base[] 307 / 310 ms
Get Base[][] 152 / 177 ms
Get Base[][] 1072 / 1081 ms
Get Base[][] 214 / 240 ms
Get Base[] 454 / 463 ms
Running VariableStoreLocal...
Replace Into Base 32 / 31 ms
Replace Into Base[] 39 / 34 ms
Replace Into Base[] 180 / 174 ms
Replace Into Base[] 44 / 41 ms
Replace Into Base[] 93 / 78 ms
Replace Into Base[][] 48 / 42 ms
Replace Into Base[][] 304 / 285 ms
Replace Into Base[][] 61 / 54 ms
Replace Into Base[] 120 / 121 ms

So, certainly for variable access and repeat loop overhead, the 
differences are within the margin of error for such measurements - which 
would probably go away if I ran them on a completely empty machine and 
with increased number of iterations. The story is the exactly the same 
for the 'strings' benchmarks we have there too.


Most of Apple's apps are 64-bit only and have been for quite some time 
as there is no value in them shipping universal versions on any OS since 
10.6 (the only reason they would have done in previous versions is for 
apps which they had not yet ported to Cocoa and away from QuickTime) - 
all that does is waste download bandwidth and disk space.


Also, on the whole, Intel 64-bit machine code is can be much more 
efficient than 32-bit. The 64-bit Intel architecture actually has a 
measurable number of registers! 32-bit Intel processors have a huge 
amount of logic inside them to alias memory locations and such 
(essentially meaning memory accesses under specific conditions are akin 
to accessing registers). Of course all that costs silicon which could be 
used for better things - like caching and multiple cores. Basically, the 
64-bit Intel architecture is superior to the 32-bit one which does show 
its age quite a bit.


FWIW, when we got LiveCode on 64-bit Linux, Fraser did some performance 
tests which indicated on the whole, it ran about 5-10% faster than its 
32-bit counterpart. This was, admittedly, mainly in the area of graphics 
- since the types of things you do to rasterize graphics at this level 
benefits disproportionately from the number of registers available.


The thing is that most users won't ever notice whether an app is 32-bit 
or 64-bit because Apple's approach (universal binaries) means that it 
isn't possible to tell unless you go digging in Activity Monitor. (One 
would expect for this to be the case - Apple have done the processor 
architecture switch thing 3 times now - and in those cases it was to 
completely different architectures).


The main reason to not bother with 32-bit builds when there is no reason 
to is that it makes you much more efficient from the engineering point 
of view. It removes any question (when writing code) as to whether "is 
this correct for 32 and 64-bit" (admittedly, you try and structure your 
source base so only specific areas suffer from this overhead - but it 
still is there in the back of your mind). It means you only have to 
compile your source-base once (you don't magically get 64-bit code when 
compiling, you compile once for 32-bit and once for 64-bit). It 
eliminates one split in the test matrix. It halves the size of all your 
code deliverables - which is good for disk space and bandwidth (which, 
whilst less of an issue as time goes on - people do still tend to notice 
the difference between 500Mb download a 1Gb download!).


So, the reason Apple are doing it will undoubtedly be because of 
efficiency. It means they can focus all their energies on 64-bit Intel 
architecture (for Mac), and put all there resources into building and 
testing the 64-bit version of Mac.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ 

Re: AW: 64 bit desktop apps

[Mark Waddingham via use-livecode]

On 2017-06-08 08:48, Tiemo Hollmann TB via use-livecode wrote:
I would love to build 64-bit for Mac, but up to now, the Valentina 
extension

is still 32-bit, I hope they'll get it fixed by time.


I must confess that we always had the intent of dropping the 32-bit 
slice of the engine on Mac from 9 onwards. However, the case of people 
having to rely on 32-bit only externals potentially puts a spanner in 
that - so we might have to hold over to 'the next major version'.


The reason this would be good to do is that:

  1) Beyond the (legacy) 32-bit externals problem there is no advantage 
to the 32-bit slice


  2) It means our Mac builds will halve in time (which is important for 
CI, in particular) as it only has to compile once (and not twice) per 
build


  3) It is one less 'thing to think about' when doing Mac engine work.

  4) It makes LiveCode and the apps it builds more compact.

At the very least, we'll certainly be switching the IDE to 64-bit (by 
default) and make the SB build 64-bit only (by default) in 9+.


I'll see if we can get in contact with Valentina and find out what would 
be needed to do a 64-bit version.


As a general request, can people let us know if they are relying on 
externals on Mac which are currently 32-bit only?


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: 64 bit desktop apps

[Mark Waddingham via use-livecode]

On 2017-06-07 21:59, Richmond Mathewson via use-livecode wrote:

I disagree as there are plenty of Macs "out there" in the worldthat
run 32-bit systems.


Not that LiveCode supports.


Far better to have BOTH possibilities checked as default.


Only if there existed a Mac which can run LiveCode but cannot run 64-bit 
apps - which is the case for LiveCode 9.x as it supports 10.9+.


Indeed it would be far better to have no possibility at all (simpler) - 
just build for 64-bit since...


64-bit support has been around since 10.6, at that time there were 
machines which could run 10.6 which were 32-bit only.


However, all macs which will run 10.7 will run 64-bit apps.

Therefore, if LiveCode only supports 10.7 and above, then LiveCode and 
any apps you build with it need only be 64-bit.


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: Ben Beaumont jumps ship.

[Mark Waddingham via use-livecode]

On 2017-06-07 19:56, AndyP via use-livecode wrote:

Where is this blog post?.just gone to the blog page and cannot see any
references to staff changes.


It was in TWiL - Alex (one of our new employees) wrote his first blog 
post last week.


I did not mean to be alarmist or provocative but when two highly 
regarded

team members move on in the same month it does raise concerns.


They didn't move on in the same month. As Heather said, Ben went part 
time around 2 years ago, and continues to be.


I think there was a slight case of Richmond indirectly tilting at 
windmills (not that I ever do that, oh no, never ;)).


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: Ben Beaumont jumps ship.

[Mark Waddingham via use-livecode]

On 2017-06-07 18:00, AndyP via use-livecode wrote:

Worrying in view that Dr Peter Brett recently left as well.


As I said above:

"Ben still works for us part-time - so I'd describe that as a 
non-'event'."


In any case, I'm not sure why it is 'worrying' (especially as we have 
had two staff join us recently).


What would be worrying is if companies started locking their employees 
up in chains and never let them leave! ( It would also be illegal, in 
the UK at least ;) ).


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: 64 bit desktop apps

[Mark Waddingham via use-livecode]

On 2017-06-07 17:05, Charles Szasz via use-livecode wrote:

Apple announced that the next MacOS operation system after High Sierra
will only support 64 bit desktop apps. What version of LC supports
creating 64 bit apps?


LiveCode 8.x onwards.

Currently the IDE runs in 32-bit mode by default (you can change this by 
using 'Get Info' on the LiveCode app bundle, and unchecking the box).


The SB by default builds for 32-bit mode, but you can choose 64-bit by 
checking the appropriate box.


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: Ben Beaumont jumps ship.

[Mark Waddingham via use-livecode]

On 2017-06-07 15:21, Richmond Mathewson via use-livecode wrote:

Interestingly enough this event, and
others, do not seem to be reflected
currently on the LiveCode website.


Ben still works for us part-time - so I'd describe that as a 
non-'event'.


In regards to the other 'events' you refer to - I'll make sure updating 
the team page is on our website todo list.


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: Rooting around in the Forum: destructors

[Mark Waddingham via use-livecode]

On 2017-06-03 18:46, Richmond Mathewson via use-livecode wrote:

Not having looked at any sort of "serious" programming language since
about 1989 (I don't think that VB 6 is a serious language),
I find it hard to understand what a destructor is beyond a way to free
memory on a system that has constraints in that area.


Depends on your definition of 'serious'. I'd say that a language was 
'serious' if it allows to write full, complete programs. VB6 certainly 
did (after all, it had a huge installed user base for a very long time), 
as was HyperCard, as is LiveCode.



1. Does Livecode have something(s) that does the job of a destructor?


Yes.


2. If so, where is it and so on?


The 'delete*' messages are destructors for controls.

On a more general note this thread descended into a discussion of 
whether LiveCode is object-oriented or object-based:


  https://en.wikipedia.org/wiki/Object-oriented_programming

  https://en.wikipedia.org/wiki/Object-based_language

As I've said many times before, object-orientation is a methodology of 
programming. Any procedural language which has the equivalent of 
(mutable) structs can be used to program in that style relatively 
easily. Being 'object-oriented' doesn't mean the language can do any 
more than any other, just that it allows you to program in that style 
more easily - with compiler checking via explicit syntax for 
object-oriented formalisms).


LiveCode certainly has the equivalent of structs (assoc. arrays), and 
mutable parameter modes (@ before a parameter). Which means you can do 
object-oriented style programming - just as you can in C - indeed I do 
this a lot:


  command foobarCreate @xSelf
-- init xSelf as an array with the state for foobar
  end foobarCreate

  command foobarDoSomething @xSelf
-- use state in xSelf array to 'DoSomething'
  end foobarDoSomething

As to whether one calls a language object-oriented or not is largely 
down to 'what intrinsic features the language gives you to implement the 
object-oriented methodology'. In particular, an important feature there 
is to be able to define classes, with some form of inheritence and 
overriding of methods.


Now, since behaviors were introduced (and then chained behaviors), 
LiveCode has had something which is identical to the fundamental ideas 
of classes. A behavior script defines a class, the behavior chain allows 
inheritence, and the message path along that chain gives you inheritence 
and overriding. So, in that sense, LiveCode is definitely 
object-oriented.


However, one thing (all?) object oriented languages (in the classical 
sense) allow you to do is to define classes, create instances of those 
classes and store them in variables - LiveCode doesn't quite have this 
(LiveCode variables are either numbers/string or arrays), its 
object-orientation is centered around stacks, cards and controls. 
(Putting this on a slightly more abstract setting - LiveCode has 
object-orientation centered around a persistent object-tree, rather than 
transient object instances).


So LiveCode is definitely object-based, but perhaps not quite fully 
object-oriented in the classical sense - but it is certainly not that 
far off it.


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: HTML5 deployment: progress comes into sight

[Mark Waddingham via use-livecode]

Hehe - that works both ways Mike ;)

Sent from my iPhone

> On 2 Jun 2017, at 14:22, Mike Kerner via use-livecode 
>  wrote:
> 
> Mark,  and the rest of the team, having come from other development tools,
> where the team is not part of the community, it's nice that you guys are so
> actively engaged with the community, even when you're completely wrong
> because you disagree with me.
> 
> On Fri, Jun 2, 2017 at 7:46 AM, hh via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> We really should start to split this thread into branches, for example
>> 
>> [A] HTML5 deployment and "do as javascript" as already implemented
>> [B] HTML5 deployment and using widgets (not the browser widget)
>> [C] HTML5 in LC Builder (and the browser widget, javascript via FFI)
>> [D] LC Builder: Communication between widgets
>> 
>> Yes, there are intersections. Just an idea to have more 'structure'.
>> 
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
> 
> 
> 
> -- 
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>   and did a little diving.
> And God said, "This is good."
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: HTML5 deployment: progress comes into sight

[Mark Waddingham via use-livecode]

It has substantial and wide ranging implications - all to the good.

At the very least 'WASM' is more compact than asm.js and eliminates the 
compiling overhead which you have when you load a text based representation of 
the language.

We've got a fair bit of housekeeping to do (particularly in our build system) 
to be able to start leveraging it, but it is a case of when and not if.

Warmest Regards,

Mark.

Sent from my iPhone

> On 2 Jun 2017, at 07:53, Dan Brown via use-livecode 
>  wrote:
> 
> A bit OT but there's an interesting discussion here
> https://news.ycombinator.com/item?id=14458648 on the merits of WebAssembly
> vs JavaScript for in browser applications. As WebAssembly matures it will
> be interesting to see what implications (if any) it has for livecode html5
> i.e. will it ultimately become a better fit
> 
> 
> On 2 Jun 2017 3:08 am, "Andre Garzia via use-livecode" <
> use-livecode@lists.runrev.com> wrote:
> 
>> What I believe BR was referring to is that we can expose LC handlers to the
>> local JS context of a browser widget thus enabling liveCode.* calls. What
>> would be good, was to have functions (synchronous ones for the sake of
>> complexity) exposed as well so that calling a liveCode.* function from JS
>> on a browser widget not only would trigger the function but also return the
>> results.
>> 
>> Right now, we need to play musical chairs where JS calls a liveCode.*
>> handler, which doesn't return anything but executes, then the said handler
>> execute something in the JS context which is essentially a callback thus
>> forcing every call into an async call. I know pretty well how async JS
>> world is but even if we could simply have synchronous functional calls
>> there it would be awesome and open a whole new world to customized
>> experiences.
>> 
>> On Thu, Jun 1, 2017 at 9:50 PM, Mark Wieder via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> 
>>> On 06/01/2017 04:59 PM, Monte Goulding via use-livecode wrote:
>>> 
>>> Why not check for CopySpecial() if the object is a widget before passing
 to the owner? It makes more sense that the library handler a widget
>> exports
 is part of the message path. That way we can dispatch to the instance
>> and
 the instance can overload/override it if they want necessary.
 
>>> 
>>> +1. I like the way you think.
>>> 
>>> --
>>> 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
>>> 
>> 
>> 
>> 
>> --
>> http://www.andregarzia.com -- All We Do Is Code.
>> http://fon.nu -- minimalist url shortening service.
>> ___
>> 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: HTML5 deployment: progress comes into sight

[Mark Waddingham via use-livecode]

The thought did occur to me - whilst it 'sounds' like a good idea at first 
glance there's a lot of i's to dot and t's to cross especially as the goal of 
widgets is they should be indistinguishable from controls written in C++ direct 
in the engine.

As it stands many of the implications of that approach are hard to assess 
because the current message path behaviour is more a result of iterative 
additions over the years (the code is spread all over the place in the engine) 
rather than something which has been explicitly designed ahead of time.

For example - we added behaviours, then we added before/after, then we added 
chained behaviours. However the latter don't take into account before/after 
explicitly which means there are somewhat murky interactions there (it is 
actually quite difficult to see how those two features should interact as it 
stands).

We need to rework the message path is implemented for html5 as part of solving 
the 'wait' problem (we can't use the same trick as on mobile because web worker 
threads are not fully featured enough - and the unknown number of years before 
they will likely be is not something we can depend on) so that will help shake 
out all the skeletons and make deeper changes much easier to assess.

[ the wait problem is that android, iOS and emscripten don't allow nested 
dispatch of the system event loop - control has to return to system (i.e. Empty 
c stack) for them to be dispatched ]

TL;DR - it might well be the way to go, but some prep work is needed first. Or 
at the very least, some time spent pondering it in a dark room to make sure we 
don't back ourselves into a corner.

Mark.

Sent from my iPhone

> On 2 Jun 2017, at 00:59, Monte Goulding via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
> 
>> On 1 Jun 2017, at 8:27 pm, Mark Waddingham via use-livecode 
>> <use-livecode@lists.runrev.com> wrote:
>> 
>> Would export fooCopySpecial() as a function accessible from LCS where you 
>> can do:
>> 
>>  fooCopySpecial(the long id of widget 1, ...)
> 
> Why not check for CopySpecial() if the object is a widget before passing to 
> the owner? It makes more sense that the library handler a widget exports is 
> part of the message path. That way we can dispatch to the instance and the 
> instance can overload/override it if they want necessary.
> 
> Cheers
> 
> Monte
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
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: HTML5 deployment: progress comes into sight

[Mark Waddingham via use-livecode]

On 2017-06-01 12:34, Roger Eller via use-livecode wrote:

LOL @ invoke!  You need to rename Widgets to Spells.  #widgetcraft


Heh - I hadn't thought of that connotation :)

Perhaps that means we have #widgetseers or #widgetmages too!

FWIW, 'invoke' is the name of the LCB VM's opcode for, well, invoking a 
handler. I didn't want to use 'call' or 'send' as they have a somewhat 
different meaning in LCS - which involves the message path.


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: HTML5 deployment: progress comes into sight

[Mark Waddingham via use-livecode]

On 2017-05-31 23:13, hh via use-livecode wrote:

Call, send , dispatch, do script ...
It is very impressive how the core team can still have all that
messaging in mind while developing LC Builder.


The problem here is what syntax to use in LCS to 'call into a widget' - 
widget's need to be able to expose public handlers which can be called 
from LiveCode Script (not just properties and events).



Now why not use kind of a mnemonic naming in LCB e.g.

   sendHandler  
   callHandler  
   dispatchHandler  
   doHandler  ?


The problem is that all the keywords (naturally) associated with 
'calling' something in another context are already taken (i.e. send, 
call, dispatch, do) and their context is the script of the object. So:


   call "foo" in widget 1

Means send the message 'foo' to the *LiveCode Script* side of the widget 
- it is not entirely clear how that could work to mean 'call the handler 
'foo' exported by the widget's implementation'.


I've pondered 'invoke' as a new keyword - but I'm not sure how much I 
like that, but it would 'fill the gap'.


The other way to slice and dice things is to make it so that any 
handlers you want to export to act on the widget internally are added as 
'library handlers'. e.g.


  widget foo
public handler CopySpecial() returns nothing
  ... do magic stuff ...
end handler
  end widget

Would export fooCopySpecial() as a function accessible from LCS where 
you can do:


   fooCopySpecial(the long id of widget 1, ...)

Or similar. This is closer to how the engine does syntax - which are all 
non-object based functions in C++, which then dispatch to the object. 
e.g.


   copy widget 1

Ends up calling a C++ function:

   MCInterfaceExecCopyControl(ctxt, ptr-to-widget-1)

Which then does:

   ptr-to-widget-1->copy()


We could still have

   do 

Re: HTML5 deployment: progress comes into sight

[Mark Waddingham via use-livecode]

On 2017-05-31 15:43, hh via use-livecode wrote:

The problem is the "one-way"-only:
I can't see any way to go back, from the page to the standalone.


That is a very good point.


= The browser widget has jsHandlers available.
= The standalone has to get the data from the page by guesses, in a 
loop.


If you can show or give us a solution for that, then we can have in 
some
scenarios even more by using the latest versions of the main browsers 
than we

get by using an embedded browser widget.

In sum:
Can the HTML5 standalone become a property "javascriptHandlers" that 
works as

in the browser widget?


Yes it can - I'll look into getting that (or something similar) done 
asap.


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: HTML5 deployment: progress comes into sight

[Mark Waddingham via use-livecode]

On 2017-05-31 14:30, Jonathan Lynch via use-livecode wrote:

Would it be possible to create a widget that links to an Inkscape
library that processes svg data and sends it back to the widget to be
displayed the way PNG is displayed?


No - two issues:

  1) Inkscape is an application - not a C library.

  2) Inkscape is GPL - therefore any solution involving it would be 
unusable in commercial.


FWIW I don't believe there are any complete open-source SVG C/C++ 
library implementations which are not GPL - but would be happy to be 
proved wrong.


Obviously WebKit has an implementation, but it is part of WebKit and not 
exposed as an independent component as far as I'm aware.


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: HTML5 deployment: progress comes into sight

[Mark Waddingham via use-livecode]

On 2017-05-31 13:18, Richmond Mathewson via use-livecode wrote:

Weel you could start with ALL SVG images made in Inkscape:
monochromatic "thingies" have limited use.


Or how about we start with the *standard* profiles for SVG and work up 
from there:


   https://www.w3.org/TR/SVGTiny12/

i.e. Let's walk before we try and run.

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: HTML5 deployment: progress comes into sight

[Mark Waddingham via use-livecode]

On 2017-05-31 10:38, Jonathan Lynch via use-livecode wrote:

A native svg object that accurately displays all svg files is
essential. I strongly support Mark's point on that issue. This is not
reinventing the wheel - it's attaching the already invented wheel to
the wagon.


Heh - well more accurately - attaching a LiveCode-compatible instance of 
the already invented wheel pattern to the LiveCode wagon ;)


Accurately displaying *all* SVG files might take quite a while (SVG is 
quite a large standard) - however, there are smaller subsets 
(Basic/Tiny) which cover the 'icon' use-case sufficiently. So they are a 
good place to start.


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: HTML5 deployment: progress comes into sight

[Mark Waddingham via use-livecode]

On 2017-05-31 04:31, Sannyasin Brahmanathaswami via use-livecode wrote:

Does this relate at all to " LCB to bind to  JavaScript APIs" ?


Directly? No - they are two distinct things.

However, running JavaScript (via LCB) in the HTML5 engine is equivalent 
to running JavaScript (via LCB) in a browser widget... The only 
'difference' being in the latter it happens in the browser widget you 
say, as opposed to the browser running the (HTML5) engine. Of course, 
making good use of LCB JavaScript bindings is contingent on having 
synchronous JS execution - which we have in the HTML5 engine (due to how 
it is implemented), but we don't with the browser widget (due to how the 
embedded browsers we use work).


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: HTML5 deployment: progress comes into sight

[Mark Waddingham via use-livecode]

On 2017-05-31 09:01, Dan Brown via use-livecode wrote:

I'll also add that for all the wonderful possibilities that LCB brings
there is a very real danger that countless hours will be spent using it 
to

re-invent the wheel.


That is true of every language ever implemented ;)

However, one of the goals of LCB is to allow it to be used as the 'glue' 
language allowing LiveCode Script to access 'things written in other 
languages' with (eventually) as much syntactic fidelity as you get with 
builtin-in engine functionality. Hopefully, reducing the need to 
re-invent the wheel to the minimum required to make other-world 
libraries look more LiveCode like.


i.e. One of its main goals is to rid ourselves of the need to 're-invent 
the wheel'.


Take for instance the displaying of svg's. This is a solved problem in 
the
browser and has been for a long time but in native livecode it's still 
in
the infant stages of implementation (to put it mildly). The best 
solutions

for user interface "widgets" are arguably being created in the form of
javascript libraries. To me it makes total sense to integrate with that
ecosystem and free up LCB / livecode developer hours for solving other
problems


True - but then if I want SVG icons in my app, and I don't need the 
browser widget at all then I might balk at the 70-100Mb bloat I have to 
add to Windows / Linux apps to get it. Furthermore, I might balk at the 
start up time of my app on mobile devices, whilst I use the browser 
widget to load all my SVGs and render them into PNGs at various sizes 
(unless you instantiate a browser widget for every SVG icon you want to 
use and want to put up with the restrictions that places on you, and the 
overhead in terms of use).


Certainly we need to be careful about 're-inventing the wheel' but that 
just means making good choices. In this case, the case for 'native' SVG 
support in LiveCode is overwhelming - the more lightweight it is, the 
faster it is, the more utility it has. (Also, the main problem here is 
'SVG as a replacement for PNG icons' which is a much smaller problem to 
solve than an editable SVG canvas - which is what you get if you go the 
via-browser route).


In terms of JavaScript 'widgets' in general, then we already have a 
reasonable strategy for using them now - you use a browser widget and 
load it in there. For example, FileMaker has a BrowserView element and 
there is a plugin 'React' which allows you to defined JavaScript 
controls and have them rendered in the browser. Admittedly using such 
things is a little trickier than we'd like at present - due to the lack 
of synchronous 'do as javascript'.


Anyway, I agree that using existing libraries and code as much as 
possible is probably the best way to expand LiveCode's capabilities - 
hence LCB :)


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: HTML5 deployment: progress comes into sight

[Mark Waddingham via use-livecode]

On 2017-05-31 09:02, hh via use-livecode wrote:

If I understand correctly Mark speaks currently about
[1] using a browser widget within the _HTML5 deployment_ (emscripten).


Heh - not in this case - however, it is an interesting idea. With the 
'do as javascript' functionality, scripts could already create a 
suitable element in the host page to allow this - although, admittedly, 
it would be quite cool if libbrowser had a 'html5' implementation which 
made it 'do the right thing'. (Pre-requisite for this is getting 'native 
layers' working in HTML5).


[2] using via FFI javascript or (part of) libbrowser _within_ LC 
Builder.


Yes - this was what I was mainly referring to. With 'do as javascript' 
(in HTML5 engine) you can already evaluate anything javascripty, but 
(again) it would be nice if LCB had a more 'native' way to do it without 
indirecting through it (also it would save a per-call JavaScript compile 
step)



Part [1], the current thread, will hopefully allow for example to have
the "sample
stacks" imageToolKit or the recent SVGplay-stacks in a HTML5
standalone. The speed
results will be very interesting.


If you have pure JS libraries you want to use, then you can already load 
these and access them (do as javascript, again) - you wouldn't 
necessarily need an 'embedded browser in HTML5' to do so.



Part [2] will allow the use of javascript libs _within_ our widgets
(not by talking
_via LC Script_ forth to and back from a browser widget).


Yes.

Using or not using another widget from LC Builder via LC Script arises 
the next

new question:
[3] How can widgets easily communicate amongst themselves?


At the moment widgets can communicate with each other via properties - 
there is a missing 'feature' at present in terms of allowing public 
(non-event) handlers to be called from 'outside the widget' (i.e. from 
script)... Although this is more a matter of finding the right syntax 
than anything else.


e.g.

A widget might have a 'Copy' handler - which does what you would expect 
'copy tObject' to do - so you might want to invoke this handler at 
certain points:


   call "Copy" of widget "Foo"

However, 'call' already has a meaning - it means 'send message to script 
object without changing context' (note I use the term 'script object' 
here to distinguish between the object as you see it in LCS, i.e. its 
script, and the object which backs it, i.e. the widget).


Basically, we can't use 'dispatch', 'call' or 'send' as their behavior 
is already taken for interaction at the script level (i.e. LCS handlers 
in the scripts of the objects) and *not* invoking a method on the 
'thing' behind the script (whether that be an engine control, or 
widget).


Indeed, we already made a slight mistake with 'do in ' which we 
do need to rectify (somehow) at somepoint - for a similar reason so that 
we can actually have 'do in ' to mean 'do the fragment of script 
in the context of the target object' (at the moment you can use it on a 
browser widget, but then the script is JavaScript and not LCS!).


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: HTML5 deployment: progress comes into sight

[Mark Waddingham via use-livecode]

On 2017-05-18 16:09, hh via use-livecode wrote:

[Excerpt from thread 'LC core team', now with a more approriate title.]

That being said, recently we are a hair's breadth away from getting
widgets working in HTML5 (hopefully running a little quicker than they
did before too):

 https://github.com/livecode/livecode/pull/5428


I got this out of 'work-in-progress' state today - there still seem to 
be
a couple of odd issues with specific widgets (the clock widget only 
renders
1 to 11, for example - not 12), however they are probably due to issues 
elsewhere

rather than the general approach.

Anyway, widgets should be coming (back?) to the HTML5 engine in 9-dp7 :)

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: Is there any way at all to have a mobile app simply resume rather than restart?

[Mark Waddingham via use-livecode]

On 2017-05-24 21:34, Mike Kerner via use-livecode wrote:
If you're referring to ios, look up "plist hack", here.  The only thing 
to

remember is that for each version of LC, you have to perform the hack,
again, until Edinburgh gives us a Standalone Settings option.


Like this:

  https://github.com/livecode/livecode/pull/5515

Alex is also working on adding all the options for 'background 
execution' too.


Both of these should appear in the next 9 DP (7), which will appear when 
we've
finally got everything working again (after updating Skia, toolchains 
etc.) -
the latter has been causing us significant headaches for quite a 
while...


Warmest Regards,

Mark.

P.S. Yes it took a long time to add this - a slight case of 
ball-dropping amongst

a vast variety of other things!

--
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: Funny pricing policy

[Mark Waddingham via use-livecode]

On 2017-05-26 12:58, Richmond Mathewson via use-livecode wrote:

Ah: so as I took the survey, but am not signing up for the conference
I should be getting a T-shirt . . . .


No - if you took the survey, then you get a coupon giving you a free 
t-shirt *if*

you sign up for the conference.

If you just took the survey, and do not sign up, you'll still be entered 
into

the gift voucher prize draw.

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: WannaCry [OT]

[Mark Waddingham via use-livecode]

On 2017-05-19 18:02, Bob Sneidar via use-livecode wrote:

I don't think it's a matter of programming standards. The methods used
to exploit systems are almost always something you could never have
guessed. Flaws in code can be extremeny difficult to see, as was the
case in the SSL Heartbleed bug. None of the devs saw the bug when it
was approved for merging. Seeing what it was and what it ought to have
been would be like seeing a needle in a haystack. I have thought for
some time that it is the nature of digital information and our human
minds incapacity to comprehend it in its real form that makes it
nearly impossible to produce "unhackable" code.


I'm not sure this is correct - and it is important that we don't 'lull 
ourselves into a false sense of security' by assuming that 'oh we could 
never have guessed that'.


The reality is that whilst exploiting a vulnerability in general is 
REALLY HARD (seriously, when I say REALLY HARD, I mean REALLY REALLY 
REALLY HARD and this is why you only tend to see exploits in things 
which have a very large reward for making that exploit - hackers have to 
consider ROI too!) - all they need is a vulnerability in the first 
place.


Eliminate the chance for vulnerabilities and you eliminate the 
possibility of exploits. Of course complete elimination is the ideal, 
but generally if you minimise the chance of introducing a vulnerability 
to the absolute minimum and you hugely reduce the chance of an exploit 
appearing (because finding vulnerabilities to exploit becomes much much 
harder).


Simplifying matters a bit, you can pretty much divide vulnerabilities 
into two classes:


  1) vulnerabilities introduced because of how something is written

  2) vulnerabilities introduced because of how something is done

The latter class (2), I will concede are much harder to spot. So called 
'information leakage' is a good example of (2) - this is where the 
method you use to do something causes 'secrets' to leak into an 
accessible channel. The thing is that such leakage can be caused by 
stuff the processor does (unreset registers in a call to a critical 
function, sideline data accessible due to the way HyperThreads are 
implemented in processor cores etc.). This is of critical concern in 
security stacks (such as SSL and strong encryption implementations) and 
is why the universal advice given is: never implement such things 
yourself - use a library which has the involvement of cryptography and 
security experts or employ such a person to do it for you.


The former class (1) essentially all boil down to mistakes in coding 
which mean that a suitably motivated hacker can use the mistake to 
execute arbitrary code which they have written - one of the biggest 
classes of these is 'buffer overruns':


  int main(int argc, char *argv[])
  {
 if (argc != 2)
   return 0;

 char t_buffer[32];
 sprintf(t_buffer, "Argument 1: %s", argv[1]);

 fprintf(stderr, "%s\n", t_buffer)
  }

Here I have a chance of being able to construct a string passed as a 
command line argument to my program which could execute arbitrary code 
encoded in the string I passed in - because I am potentially able to 
overwrite the stack at critical points to execute something that was not 
intended.


Another class of (1) is failure to sanitize inputs:

  int main(int argc, char *argv[])
  {
 if (argc != 2)
   return 0;

 char t_buffer[1024];
 snprintf(t_buffer, sizeof(t_buffer), "DELETE %s FROM 
MyImportantDatabase", argv[1]);


 RunSQL(t_buffer); // Mythical call for illustration only
  }

Here I've constructed an SQL query by inserting an unescaped string 
directly into an SQL statement that I execute. With this I can do 
anything to the database I like - just by using ';'.


I'd put my neck out and say that all vulnerabilities in case (1) can be 
prevented by strict programming standards and review (or better) using a 
language which doesn't let you make those kinds of mistakes in the first 
place.


So, in short, I'd perhaps suggest that all exploits we see are caused by 
one of two things:


  (1) Using tools which are too low-level for the job at hand, or people 
using tools which they are not experienced enough to use fully and 
absolutely correctly.


  (2) Writing code to do a task when you do not have enough 
domain-specific knowledge to do it correctly.


Just my two pence :)

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: English Like?

[Mark Waddingham via use-livecode]

On 2017-05-24 19:27, Mark Wieder via use-livecode wrote:

On 05/24/2017 08:11 AM, Martin Koob via use-livecode wrote:
I agree that LiveCode script should become more English like as time 
goes on

not only with english words but also with more natural(or intuitive)
grammar.


From your examples I think it would be more natural to type.


put the third index of tNumericArray into tFoo


The one that's always bugged me is

put item 2 of the rect of someObject into tVar

Rects have a defined order of items, and I can never remember whether
it's "left,top..." or "top,left..." and I end up looking it up every
time. I'd love to have a more normal (all right, English-like...
there... I've said it) way to remember and write this.


This is a very interesting example on two levels...

The first is in regards to 'English-like'-ness. In English we uniformly 
use 'top left' to describe, well, the 'top left' point of something. 
However, mathematical convention means that points are always 'across 
then down' - i.e. x, y.


The English phrase for this concept is 'top left' because there is a 
rule in English about the order of adjectives - interestingly if you get 
the order wrong, it just *sounds* wrong (e.g. mad old women vs old mad 
women). Of course, for non-native English speakers (as Tiemo pointed out 
a few days ago) it probably makes no sense at all *unless* you remember 
that rather odd English rule about adjective order.


[ Indeed, I suspect other languages also have a similar rule, but I 
don't recall ever being taught such a thing in French, German, Latin or 
Ancient Greek (which could be a facet of time admittedly - it being 20 
yrs since I studied them), but perhaps it is just something which we 
'pick up' through repetition until it gets embedded in deep parts of our 
brains. ]


So we do have the (syntactically) rather (apparantly) inconsistent and 
unintuitive:


  set the topLeft of button 1 to tLeft, tTop

However, conceptually it is 'correct' - topLeft is the correct way to 
express the concept *in English* and tLeft,tTop is how the concept is 
expressed in geometry.


If we were to use leftTop instead, it would be consistent with the 
'syntax' (if you like) of the underlying concept, but inconsistent with 
the 'syntax' for it in English.


End result: there is friction between the abstract concept (a point is 
x,y) and how it is expressed in language (English mandates top-left).


Now, I'm not sure this is 'fixable' in a way which would be 'better' for 
everybody, however, the name of the concept (topLeft) used in LiveCode 
is perhaps not the real problem... The problem comes (as Mark rightly 
points out) when you try and *manipulate* the thing you get when you ask 
for the rect, or the topLeft...


You have to do:

  put item 1 of tRect into tLeft
  put item 2 of tRect into tTop
  put item 1 to 2 of tRect into tTopLeft

Here we have what you might call 'magic constants' (1 and 2) - you have 
to *know* what those constants are, and use them explicitly to get the 
right thing (Alex pointed out in this thread that you could just define 
constants and/or globals for them - which works, but isn't exactly 
intuitive unless you know to do that).


A much more intuitive way to do this would be to be able to do:

  put the left of tRect into tLeft
  put the top of tRect into tTop
  put the topLeft of tRect into tTopLeft

Of course the issue here is that (in LiveCode) points and rectangles 
(and colors) are just strings - there is no extra information there. So 
when the engine tries to evaluate:


  the left of tRect

All it has to work with is the content of tRect which is a string of 
four comma separated numbers - but a string of four comma separated 
numbers could be a variety of things and not necessarily a rect.


One suggestion which immediately comes to mind is - oh we could just add 
some extra invisible 'meta' information to 'the thing returned by the 
rect property' marking string as a StringyRectangle so the engine 
*knows* it is a rectangle. However, that doesn't work because that meta 
information would be immediately lost if you concatenate your rect onto 
another string:


  repeat for with i = 1 to the number of controls
put the rect of control i & return after tControlRectList
  end repeat

Something which is done all the time in LiveCode. Furthermore, if the 
string came from somewhere which is not a rect property, then it 
wouldn't have it either - e.g. the rect is a substring of a text file 
from an external source.


However, what we could potentially exploit is the syntax of the thing in 
the string. At the moment when you do:


   the something of tString

The engine interprets this as a property get on an object - it converts 
tString to an object reference (internally) and then gets the property 
'something'. The syntax of an object reference is fixed. e.g.


   control 3
   field 2 of card 4
   button "moomin" of card "moominland"

It also happens to be completely 

Re: English Like?

[Mark Waddingham via use-livecode]

On 2017-05-24 23:47, Mark Wieder via use-livecode wrote:

On 05/24/2017 08:03 AM, Mark Waddingham via use-livecode wrote:

Syntax is an emotive issue (I could beat Python to death with some of 
the decisions they have made about syntax - but yet I still use it and 
slightly enjoy doing so for the purposes I use it for) - but it is not 
the be-all-and-end-all.


I could say the same for any of the computer languages I use.


Very true.

Of course, the thing here is that (in general) we have more control over 
the grammar and semantics of *programming languages* with constraints of 
course...


In a new language, we have complete control so (in theory) it should be 
possible to be unambiguous, consistent and intuitive as far as is 
possible... Assuming that one has 100% foresight and knows everything at 
the point of design. Failing that, one just does not add features until 
one is sure that they 'correct' (for some definition of 'correct') cf: 
switch in LCB.


In an existing language, we have significant constraints with regards 
backwards-compatibility and consistency to what is already there. In 
many cases, inconsistencies or un-intuitive is actually what you might 
call 'a lack of abstraction of a pattern' - an idea has been implemented 
for specific cases, but is actually an instance of a more general 
abstraction underneath. Of course in other cases, they come about 
because the remit of things that were considered when they were added 
was not wide enough and friction develops between what you have at the 
point of implementation, and what occurs to you later down the line (in 
some cases, many many years down the line).


The former generally allows things to evolve in a backwards-compatible 
way, but the latter it is a great deal harder - however that's where 
some sort of 'language versioning' mechanism (e.g. scriptVersion) can 
help. Of course you need the infrastructure for the latter to be able to 
make progress on those fronts - something we don't *yet* have in LCS.



And not just computer languages- the various forms of the irregular
verbs for instance...

Old English am had two plural forms: 1. sind/sindon, sie and 2.
earon/aron. The s- form (also used in the subjunctive) fell from
English in the early 13c. (though its cousin continues in German sind,
the 3rd person plural of "to be") and was replaced by forms of be, but
aron (see are) continued, and as am and be merged it encroached on
some uses that previously had belonged to be. By the early 1500s it
had established its place in standard English.


Hehe - I think I understand English's irregular verbs better now :)

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: English Like?

[Mark Waddingham via use-livecode]

On 2017-05-24 19:14, Mark Wieder via use-livecode wrote:

On 05/24/2017 08:03 AM, Mark Waddingham via use-livecode wrote:

Anyway, I shall now get off my (small?) soap-box. Again this is a 
discussion, there are lots of reasons why people don't choose LiveCode 
and we try our very best to determine them, and deal with them. There 
are certainly easier ones to tackle than adding a new 'syntax style' 
and of course we intend to address those first...


I just want to say that in spite of all the verbiage that showed up
overnight, this has been a most enjoyable thread to wake up to.


Heh - the verbiage being mostly my fault ;)

It is amazing how your mind can wander whilst staring at a terminal 
watching build instructions fly by!


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: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-24 18:44, Mark Wieder via use-livecode wrote:
As I said before, the lack of switch in LCB isn't because we don't 
want

a construct like that; just that we'd like one which doesn't have the
issues of C-style switch. (The best way to avoid people accidentally
introducing subtle bugs, is to ensure the language is designed to not
let them do so!)


It's *always* possible to introduce bugs, subtle or not. The best way
to avoid that is not to allow people to code 


Hehe - well that is certainly true - no one can argue with that!

Of course it is always possible to introduce bugs, but when you have
a control structure with a syntax which is almost begging for people
to make mistakes with it - surely it is worth considering how it could
be restructured to prevent that?

Indeed, the evidence that there is a problem here is held up by the
fact that more recent C compilers have explicit warnings which tell you 
about

potential errors in your switch statements - indeed, IIRC, there is even
a way to mark *explicit* fall-through in recent GCC or clang so that
you don't get a warning (which is important if you compile your code
with warnings-as-errors - we've started to turn more and more warning
flags into errors on our codebase to make sure that we don't introduce
the errors they warn about).

Generally compiler writers aren't going to spend time adding warnings
for things which *aren't* a common problem in end-user code - there's
far too many other fish to fry. So I generally think that if something 
in a

language design requires compiler writers to add explicit warnings
about potential problems in a construct then it suggests the construct
is perhaps not as good as it could be.

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: English Like?

[Mark Waddingham via use-livecode]

Hehe - what an enjoyable post to read - I couldn't resist 'biting'
on a few things though ;)

On 2017-05-24 17:57, Richmond Mathewson via use-livecode wrote:

Probably most of those programmers (like many well-established
LiveCode programmers) have invested so much time and effort
in learning the high level language(s) they already use that they are
unlikely to switch.


But if we can make them switch, that benefits LiveCode as a whole.


From a marketing point of view I believe that this question is more
pressing than the other one, just because people new to coding have
not got stuck in the groove of a particulalr programming language.


This is partly true - however, 'no man is an island', people develop
preconceptions about things over time which influence the choices in
the future.

I think it would be fair to say there might well be some sort of general
'meme' which floats around with regards to 'English-like' languages
and not necessarily a positive one.

Ergo - someone who has never been a programmer, who perhaps is thinking
of dabbling, might get put off by LiveCode because of its language, just
because they have that 'meme' embedded in that psyche without even 
trying

it properly.


What does need to be born in mind is that most of LiveCode's installed
user-base like their pudding the way LiveCode serves,
and changing the recipe to attract other people might only serve to
alienate current users rather than attarct others;
probably not worth the risk.


So we must make sure that the 'pudding' our current user-base isn't
diluted in the process. Most companies might start out producing only 
one
kind of 'pudding', but if they never diversify they risk ceasing to be 
at some
point when some other company produces 'pudding+' which people like 
better;
or if they can no longer produce 'pudding' because some 'nanny' decides 
that

a key ingredient should not be allowed anymore for the health of all.

Having all your eggs in one basket is a little risky...


My school now runs at exactly the size I want it to; those 'factories'
still run. Nobody, as far as I can tell, feels threatened by my
operation,
and I don't feel threatened by them. This is because, although we all
"sell" English as a Foreign Language, we do it in different ways; and
the children who come to my school are quite unlike those who go to
the other ones (which suits me 100%). There is room in the
multiverse of EFL for a variety of products.


It is great that you've reached a 'steady state' with your EFL school :)

However, it is perhaps fair to say that the world of EFL teaching does
not move at quite the same rate as the world of computers, there are 
lots
of very large 'pudding behemoths' out there who care not one whit for 
small
'pudding' manufacturers - and quite often trample them under foot 
without

a moment's thought.

I would also conjecture that the infrastructure requirements for our
particular kind of 'pudding' are somewhat larger than for a single
successful EFL school - and when combined with the fast paced 
environment
our 'pudding' is couched in, one needs to be careful that one can 
support

one's 'pudding' manufacture now and into the long term future.


No: a lot of the syntax isn't English-like, and the claims that have
been flying around about that ever since HyperCard seem almost
as crook as the "programming is easy" porky.


I agree with the statement that 'programming is easy' in general is a 
bit of a porky.


Most things are not easy when you get below a certain depth (kind of a 
tautology,

easy things generally being quite shallow in any domain).

However, I am firmly in the belief that many of the reasons why it is 
not 'easy'
right now are not because they could not be easier, but because like 
most
industries there is a huge inertia with how things are currently done 
and
when you are in the midst of doing something, you have to get it done, 
and perhaps

thinking about 'how to make it easier' is a distant thought.

In general I'd like to think that LiveCode does make some things easier 
than

other languages - and, in general, it is going in the right direction.


In regards to 'English-like' - then well let's just say LiveCode is 
'fibbidy-dab'
if 'English-like' is considered too inaccurate. In comparison with 
pretty much
ever other programming language which exists today and is still 
maintained,
I'd say LiveCode is significantly more 'English-like' than any of them 
thus

justifying its tag of 'English-like' ;)



"Intuitive" . . . ha, ha, ha. Human languages are not intuitive:
otherwise we'd all be learning a new language every 3 or 4 weeks
and the Tower of Babel wouldn't look like Trump Tower!


Indeed - human languages have evolved organically - but they have some
nice properties which most programming languages do not (particularly
in terms of how they reflect, at least in some part, how our brains
would appear to work - being something which has resulted from our 
brains

rather than the 

Re: breakpoint on parameter

[Mark Waddingham via use-livecode]

On 2017-05-23 17:45, Richard Gaskin via use-livecode wrote:

Matt Maier wrote:

I want to find out which parts of my code are making changes to a
control's parameter. Specifically, I've got an arrow that I want
to be black, and it is black when it's created, but then it turns
gray. I can't find the script that's turning it gray.

I don't know where to put a breakpoint in the script.

Can I put a breakpoint on that control's color parameter, so execution
stops whenever something modifies it and goes to the script that's
doing the modification?


There's a request to allow getProp and setProp for built-in object 
properties:

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

I would imagine this is a non-trivial request, given what I'm guessing
would be performance penalties.


I don't think the performance penalty is necessarily an issue any more 
(see forum thread I posted in another reply).


I did something years ago to how handlers in the message path worked 
(changed the search from linear to binary-per-handler-type) - I didn't 
think anything of it at the time (didn't even mention it). However, it 
has vastly reduced the overhead of dispatching a message through the 
message path.


Now, there are potentially other dragons lurking there with the request 
- in terms of interpretation of tokens which the engine reserves to 
itself, and the order in which the engine does things currently. I'd be 
a little concerned that either might cause significant 
backwards-compatibility issues. However, that just means it needs more 
thought and validation.



Perhaps Mark Waddingham could offer insight on this.


In terms of the original question - it is certainly worth of a 
enhancement request (to hook up a debug message for 'control property 
changed' situation, like we have one for variables).


Right now, though there might be a way in the IDE by using an IDE 
mechanism - the IDE has an API allowing an object to subscribe to a 
message when any properties of that object change:


  revIDESubscribe "idePropertyChanged", 

The idePropertyChanged message gets sent to the object which calls 
revIDESubscribe. In that handler you can inspect the malfunctioning 
object's properties.


It might not be fine-grained enough (the engine coalesces such messages 
otherwise they would flood the IDE and grind things to a halt) - but it 
*might* give you some insight.


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: breakpoint on parameter

[Mark Waddingham via use-livecode]

On 2017-05-23 17:57, Mark Wieder via use-livecode wrote:

On 05/23/2017 08:45 AM, Richard Gaskin via use-livecode wrote:


There's a request to allow getProp and setProp for built-in object
properties:
http://quality.livecode.com/show_bug.cgi?id=3126


...and it's from  2005, rev version 2.6...


The ball was dropped on that one somewhat:

  http://forums.livecode.com/viewtopic.php?f=66=14819

Monte submitted a PR, which kinda got lost in the huge behemoth that was 
the refactor. Definitely something to revisit at some point.


Of course, the fact I've still not managed to figure out a solution to:

  http://forums.livecode.com/viewtopic.php?f=66=18048

Irks me greatly.

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: English Like?

[Mark Waddingham via use-livecode]

On 2017-05-24 15:45, dunbarx via use-livecode wrote:
There is a far more important issue here. New learners are far more 
likely to

be coaxed into continuing to spend the time and effort, and to put away
their fears, if they see and use "put x into y". It is why we have 
stacks
and cards, and in the olden days, rolodexes. The original HC team did 
all

that on purpose.


Which 'new learners'? I can absolutely assure you there is no homogenous 
group there.


At one point after years of collecting surveys and analysing data we 
managed to divide up users and non-users into 7 (or thereabouts) 
distinct groups. Recently, taking a slightly different approach we have 
reduced this to 3 (7 was too fine-grained to actually be able to do much 
with, 3 is more manageable and seems to work much better in terms of 
targetting).


Why have we done this - because we need to actually *sell* LiveCode - 
nothing sells itself. Market segmentation and understanding your users 
and potential users is perhaps the most significant piece of selling.


( Okay, that's my marketing brain cell exhausted for a while ;) ).

It is quite possibly true that as many people get put off by LiveCode 
because of its 'English-like' language, who get sucked in because of it. 
We have to concede that point - if it weren't (at least in some part) 
true we wouldn't hear such phrases as 'babyish' and 'insult to 
intelligence' that are often heard about xTalks (and LiveCode in 
particular).


(Btw, @WilliamProthero: Please don't think I'm singling your comments 
out or taking offense by them - you echo words I have heard many times - 
as have all of us I suspect when we get asked by some - 'so what's 
LiveCode like').



Remember "for the rest of us"?

Experienced users are being academic and pedantic to raise this issue 
as if

it were something important. We need new users, not old ones.

No offence, please.


No offence taken - it is a discussion :)

However, it is important to realize that whilst it is not important to 
you (I get you are quite invested in LCS - as am I, much more than is 
ever apparent at times), it *is* important to others (otherwise we 
wouldn't get some comments about the language that we do).


Syntax is an emotive issue (I could beat Python to death with some of 
the decisions they have made about syntax - but yet I still use it and 
slightly enjoy doing so for the purposes I use it for) - but it is not 
the be-all-and-end-all.


I mentioned in my last post about the 'high priest' mentality - let us 
not risk falling into the same mentality but in reverse. The time for 
being an island in our own right passed with the passing of HyperCard. I 
think it is fair to say that, these days the world of computing is 
inordinately larger and much more diverse (look at the rise in the 
HTML/JavaScript world for just one example). There is huge value in 
being 'maverick', but it perhaps makes things much harder than they 
would be otherwise.


In reality the scripting language LiveCode has, whilst one of its 
greatest strengths IMHO (otherwise I can quite honestly say I wouldn't 
be here), is only one part of the ecosystem:


  - we have an interactive IDE which allows to edit and run code 'live' 
(for some definition of live)


  - we have a large GUI framework

  - we have large collections of libraries (script, externals, LCB) all 
giving high-level access to new

features

  - in order to build and maintain LiveCode we have a large 
infrastructure which allows us to build

on 7 different platforms.

Furthermore, we all want more features - we all want LiveCode to do 
everything in a way commensurate with how LiveCode 'is'. However, the 
breadth of knowledge that requires is immense - we do quite well as a 
team, sitting here (mostly in Scotland), we also do well as a (small, in 
the grand scheme of things) global community. Our current solution to 
help achieve this 'doing everything goal' is LCB and expanding its FFI 
capabilities - but that is a tool - it still needs knowledge and a great 
deal of effort to use.


We need to attract people from other worlds, and as many as possible - 
in there heads lies so much knowledge about how to use the concrete 
things which do exist in other language ecosystems (whether it be 
JavaScript libraries, Java libraries, C# libraries, ActiveX widgets, the 
list goes on and on) it seems quite sensible to ensure that we can fold 
that knowledge into our own so we can benefit from all that currently 
exists, and not just what a team of a few can generate, or a small 
community can generate.


Pre-7 what I suggested in my previous email was just not possible (in 
terms of a different syntax style) - or, should I say, the cost of 
attempting to do it would be far in excess of its potential benefit at 
the time. However, the main part of the refactor is done, we are in a 
very different situation technically - perhaps it really is something to 
seriously consider *if* the cost of doing 

Re: English Like?

[Mark Waddingham via use-livecode]

On 2017-05-24 14:52, Lagi Pittas via use-livecode wrote:

Mark

You are a big Tease.


Hehe - I don't mean to be a tease - making correct/good technical 
choices as to how things should work under the hood opens up an array of 
options for the future. We always try and design things with that in 
mind.


The 7 refactor was a large and rather difficult project, the full fruits 
of which have yet to become apparent. I can't say when some of the 
things we might like to do might happen, but at least they are possible 
now; when they weren't before.


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: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-24 14:55, Mike Kerner via use-livecode wrote:
On the CompileIt thoughts, that was what I was hoping we were going to 
get
with LCB (We already have Double-XX).  You could make any Mac Toolbox 
call

in CompileIt, which meant you could build any XCMD/XFCN to add to your
stack, but the syntax was still HC (with some restrictions).


LCB already has the ability to call C functions - which is what 
CompileIt allowed you to do (as far as I understand). However, there is 
a fair bit of glue required to deal with things like C arrays (which are 
just pointers at the end of the day) and structs - that is something we 
would like to make much easier.


[ That being said, many C APIs are moving towards 'opaque pointers with 
accessor functions' rather than exposing C-bound concepts - mainly 
because that way it is much easier to bind to 'higher-level' languages 
(Python, Ruby, JavaScript etc.) - which just mean you have to deal with 
opaque pointers. ]


What we don't have is much documentation as to *how* to use the features 
which already exist. Although there is some usage of the feature 
littered about in some of the engine LCB files, I can appreciate that is 
not that easy to grok.


We also have an almost complete Java FFI system - Ali is currently 
working on the final piece: adding 'Listener' support (essentially 
callbacks) which the Android APIs use ubiquitously - e.g. for event 
handlers on Views.


I can attest to the fact that LCB FFI (for C) works - our LCFM plugin is 
written in LCB and the FM Plugin API is wrapped in LCB using the current 
C FFI features which are available (doing so has given me some more 
ideas about how to make such things easier *and* safer - which is a 
critical factor these days).


For Mac / iOS APIs we need to add a way to wrap an Obj-C object, and 
implement a Delegate (although you can manipulate Obj-C objects through 
a C API so technically you can do this already, if you don't mind a bit 
of bit munching). However, now we have done Java, Obj-C should follow 
very quickly. Both Obj-C objects and Java objects have very similar 
(abstract) properties in terms of how you access from from native code; 
and Listeners and Delegates are very similar things also.


In terms of actually compiling stuff to native code - it is a goal we 
have; but there are a few more ducks to get in a row before it can 
become a reality.


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: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-24 12:35, hh via use-livecode wrote:

Switch in LCB -- Monte asked to have the opportunity to do the job:
http://forums.livecode.com/viewtopic.php?p=131509#p131509


Yes... I'm not sure I quite see your point (especially as he said 'Is 
there any chance switch will be implemented as a control structure.', 
not 'how would I implement...') :)


So...

Would some sort of switch statement be useful in LCB? Yes - it is a 
generally useful thing to have.


Has anyone proposed *any* design yet which does not have the flaws (we'd 
like to avoid) in the C-switch mode? No (well until it came up on the 
list the other day - there's a conversation going on that topic now 
which might bear some fruit, at least in terms of a design).


Is 'switch' more important than a number of other things we need to do 
to LCB to meet its goals? No I don't think it is because it is 
equivalent to if/elseif/.../endif and we have that. For example, right 
now more code economy (taking into account the current main uses of LCB 
in the LiveCode ecosystem) would probably be gained (for example) by 
adding a bridge between LiveCode script's string lists, and LCB's lists; 
or enumerations or ...


There's a whole chasm between saying 'I want a switch control structure 
in LCB' and having a switch control structure in LCB. If there wasn't 
then no-one on this list who programs for a living would have a job - 
last time I checked I can't just ask my computer 'please implement the 
switch control structure in LCB' ;)


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: English Like?

[Mark Waddingham via use-livecode]

On 2017-05-17 22:41, William Prothero via use-livecode wrote:

Folks:
It can be difficult for long term users of an application to
appreciate the “exceptions” to the philosophy of a dev app. I think
the livecode community is affected by “familiarity” over clarity
sometimes. For years (when Director was a viable dev platform), I had
a negative feeling about Hypercard type syntax. I had done some pretty
extensive programming in Hypercard and Supercard too. I liked the way
Director worked. I liked that it did not insult my intelligence by
requiring “put 3 into x” instead of the universal "x=3” syntax that
all algebra students lewarn in gradeschool, When Director died, I
looked around, held my nose, and jumped to livecode, and now I’m glad
I jumped that initial negative barrier. But, I take exception to the
many claims that livecode is “english-like” (in spite of the many
“english-like” commands), especially if you want to do the advanced
work that most of the users do.


Finally getting around to responding to this, as it is something which
interests me... Specifically, we often hear about how LC's syntax
'insults intelligence' or is 'babyish' etc. However, I have to say that 
I've

never understood *why* really.

The only two reasons I really come up with are:

  1) The 'high-priest' argument: programming languages should use 
somewhat arcane and obscure means of expression so that it limits who 
would want to / can use them.


  2) The 'burnt by limited English-like systems in the past' argument: 
the incorrect association between being 'English-like' syntax wise, and 
not being a full, general, programming environment (the point here being 
the limits are in the implementations, not in the concept).


I'd be really quite interested to know what other people think here.

In particular, the use of 'put X into Y' rather than 'X = Y' comes up
periodically.


The mathematician in me has to point out that the argument that 'X = Y' 
is 'better because we learn it in algebra' is technically erroneous. 
Algebra (and mathematics in general) operates on pure substitution - all 
values are singletons and the *only* thing which is equal to any value, 
is the value itself. Put another way, algebra does not have 'variables' 
in the sense we mean it in computing, 'X = 3' really does mean that X 
*is* 3, not that it should have 3 assigned to it, hence in a 
mathematical expression you can replace every occurrence of X *with* 3. 
(Modelling computer languages in the pure world of mathematics requires 
a bit of mental leap - what we consider a procedure is transformed into 
a function on the set of all possible states of the computer it is 
running on, rather than as sequential actions which occur on a single 
mutable state). Indeed, many languages choose ':=' for assignment and 
not '=' for this reason (it also means you don't have to use '==' for 
equality, and can use '=' which is a much better fit with what we do 
learn in Algebra).



Okay, so back to the point, if one wants a language to be readable and 
easily understandable it needs to be consistent. So, in isolation, 
perhaps have 'X := Y' for assignment might seem more economic. However, 
LiveCode's 'put' command is actually a fair bit more flexible. You can 
do:


  put X into Y
  put X after Y
  put X before Y

So if you have code which does:

  put "foo" after X
  put X into Y
  put "bar" before Y

You end up with:

  put "foo" after X
  Y := X
  put "bar" before Y

Here you end up having to do mental contortions because the sense of the 
'before' and 'after' forms are opposite to the assignment (copy) form - 
easy readability vanishes. In particular, put flows from left to right, 
in contrast to the right to leftness of ':='.


Certainly one could replace 'put X into Y' with 'X := Y', and even 'put 
X after Y' with 'X &= Y' - but what about before? 'X =& Y'? e.g.


  X &= "foo"
  Y := X
  Y =& "bar"

This looks really quite subtle to me, much easier to miss that one is 
'append' and the other is 'prepend'.


One thing I think LiveCode does do because of its slightly more verbose 
syntax is that it encourages readability (and as a result perhaps more 
maintainability) in code - something which other languages do not 
directly... Indeed, writing C programs which are readable and 
maintainable can take a great deal of time to learn *how* to do well - 
the language in and of itself doesn't really help you much at all. (That 
isn't to say it isn't possible to write unreadable code in LiveCode, 
because it clearly is - muddy abstractions can cause that as much as the 
syntax itself, but I'd like to think that LiveCode lends itself to more 
readable code by default... As subjective as that might be!)


Of course, LiveCode syntax isn't perfect - it has [] for array access 
for example - it might be nice to be

able to do:

   put index 3 of tNumericArray into tFoo
   put the foo of tAssocArray into tBar

Which is perhaps the way I'd suggest the language should go - 

Re: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-24 12:03, Mark Waddingham via use-livecode wrote:

Perhaps a better model would be to use 'continue', rather than 'break':

switch yourName
  case "Mark"
-- do something and finish
  case "John"
continue
  case "Jon"
-- do something else
end switch

The idea being that 'continue' in a case, jumps to the next choice to
check. This works particularly nicely when you don't have an
expression, so the cases can be expressions as that essentially gives
you a 'match' type construct with back-tracking (quite useful for
processing hierarchical arrays and transforming them - a common
operation in writing compilers, for example).


Okay, so that isn't quite right - for a switch-on-value switch, continue
would have to continue into the top the next case, ignoring the case 
value which is not quite the same as it would be in switch-on-case-expr 
switch.


Certainly a 'fallthrough' type keyword would work... However, stepping 
back and looking at the utility of switch. I'd say that in almost all 
cases you either want to:


  1) Map a single case to a block of code

  2) Map multiple cases to a block of code

The use-case which causes subtle bugs and errors is where one case 
requires a 'bit more code' before the others (where code, fallthrough, 
code is *not* erroneous but intended) - also it is a rarely used pattern 
in C (because it is difficult to maintain).


Taking this into account, then perhaps a better solution would be 
('choose' used here for the sake of argument):


  choose tValue
when 1
when 2
when 3
  -- executes if tValue is 1, 2 or 3
  -- never falls through

when 4
  -- never falls through

default
  end choose

This caters for both cases (1) and (2) and is unambiguous.

As I said before, the lack of switch in LCB isn't because we don't want 
a construct like that; just that we'd like one which doesn't have the 
issues of C-style switch. (The best way to avoid people accidentally 
introducing subtle bugs, is to ensure the language is designed to not 
let them do so!).


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: Writing Extensions

[Mark Waddingham via use-livecode]

Hi Kay

On 2017-05-24 10:19, Kay C Lan via use-livecode wrote:

In that last one the only inference I could find was that due to the
probability that in 97% of use 'fall through' is not intended, a whole
heap of typing could be saved if no keyword (break) was required for
the 97%, and a keyword was only used to activate fall through. i.e.

switch yourName
case "Mark"
  -- do something
break
case "John"
case "Jon"
  -- do somethingElse
break
case "Ali"
  -- do anotherThing
break
end switch

would become

switch yourName
case "Mark"
  -- do something
case "John"
   fall --or some other keyword
case "Jon"
  -- do somethingElse
case "Ali"
  -- do anotherThing
end switch


11 less character to write. Is this the only problem with the current
implementation of Switch?


Okay so I was perhaps a little vociferous in what I said... However, 
fallthrough is
the key problem - there have been numerous subtle bugs in the engine due 
to it

(similarly, switch statements without 'default' can cause subtle
bugs too - if you add a value to an enum, but don't update all the 
switches which

switch on it).

Perhaps a better model would be to use 'continue', rather than 'break':

switch yourName
  case "Mark"
-- do something and finish
  case "John"
continue
  case "Jon"
-- do something else
end switch

The idea being that 'continue' in a case, jumps to the next choice to 
check. This works particularly nicely when you don't have an expression, 
so the cases can be expressions as that essentially gives you a 'match' 
type construct with back-tracking (quite useful for processing 
hierarchical arrays and transforming them - a common operation in 
writing compilers, for example).


However, it would probably be better to change the switch syntax to use 
different keywords (perhaps choice?). The 'switch'/'case'/'break' 
paradigm is so ubiquitous (due to C) that making it work differently 
would be very jarring.


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: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-23 17:53, Mark Wieder via use-livecode wrote:

I'm not doing this because it's fun. I'm stuck with parsing xml data,
and it's much uglier trying to treat it as a text stream, especially
with a subset of the xtalk chunking functions, than by using the
revXML functions in LCS.


Yes - so LCB could do with a module which wraps libxml...


It might be useful to have a list of what xtalk features are available
in LCB, and possibly even more useful to have a list of the features
that *aren't* available in LCB. For instance, the lack of a switch
statement is both surprising and disappointing. What decisions were
made as to what language features to support / remove?


That is the wrong way to look at things I think - it was never a 
question

of 'what should we remove or add compared to LCS'.

LCB is a language in its own right - indeed, you can write entire 
applications
in LCB (and run them using the 'lc-run' tool)... Our 'vulcanbot' (the 
system
which integrates our buildbot-based build system with github) is written 
entirely

in LCB for example.

The design of LCB has been influenced by a number of design principals 
(in no

particular order, nor exhaustive):

  a) it should have fully customizable syntax (at least 'statically' -
 i.e. at the point the compiler is built)

  b) the syntax should be familiar to LCS

  c) operations should be strict (throw an error for indexing out of
 array bounds, for example, rather than throw an error)

  d) strong dynamic typing, with the aim that if fully typed, then an
 LCB module should be completely statically checkable

  e) enable interoperation with other languages to be defined *safely*

  f) allow modularity without co-operation

  g) it should run on a VM which could be shared with LCS

  h) it should have a type-system which could subsume LCS's type-system

  i) be a natural extension language for LCS (i.e. replace C++ as the
 main implementation language for LCS features)

  j) favour abstract patterns, rather than concrete features (as one
 can implement many concrete features from one abstract pattern)

  k) it should be possible to compile a full typed LCB program to 
'native'

 code (for some definition of native) with performance commensurate
 to that you would get if you wrote in said 'native' tongue

LCB is as much about trying to find the line between what we consider a
very high level language (LCS) and what we consider to be a low level
language (such as C) - blending the two together. It is influenced by 
many
languages (principally LCS, admittedly) but perhaps is not quite like 
any

specific one.

At the end of the day I could go on at length here (what do you know,
language design and implementation is probably my biggest computing
interest ;) ); however, I'll leave it as an 'interesting exercise for 
the

reader' to consider what becomes possible if we can (at the very least)
achieve to the full extent possible principals (a), (g), (h) and (k)...

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: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-23 18:02, Mark Wieder via use-livecode wrote:

I'm rather disappointed that there's no way to search the guides. For
instance, to find out why the switch statement wasn't working in LCB,
I opened the LCB guide and found that the only way to discover this
was to read through the entire text. A simple control-F "switch" would
have either pinpointed the section or given no results.


Or you could try reading the LiveCode Builder Language Reference Guide -
which gives a full account of all the definition and control structure
syntax (modulo the occasional error - one which you pointed out the
other day - bug reports for which would be most appreciated) ;)

In regards to 'switch' - 'switch' in LiveCode copied the C 'switch' 
which

is pretty much universally considered to be one of the worst designs of
such a thing and we didn't want to repeat that 'mistake'.

There are various other designs out there in various different 
languages;

for now though 'if then/else if then/else if then/else/end if' isn't too
bad a substitute if your condition var is just a var (and not an 
expression).


Warmest Regards,

Mark.

P.S. I don't believe Python has 'switch' either, so it isn't 'only LCB'
which doesn't - however, we do intend to add such a structure when we 
have

time to design one without the flaws of the C model.

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

[Mark Waddingham via use-livecode]

On 2017-05-23 17:27, Mike Bonner via use-livecode wrote:

trying this again since it seems the list is back up...

I have an old g4 mac laptop running tiger.  I was wondering if anyone 
had a

copy of rev media out there (the one you could install and use but not
build standalones) that they could share with me, so i can mess around 
on

it?  Assuming this is ok with the mothership of course.


You could try LiveCode Community 6.x - we still supported PPC Mac's at
that point IIRC (Tiger+).

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: Best Practice for updating the screen?

[Mark Waddingham via use-livecode]

On 2017-05-23 17:05, Paul Dupuis via use-livecode wrote:
Has LiveCode ever considered a "redraw screen" command or something 
like

that which lets the system have some free CPU cycles but without other
UI events getting processed?

Is there an enhancement request for such a feature in the LiveCode
bugzilla database?

Does anyone else run into this issue in their work?

What is the "best practice" for this issue?


What Richard said is correct - at some point we reworked things so that:

After every LiveCode Script command which executes and adds an update 
region

to a stack, the updates are flushed to the screen.

If a command is executed inside 'lock / unlock screen', all accumulated
updates are flushed on unlock screen (assuming unlocking the screen at 
that

point reduces the lock count to zero).

The screen is implicitly unlocked when all running handlers finish (i.e.
control returns to the root event loop).

I've just done a quick check in 6.7.11 and doing:

  repeat forever
set the hilite of button 1 to false
set the hilite of button 1 to true
  end repeat

Does what is expected - the screen updates after each 'set'. Wrapping
one or other in 'lock/unlock' screen causes the same effect.

So I'm surprised you need the 'wait for messages' even in 6.7.11 - can
you post some more context to what you are doing?

In any case, you might find wait without messages is sufficient to solve
your problem - this still causes the event loop to run, but everything 
is

just queued rather than processed. In particular, using this you won't
get any events percolating through script.

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: news about the new Google Play policy

[Mark Waddingham via use-livecode]

On 2017-05-22 14:09, Colin Holgate via use-livecode wrote:
I did get follow up messages from the Google policy guy. Here’s what he 
said:


" I will indeed talk to the team behind developing the policies update
around dynamic code loading and surface the livecode environment. I do
not believe that the intent here is to prevent their model, but we
will absolutely explore whats going on with that framework to figure
out a path forward."


Great - I'm more than happy to discuss this with them as pertains to
LiveCode.

If LCB FFI is not used, then everything is fine. If it is used, then
it does open the door to being able to download non-native executable
(LCB VM) code to be downloaded and extend the API access of an app.

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: which Externals does a standalone load?

[Mark Waddingham via use-livecode]

On 2017-05-22 11:13, Tiemo Hollmann TB via use-livecode wrote:

Hello,

LC 8.1.4 I have a program out in the market, and I am unsure, if it 
runs

with or without tsNet.


Standalones only load the externals which are explicitly included (i.e.
those chosen explicitly, or those chosen by the 'search for inclusions' 
step).


You can check to see what a built application (on Mac) is loading by:

  1) Running the app

  2) Go to Activity Monitor

  3) Find the process of the standalone you've just run

  4) Click the 'info' button to get info about the process

  5) Look at the Open Files and Ports tab

  6) See what files under Externals are loaded.

For example, the 8.1.1 Business IDE has these:

/Applications/LiveCode Business 
8.1.1.app/Contents/Tools/Externals/revandroid.bundle/Contents/MacOS/revandroid
/Applications/LiveCode Business 
8.1.1.app/Contents/Tools/Externals/revdb.bundle/Contents/MacOS/revdb
/Applications/LiveCode Business 
8.1.1.app/Contents/Tools/Externals/revfont.bundle/Contents/MacOS/revfont
/Applications/LiveCode Business 
8.1.1.app/Contents/Tools/Externals/revbrowser.bundle/Contents/MacOS/revbrowser
/Applications/LiveCode Business 
8.1.1.app/Contents/Tools/Externals/reviphone.bundle/Contents/MacOS/reviphone
/Applications/LiveCode Business 
8.1.1.app/Contents/Tools/Externals/revspeech.bundle/Contents/MacOS/revspeech
/Applications/LiveCode Business 
8.1.1.app/Contents/Tools/Externals/revvideograbber.bundle/Contents/MacOS/revvideograbber
/Applications/LiveCode Business 
8.1.1.app/Contents/Tools/Ext/blur-1.1.17/blur.bundle/Contents/MacOS/blur
/Applications/LiveCode Business 
8.1.1.app/Contents/Tools/Ext/mergJSON-1.0.33/mergJSON.bundle/Contents/MacOS/mergJSON
/Applications/LiveCode Business 
8.1.1.app/Contents/Tools/Externals/revxml.bundle/Contents/MacOS/revxml
/Applications/LiveCode Business 
8.1.1.app/Contents/Tools/Externals/revzip.bundle/Contents/MacOS/revzip
/Applications/LiveCode Business 
8.1.1.app/Contents/Tools/Ext/mergAV-4.0.19/mergAV.bundle/Contents/MacOS/mergAV
/Applications/LiveCode Business 
8.1.1.app/Contents/Tools/Ext/mergAWS-1.2.29/mergAWS.bundle/Contents/MacOS/mergAWS
/Applications/LiveCode Business 
8.1.1.app/Contents/Tools/Ext/mergBLE-1.1.11/mergBLE.bundle/Contents/MacOS/mergBLE
/Applications/LiveCode Business 
8.1.1.app/Contents/Tools/Ext/mergBonjour-1.0.30/mergBonjour.bundle/Contents/MacOS/mergBonjour
/Applications/LiveCode Business 
8.1.1.app/Contents/Tools/Ext/mergCL-2.0.26/mergCL.bundle/Contents/MacOS/mergCL
/Applications/LiveCode Business 
8.1.1.app/Contents/Tools/Ext/mergGoogle-1.0.17/mergGoogle.bundle/Contents/MacOS/mergGoogle
/Applications/LiveCode Business 
8.1.1.app/Contents/Tools/Ext/mergGoogle-1.0.17/mergGoogle.bundle/Contents/Frameworks/GData.framework/Versions/A/GData
/Applications/LiveCode Business 
8.1.1.app/Contents/Tools/Ext/mergMarkdown-1.0.30/mergMarkdown.bundle/Contents/MacOS/mergMarkdown
/Applications/LiveCode Business 
8.1.1.app/Contents/Tools/Ext/mergMicrophone-1.0.30/mergMicrophone.bundle/Contents/MacOS/mergMicrophone
/Applications/LiveCode Business 
8.1.1.app/Contents/Tools/Ext/mergNotify-2.0.27/mergNotify.bundle/Contents/MacOS/mergNotify
/Applications/LiveCode Business 
8.1.1.app/Contents/Tools/Ext/tsNet_Business_1.2.3/tsNet.bundle/Contents/MacOS/tsNet
/Applications/LiveCode Business 
8.1.1.app/Contents/Tools/Ext/XPDF-1.0.8/XPDF.bundle/Contents/MacOS/XPDF


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: AW: how are URL / libUrl / tsNet related?

[Mark Waddingham via use-livecode]

On 2017-05-22 10:34, Tiemo Hollmann TB via use-livecode wrote:

Hi Mark,
thank you for your comprehensive explanations.

So when building a standalone, I can choose using tsNet or not, but I 
can't
choose in the IDE. What happens in the IDE when using the keyword URL. 
Does
it always go via tsNet (as far I don't unlink tsNet)? If yes and I 
don't
choose the tsNet inclusion in the standalone builder, the standalone 
would

work differently to the IDE. Right?


You can explicitly load / unload tsNet in the IDE via the message box:

To unload:

   dispatch "revUnloadLibrary" to stack "tsNetLibUrl"

To load again:

   dispatch "revLoadLibrary" to stack "tsNetLibUrl"

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: how are URL / libUrl / tsNet related?

[Mark Waddingham via use-livecode]

Hi Tiemo,

On 2017-05-22 09:47, Tiemo Hollmann TB via use-livecode wrote:

Hello,

I feel, that I am missing some basics about URL / libUrl / tsNet.

I thought, when using the keyword "URL" like in "put URL foo into res" 
it
has used under the hood in the past functions from libUrl. And I 
thought

since LC 8 or so libURL was replaced by tsNet, so when using today the
keyword URL it uses under the hood tsNet.


There are two types of URL related functionality in the engine:

  - those provided by syntax (e.g. load url, url, post etc.)

  - those provided by libUrl prefixed functions and commands.

The syntax works because the engine sends a message (such as loadUrl) 
through
the message path to handle any occurrences of 'load url X'. The other 
functions

and commands because libUrl is just a library stack/backscript.

The tsNet external provides a richer set of functionality via a 
collection of
tsNet functions and commands - the tsNet functionality is a superset of 
that

provided by libUrl.

When we started bundling tsNet, Charles modified the built-in libUrl so 
that
it consists of a universal library script, and a 'driver' script - the 
library

script provides the public API (both for functions and syntax) and then
dispatches to a (private) driver library which actually does the work.

tsNet comes with a libUrl driver which implements the whole of libUrl's
functionality via tsNet.

If you just choose to include libUrl, then you will get the libUrl 
implementation
(which runs using engine socket commands); if you also include tsNet, 
though,
it will install its driver on startup; so libUrl will then be doing all 
its work

vai tsNet.

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: which port is beeing used with get URL?

[Mark Waddingham via use-livecode]

On 2017-05-19 10:40, Tiemo Hollmann TB via use-livecode wrote:
Am I right, that using "put URL" is a standard http:// protocol via 
port

8080? Or is there a special port being used by LC?


HTTP is port 80 - HTTPS is port 443.

LC does not do anything non-standard here (unless you specify, e.g. 
http://livecode.com:93).


Are there any ideas from your experience, what and how to check for to 
find

the blocking factor in a customer network?


Right, so - we know there are problems with LiveCode's networking stack 
communicating in some network environments. However, the problem is that 
we're not sure what configurations are actually causing the problem.


Trevor DeVore has done a lot of work over the years to help improve the 
internet settings auto-discovery, to make LiveCode much better in this 
regard; however, things still aren't perfect.


If we can find a way to fetch all the info about places which are not 
letting libURL work, then we can look into making it work... The problem 
is working out how to collect that information.


If anyone has any ideas on this score then that would be most helpful!

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: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-18 22:08, Mark Wieder via use-livecode wrote:

On 05/18/2017 10:57 AM, Mark Waddingham via use-livecode wrote:

The point is the whole problem can be sufficiently solved quite well
with better tooling (which we are aware we need to work on); and in 
the

future can be solved completely using a little bit of cleverness and
exploiting the way LCB has been implemented.


Cool. That sounds promising.


Indeed, thinking a little more laterally about the problem of binary
module compatibility then there are actually two sides here:

1) The community edition side

2) The commercial edition side.

In the case of (1), the engine is GPL. This means that any extensions 
used in community, must be GPL too (or dual-licensed, if it is to be 
allowed to be used in Commercial). GPL apps need to give access to the 
source (widgets built with community already include the source). This 
means that compilation can happen on installation of the widget; there's 
actually no need for compilation to occur before this point (beyond 
checking that everything is present in the extension which is needed to 
compile it). So this would solve the problem in Community.


In the case of (2), then we definitely need to do something before 
commercial widgets become common-place - I agree :)


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: news about the new Google Play policy

[Mark Waddingham via use-livecode]

On 2017-05-19 04:39, Colin Holgate via use-livecode wrote:

Let me know what you think.


All I'd really like is a more well-defined policy - that's all that's
needed here I think. After all, if one is going to use terms in a policy
then it seems wise that those terms be explicitly defined.

What Google is trying to do is 100% clear - it is also very easy to 
state

in a completely unambiguous way. e.g.

"Apps submitted to the Google Play Store must not download any files
which allow the app to access more Android APIs which it could at the
point it was submitted to the Google Play Store."

This covers all possible cases as far as I can see - and covers cases
which their current policy does not (as worded, at least).

If you can get an email of someone to whom I can 'whinge' at, then I'll
do some suitable 'whinging' ;)

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: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-19 06:23, Mark Wieder via use-livecode wrote:

On 05/18/2017 07:14 PM, Alejandro Tejada via use-livecode wrote:
Now that we are talking about widgets and extensions, many thanks 
again

Mark Wieder for updating Peter Thirkell multicolor svg widget.

Just for curiosity, Could you write a blog entry about your process of
updating this widget? Maybe others would find this useful to update 
their

own widgets.


I'll think about it, but I'm probably the wrong person to write up the
process of creating/modifying widgets at this point. But I'd love to
see Peter write up the process he went through. All I did was add some
flexibility to the xml parsing (which in LCB ends up working with char
offsets and is ridiculously ugly, fragile, and error-prone) and
allowing hex representations of color specifications.


If we are honest then parsing XML even with LCS's excellent text 
chunking isn't
necessarily *that* much 'prettier'. XML is quite a complicated format if 
you

want a 100% compliant reader (do we have a 100% compliant XML parser
written in LiveCode?) - hence why, in this case, it would probably be 
better

to have a wrapper around a well established XML library in LCB.

Why reinvent a wheel which many other people have already decided needs 
reinventing...


(Although, having said that, there is something quite pleasing about 
this

kind of thing being written in the host language - pragmatically though,
we're probably better off with readers which are maintained by people
who live and breath these import formats - at least when you need the 
most

generality).


I had to move it out of my Extensions folder after testing it since
having both the LC8 and LC9 versions in places messes things up. This
changing binary format thing is a pain.


Point taken - it is a pain! However, it won't be like this forever - and
obviously the sooner it is stable, the better it is for the ecosystem.

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: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-18 22:08, Mark Wieder via use-livecode wrote:

On 05/18/2017 10:57 AM, Mark Waddingham via use-livecode wrote:
Yes, but that's comparing two different things. I'm concerned about
the differing binary formats, not the source compatibility. I'm stuck
if I want to distribute an easy-to-use extension (widget or library)
for others to use. My alternative is to distribute the source and say
"here you go... compile and install it yourself. And remember to do
that again when the next major version of LC comes out or it won't
work any more."


I was more just trying to explain the current situation, for both
source and binary compatibility.


I *don't* think we're doing badly in the realm of source-code
compatibility. I never intended to imply that. Sorry if I gave that
impression.


I was talking about the LCB ecosystem generally in comparison to
Rust / Swift / number of engineers they have working on those projects /
time it took them to get them to a release worthy state :)


To be fair about your comparisons, Rust only reached 1.0.0 stage two
years ago. My statement there was more about that fact that given all
the hoopla that accompanied the announcement of LCB, extensions, and
the Way Forward, the state of the resources and environment for
extension development seems pretty fragile at this point.


Indeed - we did - why wouldn't we? People wouldn't even have looked at
them if they didn't and if this stuff is never used it will never
reach any sort of maturity (the reality is that programming languages 
evolve

through direct use, rather than by design-in-totality-then-implement).

Just like many other open-source projects - most of which start off 
being

'fragile' in the way you suggest.

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: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-19 03:08, Mark Wieder via use-livecode wrote:

On 05/18/2017 12:59 AM, Mark Waddingham via use-livecode wrote:

backported to LCS. I appreciate the team's reticence to make syntax
changes to the core xtalk language, but even as a long-time C
programmer,





I wouldn't say we have a 'reticence' to make syntax changes but it 
requires

a great deal more care than in LCB for several reasons:


Heh. OK - wrong choice of word then. I'd say rather that I appreciate
the team's conservative approach to making syntax changes (although
"this me" still seems wrong to me. Or at least to this me, with a nod
to PKD).


Referring to yourself as "this me"... Does that mean you are just a link 
in a longer behavior chain then, 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: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-18 18:18, Mark Wieder via use-livecode wrote:

That's unfortunate. It means that, aside from distributing the widget
source code, compiled widgets are bound to a specific LC version with
no guarantee that they will work with any other past or future
version. Does 'major version' here mean 9.x or 9.0.x? Can I assume
that the binary format will stay the same across all LC9.x releases?


I'm not sure it as much of a problem as it first appears to be - because 
much the same is true of LiveCode Script.


If you write a script in 9 which uses features of 9, it will not work in 
any version less than 9.


If you write a script in 8 then yes, we work very hard to ensure that 
scripts will work exactly the same in 9.


So LiveCode Script is source forward-compatible (because we work had to 
make it so); but not source backward-compatible.


Now, much the same is true of LiveCode Builder in terms of 
source-compatibility (any source-compatibility issues should be reported 
so we can look into it). However, currently, LiveCode Builder compiles 
to a bytecode format which we do not guarantee inter-major version 
compatibility of currently (whether 'major version' here is the first 
version point, or first two version points is immaterial - we do 
guarantee binary compatibility between maintenance releases).


However, 8.1.x module format is fixed and will not change, as is 
lc-compile and the lcb standard library. This means that those specific 
builds of tools will now and forever produce modules which load into 
8.1.x - so we have a LCB8.1 toolchain.


Similarly, when 9 goes GM, the module format, lcb standard library and 
lc-compile will forever produce modules which load into 9.0.x - so we 
have an LCB9.0 toolchain.


If there comes a point where we do perhaps need to break 
source-compatibility, we will make lc-compile more clever - making sure 
it can be passed a 'source version' argument. Or we will reconsider the 
module format slightly, raising its abstraction level slightly so this 
isn't an issue, write a suitable converter and happily move on.


The point is the whole problem can be sufficiently solved quite well 
with better tooling (which we are aware we need to work on); and in the 
future can be solved completely using a little bit of cleverness and 
exploiting the way LCB has been implemented.



I have to say I'm surprised that we're still at this state of things
so far after the fanfare introduction of extensions.


It is important to remember that LCB has only been in development (on 
and off) for about 2 1/2 years at this point. Rust has taken over 7 to 
get to source-compatibiliy stage (IIRC), and Swift broke source 
compatibility at least twice I think since its launch - so I don't think 
we are doing too badly (particularly when you compare the size of 
Mozilla, Apple and us... I'll leave you guys to do the math there).


And on a slightly tongue-in-cheek note: I'm surprised after 26 years, 
the linux world has not solved its binary compatibility problem. Indeed, 
they don't seem to care about it one bit - even though it causes huge 
amounts of wasted effort for any organisation daring to consider 
distributing *binary only* applications. God forbid! (Also, the further 
you move away from glibc in the Linux stack, the worse things get in 
terms of source compatibility too...) ;)


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: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-18 18:07, Mark Wieder via use-livecode wrote:

Didn't find it in the dictionary, but I do see that now in the
language reference. How would one define a quote constant?
constant quote is "\q"  ?


Yes.


The language guide explicitly states "Note: Constants are not
currently implemented, although the syntax is recognised." What am I
supposed to make of that?


That's a bug in the language reference - it should say that only literal 
values are supported at present, general (constant) expressions are not.



That's unfortunate. In LCS I often change the itemdelimiter in order a
to parse complex strings. The lack of the ability to manipulate things
at this level is a serious detriment to text parsing, which is one of
the main strengths of LCS.


Indeed - it is a *great* strength of LCS and is very important in the 
domain of things which are written in LCS. The development of LCB has 
mainly focused on things which LCS cannot do - like calling foreign 
functions and being able to render complex visual representations of 
data with a much lower overhead than is necessary in LCS.



Ah. So the dictionary isn't a good place to look for things. I'll
spend some time working my way through the language reference instead.


Heh - as Ali said, the docs and such need a fair bit of work :)

Similarly, word and token are 'tokenized chunks' - they action could 
be

described by a regular expression.


See above (itemdelimiter).


See above (strengths of LCS vs LCB) :)

Now, I'm not saying that LCB shouldn't have better ways to manipulate 
text - closing the gap between LCS and LCB is an important goal; 
however, it seems wiser to get the things working in LCB which LCS 
cannot do first, before replicating functionality LCS already does 
really well.


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: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-18 15:53, hh via use-livecode wrote:

LCB bug reports by me only:

18899 CONFIRMED 2016-11-29, LCB: load image from resource file defunct
in 9.0.0-dp2
18669 CONFIRMED 2016-10-24, LCB: display problem in Linux when
rotating the canvas
18628 CONFIRMED 2016-11-03, LCB: Random 'jumping' of path elements
(polygon path)
18562 CONFIRMED 2016-11-03, LCB: The local date offset is wrong in Win
and linux
18258 CONFIRMED 2016-08-30, LCB-Canvas: access to logical and drawing
bounding rects

ID 18899 reports the 'remaining' part named in the forum-link above.

This is a justification not a reproach. I appreciate the team's work
connected to bugs
(especially Panos as 'gatekeeper') very much.


Heh - hoisted by my own petard there - I should have searched bugzilla 
first :)


Thanks for the list, though :)

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: Android policy update

[Mark Waddingham via use-livecode]

On 2017-05-18 15:00, Colin Holgate via use-livecode wrote:

The things that you’re talking about, involving an app updating
itself, does that currently get past Apple review? That would be an
argument to use with Google, in that Apple have usually been tougher
about this.

Also, does Google’s policy suggest that you can’t even update an image
in the app?


I think the web-page which Jacque linked to is much too vague - it
doesn't define any of the terms it uses, and contradicts itself as 
mentioned

in my previous post.

One thing to find out is what the actual text of the agreement you have
to click through to sign says - I'd imagine that's where the *actual* 
T

are.

As written, a conservative interpretation of that text would suggest no, 
you
cannot update an existing image in an app - as that is technically 
modifying yourself.


Similarly, it says that you can't 'modify, replace or update' other than 
via
the Google Play Store - isn't downloding content modifying the app 
technically

speaking?

Of course, I'm splitting hairs here slightly - the intent of the policy 
is

crystal clear here, they are trying to ensure that apps cannot leverage
vulnerabilities which were not known at the time the app was submitted 
to the

app store.

However, the text on that page is too ill-defined to be *any*
sort of binding agreement - so I hope there's a stricter version.

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: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-17 01:02, hh via use-livecode wrote:

Alejandro T. wrote:
How fast is LCB working with imagedata?

Would be great, if not too difficult to realise, to have
a "do as javascript" here (which uses the js engine only
of the browser widget). This is at least ten times faster
with imagedata than fastest LC Script. See several recent
examples in "Sample stacks" (and some more links in the
Raspi-Subforum to extern servers).


You could access 'do as javascript' in a browser widget
from LCB - just use the 'execute script' command (although
there are places where you cannot use that form - in OnCreate,
OnDestroy, OnLoad, OnSave, OnPaint - just because they are
critical handlers in which you don't things to get shaken
up too much).


Alejandro T. wrote:
How fast is LCB working with transform matrices?


Pretty fast and comfortable for transforming all 'small'
canvas data (pathes, text, pattern, image-as-a-whole).
I liked that after taking the first hurdles.

You may test yourself with snippets or lcb files from the
LCB-subforum. There is a lot of stuff for starting there.
Or use the examples on github by Trevor DeVore or the ones
by the LC-stuff, variants by BerndN.


The canvas library basically wraps our C wrapper (libgraphics)
around Skia, so LCB is only being used as the 'glue' there.

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: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-18 13:29, hh via use-livecode wrote:

No, not only the binary-level compatibility is the problem. LC Builder
is not downward compatible (without documenting that), already running
parts are removed.

See for example (in forum/bug-triage):
http://forums.livecode.com/viewtopic.php?p=148665#p148665


I have to remind people - please file bug reports! If you don't then the
chances of these things getting addressed, explained, or advice given
reduces greatly.

The issue there I'm pretty sure is purely one of non-binary 
compatibility.
The module files generated by the lc-compile tool in any major version 
is likely to only

produce files what work in that major version.

(It does sound like a bug has crept in there, potentially, in resource
resolution though - hence my comment about filing bug reports).

So the problem actually reduces to - having a widget which does not use
anything new in LCB V+1, but you want to use in V and V+1. This is 
solved simply
by compiling the widget file with the lc-compile from V and the 
lc-compile from

V+1.

If your widget uses new LCB features which are only in V+1, then 
backwards
compatibility isn't going to work - like it wouldn't in a stack which 
was written

to use features in 9, which aren't in 8.

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: LC core team

[Mark Waddingham via use-livecode]

On 2017-05-18 12:48, hh via use-livecode wrote:

There is rumour about personal changes in the LC core-team.
Could we please get some reliable info about that?


Well, not 'personal' (in the usual sense of the word) per-se, but
our team has changed slightly recently. I'll post some more information
about this in due course.


What are the consequences of that change for the HTML5 deployment?
There was no progress with that for half a year. Is it now 'stopped'?


No - it never stopped. Admittedly the last *feature* to be added to the
HTML5 engine was 'do as javascript' (which is actually a feature which
enables anyone who knows javascript to get the HTML5 engine to do a 
whole

lot), but remember that the HTML5 engine is just another platform like
any other, so work on the platform as a whole benefits HTML5 too.

That being said, recently we are a hair's breadth away from getting
widgets working in HTML5 (hopefully running a little quicker than they
did before too):

https://github.com/livecode/livecode/pull/5428

(Yes, the name of the PR sounds unrelated to HTML5, but the purpose of
doing what it said was to get widgets working *in* HTML5 - but it has
a couple of other fringe benefits as well - a slight performance bump
for LCB execution in general)

We've also been looking at how to abstract the FFI work we've done as
part of the Infinite LiveCode campaign to allow LCB to bind to 
JavaScript

APIs (which will allow greater type fidelity than is possible using
'do as javascript' from LCS).

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: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-17 23:43, Mark Wieder via use-livecode wrote:

Yes. In fact it's the areas where they differ that make for a
difficult learning curve. There are features in LCB that I wish were
backported to LCS. I appreciate the team's reticence to make syntax
changes to the core xtalk language, but even as a long-time C
programmer,

put tHexNumber converted from base 16 into tDecimalNumber

seems so much more readable than

put format("%02x", tHexNumber) into tDecimalNumber


I wouldn't say we have a 'reticence' to make syntax changes but it 
requires

a great deal more care than in LCB for several reasons:

   - The current implementation of LCS has no notion of versioning for 
its
 syntax or semantics - so every change to syntax / addition has to 
be done

 in a way which will not break user scripts.

   - All the syntax in the engine is done using hand-coded parsing - it 
is very
 easy to introduce unintended ambiguities and syntactic forms which 
we did

 not intend.

   - It is quite labour intensive to add / change syntax which means 
experimenting
 with it (which you need to do to get it 'just right') is hugely 
costly.


In contrast, all of LCB's syntax (beyond the core control structures and 
definiton
structures) is defined in LCB itself, and binds direct to handlers which 
implement
that syntax (in contrast, in LCS, you have to write C++ code both to 
parse a piece
of syntax, and to dispatch it to the implementation). For example, the 
syntax you

mention above is defined like this:

syntax BaseConvert is left binary operator with conversion precedence
 "converted" "from" "base"  
"to" "base" 

begin
MCMathEvalConvertBase(Operand, Source, Target, output)
end syntax

With 'MCMathEvalConvertBase' being a (foreign) handler implemented in 
C++ which performs

the action of the syntax.

The main limitation with LCB's syntax right now is that it has to be 
compiled into
a parser spec ahead of time - i.e. at creation of the lc-compile tool - 
but even with
that restriction, 'playing' with syntax is possible by just a tweak to a 
code file and a click of
a button (albeit in a native code IDE), rather than spending many hours 
hand modifying

some rather old (and in some places very complex) C++ code.

Of course, one valid retort here would be - then why don't you just make 
it easier to
do this by changing how the engine works in this regard? And the simple 
answer is that
we are - in order to do that we need an architecture and method of doing 
so, and LCB is

that architecture.

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: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-17 21:27, Mark Wieder via use-livecode wrote:

Well, I'd love to have more parity between LCS and LCB as far as
keywords and syntax, but I guess that's outside the scope of the
documentation per se. But finding that constants like comma and quote
aren't defined in LCB was a shock. Indeed, even defining a constant
doesn't seem possible. Or at least it's not documented. Searching for
"constant" gives nothing, even though "PiConstant" is in the
dictionary.


You can define constants using:

   constant X is Y

Currently Y has to be a literal - not an expression (just like LCS).


Is it even possible to set the various delimiters? The documentation
only talks about retrieving them. The description talks about the
calling (script) handler's Delimiter property... is this an
actual property of the object or is just a shorthand way of talking
about "the Delimiter"?


No - the context local properties are a LiveCode Script feature, they
don't exist in LCB.

The 'the Delimiter' syntax gives you access to the values of those
properties in the most recent LCS stack frame allowing LCB to do similar
things as the engine can in its commands and functions.


The pointer type isn't documented.


Well it is listed in the language reference ;)


Why is the "point" operator documented as "PointMake"? Is this just to
differentiate between the "point" creator keyword and the "point"
object keyword?


Each piece of syntax in LCB has a unique name (it is a definition, like
a handler or a variable) - those title-case names you see are the names
of the syntax definitions.

The point operator is a constructor for the (Canvas.)Point type.


Some major strengths of LCS are missing in LCB, or at least don't
appear to be in the documentation. Chunks, for instance. It's possible
to get character chunks (and the [first|last] modifier in the offset
functions are *very* nice), but there's no conception of words. This
results in some ugly, convoluted, and error-prone coding to deal with
things that are not only easy in LCS, but IMNSHO one of the things
that makes LiveCode such a productive environment. I'm hoping this is
just a documentation failure and not a missing feature.


LCB's syntax is quite minimal at the moment, it isn't meant to be a
replacement for LCS (as mentioned before) - it is intended as a language
which makes explicit the implicit patterns and abstractions which exist
(albeit hand-coded in most cases) in the engine, so that they can be 
used

to build the abstractions which we use everyday in LCS - and extend them
in a natural way.

For example, line and item chunks are actually an incarnation of what
you might call a 'delimited chunk' - they have identical semantics, 
apart

from where the delimiter to use is fetched from (the *delimiter property
in local context).

Similarly, word and token are 'tokenized chunks' - they action could be
described by a regular expression.


The StringToJString and StringFromJString examples handler use the
"foreign handler" construct, but "foreign" isn't in the dictionary.
Nor is the "binds to" syntax. Nor the JObject or JString objects. Nor
the "unsafe" keyword.


The dictionary doesn't currently contain anything which is 'part of the
core language syntax' - more details about that can be found in the
Guides section of the dictionary - there are a few guides related to LCB
at the bottom.

So, as Ali said, we have a fair bit of work to do on the documentation, 
but

then that's also true of the language itself.

LCB is definitely a work-in-progress but one which is actually quite
usable now for a wide variety of things... Once you've got your head 
around

how to use it!

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: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-17 01:02, hh via use-livecode wrote:

But I wait for my next examples until there is a stable
widget format (we have meanwhile three formats that work on
some LC versions only, not on the others).


Unfortunately we aren't going to be guaranteeing binary-level 
compatibility of the LCB module format for quite some time - it will 
likely change in every major version for quite a while yet.



To adjust these costs too much time, simply recompiling
worked here only in 1 of 20 cases.


Can you elaborate by 'recompiling only worked here in 1 of 20 cases'?

There's probably something we can do here. Currently widget source code 
is included in the extension when built using the extension builder 
(this will always be true of the community edition, and when we have our 
'extensions store/sharing portal', it will be one way we can ensure 
people aren't doing anything nefarious (any widget which is to be 
accessible from community will require the source is in the extension, 
and also that the compiled module in the extension matches the included 
source).


So, we could actually tweak things so that we generate the module file 
at extension installation time.


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: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-17 23:30, JB via use-livecode wrote:

It looks to me like a the easier stepping
stone to fill the gap is just write the code
in C/C++, compile it and call it using a
shell coimmand.


That works fine for batch processing type scenarios, certainly.

However, it doesn't work if you want to display a visual element in a 
window, or need access to the rich in memory data structure the LiveCode 
engine has (e.g. the object tree, variables containing arrays, or large 
strings etc).


It also won't ever work on iOS...

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: Android policy update

[Mark Waddingham via use-livecode]

On 2017-05-18 00:25, J. Landman Gay via use-livecode wrote:

I just got a developer email about a revision to Google's policies for
apps on Google Play. Google will not allow apps that download
executable code, similar to Apple's policy. It sounds like that
includes stack content downloaded via a "launcher" app.

https://play.google.com/about/privacy-security/malicious-behavior/


I would agree with Richard's analysis - albeit with one caveat discussed 
later on.


Is it just me or is the wording of that page is atrocious? I hope there 
is a more detailed normative document in which these restrictions are 
placed (like the Apple SDK/Store Agreement). After all in the 
(presumably non-normative preamble) it says:


"An app distributed via Google Play may not modify, replace, or update 
itself using any method other than Google Play’s update mechanism. 
Likewise, an app may not download executable code (e.g. dex, JAR, .so 
files) from a source other than Google Play. This restriction does not 
apply to code that runs in a virtual machine and has limited access to 
Android APIs (such as JavaScript in a webview or browser)."


Then in what appears to be the normative section, it says:

"The following are explicitly prohibited:
  - Apps or SDKs that download executable code, such as dex files or 
native code, from a source other than Google Play."


This is somewhat contradictory without an explicit definition of what 
they mean by 'executable code'. However, reading between the lines I 
would infer that what they mean is this:


"It is explicitly prohibited to allow an app to download code from 
outside of Google Play which is able to call more Android APIs than the 
host app was originally able to do."


Anyway, reading between the lines, the reasoning behind this is simple - 
google can check all dex, JAR and .SO files which flow through Google 
Play for malicious code. They cannot check any code which is downloaded 
outside of Google Play - so if code is downloaded outside of Google Play 
then it must not create any more 'routes in' to the OS in order to 
trigger vulnerabilities and the only 'routes in' to the OS are Android 
API calls, whether they be Java or C.


Anyway, I think you are fine as right now the range of APIs which the 
Android engine uses is fixed at the point of building an Android 
standalone and we are definitely a VM (LiveCode Script runs using an 
Abstract Syntax Tree, LiveCode Builder a ByteCode Machine) - thus we can 
be considered 'JavaScript in a WebView'-like.


Okay so the caveat. I really want the above paragraph to be true, 
however it actually isn't if one casts a critical eye over the whole 
system...


We potentially have an issue with LiveCode Builder... Well, not LiveCode 
Builder, but its FFI capabilities.


It's very presence and the way it works means that in actual fact, we 
cannot say that 'code that runs in a virtual machine has limited access 
to Android APIs' - even the existing C FFI mechanism allows you to hook 
up to arbitrary C APIs; the upcoming Java FFI mechanism makes this even 
easier (as connecting to Java APIs is a fair bit easily than C - from 
the point of view of the developer, at least).


Indeed, LCB modules are loadable at runtime, so you could download an 
LCB module which hooks into APIs the existing app does not; and then 
call them. Further than that, it is possible to write an LCB module 
which allows arbitrary machine code to be executed directly.


This will require some thought - I'd rather LiveCode didn't get 
blacklisted from being considered a 'JavaScript running in a 
WebView'-like language.


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: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-17 21:34, Richmond Mathewson via use-livecode wrote:

Why do I feel that the reason for all this "wierdness" is because LCB
has been written from C++ programmers from the ground up,
while LiveCode still (well, just about) hangs onto to its HyperCard 
heritage.


LiveCode, at its best, preserves the clarity that was the best thing
about HyperCard (certainly mind-blowingly refreshing
after my baptism with FORTRAN and PASCAL); LCB, not doing that, is as
opaque as its heritage.

It has been suggested before that the LiveCode team have, maybe
unwittingly, started moving away from the
HyperCard-like simplicity that was what made LiveCode so obviously the
best successor to HyperCard; with LCB they
don't even have to pay lip service to that . . .


I think this perhaps displays a misunderstanding what LCB is for - it 
isn't a replacement for LiveCode Script; it is intended to be a stepping 
stone between C++ and LiveCode Script which means it can be used to 
extend the engine in way which LiveCode Script cannot. i.e. Allowing 
functionality to be added to LiveCode *without* having to deal with C++ 
and, instead, deal with something slightly more familiar (also there is 
a lot of boiler-plate required in writing engine functionality in C++, 
which LCB eliminates by raising the abstraction level of values).


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: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-17 18:05, Mark Wieder via use-livecode wrote:

Ha! Yes, It sounds like that should take care of that issue. I kept
thinking the pointer was showing me where the error occurred (the line
number was correct), but I kept changing the parameter it was pointing
to and still got the same syntax error. I finally narrowed down what
was going on with that line, and it had nothing to do with what was
being pointed out to me. I'll file a bug report on this.

However, "Syntax error" as the sole error message doesn't really help
much in telling me what I might have done wrong, especially given the
lack of a messagebox or irb style playground to experiment with
things.


Yes - the syntax error message is about as good as we can make it at
the moment by virtue of the fact we use bison (in GLR mode) to generate
the parser (the spec of which is generated from the syntax 
specifications

in the LCB source files which are compiled in lc-compile) :(

LCB is more of a 'traditional' language - so compilation is completely
divorced from execution - hence no REPL loop.

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: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-17 09:09, Ali Lloyd via use-livecode wrote:
Mark, it would be lovely if you could be more specific. What parts of 
the
docs in particular could be improved and how? What specific sticking 
points

did you have?

Could you file a bug report about the extension builder? It may be that
something about error reporting has changed that hasn't been updated in 
the

extension builder.


Yes - LCB errors now emit with a marker and code line as to where the 
error
is... However, this requires a monospaced font to look right (it works 
really well from the terminal, for example) - so just making the log in 
field in the extension builder use such a font should fix that issue (if 
I understand Mark's issue 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

Re: Identical and similar blend modes

[Mark Waddingham via use-livecode]

On 2017-05-16 12:32, Roger Eller via use-livecode wrote:
Results may vary depending on OS, video card, and/or video drivers.  
Many

of these appear subtly different to me.


They shouldn't - all the blend mode code is cross-platform - so if there
is a difference across platform (which isn't down to just differences in
the Monitor's Color Profile) it would be a bug!

In this case, it is probably just that what you see will depend on what
the colors/alpha of the destination and source pixels are. Indeed, for 
some

of the 'structural' blend modes, they don't do very much unless they
are used within a group which has ink 'blendSrcOver', as they modify
the destination alpha channel (which cards don't really have).

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: [ANN] This Week in LiveCode 82

[Mark Waddingham via use-livecode]

On 2017-05-16 14:51, hh via use-livecode wrote:

Yes, thanks. [You did probably test on Mac only. It's not worth to mix
in the problem of linux (and Raspi) with blend modes/transparency 
here.]


I don't recall seeing any bug reports about inks/transparency on Linux -
could you elaborate?


Anyway, I updated my stack to a simple Theme-switcher, usable as tiny
plugin and included it to post RaspberryPi stacks #89
( http://forums.livecode.com/viewtopic.php?p=150402#p150402 ).

I find it more comfortable (what the stack does by one click) to simply
reverse all current settings of the prefs for theme and background by
setting the blend modes. That's pretty fast and one can use it for each
script editor window differently dark or light: incredibly efficient 
;-)


In terms of number of lines of code to achieve the effect, perhaps - but
not for the poor CPU...

Any control which has an ink other than srcCopy has to be rendered into
an offscreen buffer before it can be composited into the parent. So,
technically, the CPU would be happier if the colors used in the first
place were just inverted ;)

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: [ANN] This Week in LiveCode 82

[Mark Waddingham via use-livecode]

On 2017-05-15 21:11, Roger Eller via use-livecode wrote:

I just looked in the dictionary of 6.7.5 (my daily driver), and only
srcCopy concerns me, as it is the default for any image placed as a
control.  I also found an image that I had placed with addMax applied.
This saved me the trouble of taking it into Photoshop of Gimp to create 
the

same effect.  I'll roll with the changes.


As I said elsewhere, srcCopy is the same as blendSrcOver and only has
a distinction when it is applied to a group.

In terms of the others, there are effects you can get with the 'legacy' 
inks
and it is useful to file those uses with us so we can see what they are 
and

how to add replacements.

In the case of things applied to images, a general convolve/colormatrix 
type
property would probably give much more flexibility - and fit in much 
better
with the 'graphics pipelines' of today (rather than those of the 
1980's).


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: WannaCry [OT]

[Mark Waddingham via use-livecode]

On 2017-05-16 02:23, Richard Gaskin via use-livecode wrote:

Until we see some enforced security standards, I have no interest in
"smart cars", "smart TVs" or "smart homes".  When I look at those
products I just see one big botnet.


I'd at least hope that 'smart cars' software is engineered to a much
higher standard than other places:

   https://en.wikipedia.org/wiki/MISRA_C

[ Of course, it is slightly worrying that Chrome thinks that 
www.misra-c.com

is 'Not Secure' ;) ]

Such standards, processes and tooling helps to ensure that code that is
written minimizes the chance of vulnerabilities *in the code* (e.g. 
buffer

overruns). Of course it doesn't necessarily cover vulnerabilities in
design - e.g. in protocols.

There are other methods to ensure this is the case (at least in terms of
the code):

  - adequate automated testing (100% coverage being the goal - i.e. the
tests should exercise every line of code).

  - fuzz testing (giving random inputs to every module in a system
to make sure it handles any potential case gracefully).

  - extensive code review (i.e. ensuring that code does not make it into
a system unless it has been thoroughly checked by as many people as
possible).

  - use static analysis tools (e.g. Coverity).

Of course, the principal issue really is that most code which is used in
critical systems (and systems generally) tends to be C/C++ - or 
something

like Java where the VM and parts of the supporting libraries are written
in C/C++ (e.g. Smart TVs, Blu-Ray players, Android phones).

C/C++ are inherently unsafe (let you do things which are wrong) 
languages
(although it is becoming increasingly easy to write safe code in C++ - 
as
long as you use it in a specific way - you cannot yet turn off unsafe 
aspects

of the language which means they can be used).

The reason they are unsafe is because the design of them means that 
static
checking is really hard to do well (the depth of what Coverity does, for 
example
is quite astounding but it is not perfect by any means) and impossible 
to do

completely.

The solution then is to use *safe* languages - ones which don't let you 
write
code which contains the kind of exploitable vulnerability which result 
in

virii being able to be written in the first place.

However, the reality is that the number of safe-systems-languages (ones 
where
it is possible to write device drivers, kernels etc.) in existence is 
well,
negligible (Rust is probably the only one which has floated to the 
surface of
the dev community in recent years that I can think of); this combined 
with
the fact that there are probably not just billions but trillions of 
lines of
C/C++ code in the world means that things are probably not going to 
change
much soon - the cost to rewrite all of that in a language such as Rust 
would

probably be larger than the entire economic output of the entire world.

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: [ANN] This Week in LiveCode 82

[Mark Waddingham via use-livecode]

On 2017-05-15 21:21, hh via use-livecode wrote:

Mark W. wrote:
> and most of these legacy Blend Modes:
> clear, noop, notSrcAnd, notSrcAndReverse,
> notSrcCopy, notSrcOr, notSrcOrReverse,
> notSrcXor, reverse, set, srcAnd,
> srcAndReverse, srcCopy, srcOr,
> srcOrReverse, srcXor, blend, addPin
> addOver, subPin, transparent
> adMin, addMax



We're still on the fency about all of these - I do wonder how
much they are used anymore particularly as they do not fit into
the RGBA rendering model which everyone uses anymore and as such
are incredibly inefficient. (They will never be acceleratable,
for example).



I'd be surprised if people couldn't get similar effects by using
appropriate blend inks - if they are still in use at all.



Ali L. wrote:
To be fair, the docs claim the legacy blend modes have been deprecated
since LC 5! We've supported them for quite a long time 
post-deprecation...


1. Please read this twice and don't cry ...

The default blendLevel of each and every LC object that has an ink is
"srcCopy" --- 'incredibly inefficient' as you judge it.

2. How do you define a "similar" effect?
3. Please tell me for example which "similar" blend effect allows a 
dark
   theme in the script editor which is currently simly done by setting 
the

   fields ink to "notSrcCopy".


Okay so - I take it the current approach is:

  edit script of stack "revmenubar"
  set the ink of field "Script" of stack "revNewScriptEditor 1" to 
"notSrcCopy"


Which gives the exact same effect as:

  set the ink of field "Script" of stack "revNewScriptEditor 1" to 
"blendDifference"


As far as I can see, anyway...

However a better effect (due to the way drawing works, transparency, 
antialiasing and

such like) is to actually set the colors of the field. i.e.

  - backgroundColor black (inverse of white)
  - each color assigned to the colorization inverted in the same way

The former is directly configurable in preferences; the latter current 
has three
fixed modes also configurable in preferences (none, default, classic). 
The colorization

'schemes' are defined in the seColorizationLoadScheme handler in the
revseutilitiesbehavior.livecodescript file:



These are easy to add to - or better yet, a little dialog in preferences 
which allows

you to add / remove them would be cool.

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: [ANN] This Week in LiveCode 82

[Mark Waddingham via use-livecode]

On 2017-05-15 22:05, Richmond Mathewson via use-livecode wrote:

"the modern era"

Ah; such an awful pity that both Thee and Me have more important things 
to do;


we could have such fun playing "semantic squash".


Hehe - indeed, modern should have been 'modern'* with:

* 'Modern' in the context of the evolution of the way 2d graphics is
  expressed in computing. It has gone from pixel-oriented bitwise
  operations; to color-oriented transparent blending operations.

;)

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: [ANN] This Week in LiveCode 82

[Mark Waddingham via use-livecode]

On 2017-05-15 23:22, Alejandro Tejada via use-livecode wrote:

This Skia feature named: Perlin Noise Shader
could have this syntax:

set the fractalperlinNoise of selobj to "0.05, 0.05, 4, 0.0"
set the turbulenceperlinNoise of selobj to "0.05, 0.05, 4, 0.0"

This Skia feature named: Blur Mask Filter
could have this syntax:

set the blur of selobj to 5
set the hqblur of selobj to 10



I'd actually suggest that filters should be a list / array - you need
to be able to specify the order.

Indeed, the general model is that filters are applied after the control
is rasterized but before its rasterized buffer (with transparency) is
composited into the parent.

The bitmapEffects we currently have are filters - they do have a 
prescribed
order (as they were modelled on PhotoShop's - which at the time fixed 
the

order, I'm not sure whether that has changed); but in reality there is
use in them being reorderable and to allow multiple applications of the 
same
kind (for example you might want two dropshadows with different 
displacement).



This Skia feature named: SkMatrix
could have this syntax:

set the perspective of selobj to "1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 1, 
0, 0,

0, 0"


A perspective transform is a generalization of an affine transform 
(indeed,

I'd suggest transform, not perspective as the future property) - affine
transforms (2x3 matrices) extend to pseudo-perspective transforms (3x3) 
extend
to 3d transforms (4x4) by simple extension of the matrix (putting 1's 
and 0's

in the appropraite places).

However, there is a lot of difficulty involved in getting transforms to 
work
in Livecode (as has been discussed before) due to the way co-ordinates 
are
handled - they are always card-relative and are currently integers in 
the
engine - which makes things somewhat tricky. It would be nice to have 
though :)


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: [ANN] This Week in LiveCode 82

[Mark Waddingham via use-livecode]

In this case it means when you take into account the number of global uses of 
the (now in the modern era) non-standard inks / blend modes we provide... Does 
that percentage justify the reimplementation effort and continued maintenance 
(particularly when they have been explicitly deprecated for years) when it 
could be used on more widely usable things :)

Mark.

Sent from my iPhone

> On 15 May 2017, at 20:24, Richmond Mathewson via use-livecode 
>  wrote:
> 
> What does that word "fair" mean? I have always wondered whether
> it isn't a bit like "luck", something nebulous (c.f. "rights") to cover up
> a multitude of rather more difficult ideas.
> 
> Richmond.
> 
>> On 5/15/17 10:01 pm, Ali Lloyd via use-livecode wrote:
>> To be fair, the docs claim the legacy blend modes have been deprecated
>> since LC 5! We've supported thm for quite a long time post-deprecation...
>> 
>> On Mon, May 15, 2017 at 7:56 PM Roger Eller via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> 
>>> Oh no!  I use the legacy blendModes all the time!
>>> 
>>> 
>>> On Mon, May 15, 2017 at 2:40 PM, Alejandro Tejada via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
>>> 
> Read about new developments in LiveCode open source
> and the open source community in today's edition of
> the "This Week in LiveCode" newsletter!
> Read issue #82 here: https://goo.gl/8HNhau
 Looks like Skia Graphics Library dropped support
 for some features and LC9 will not show anymore
 these types of gradients:
 'XY', 'SqrtXY', 'Diamond' and 'Spiral'
 and most of these legacy Blend Modes:
 clear, noop, notSrcAnd, notSrcAndReverse,
 notSrcCopy, notSrcOr, notSrcOrReverse,
 notSrcXor, reverse, set, srcAnd,
 srcAndReverse, srcCopy, srcOr,
 srcOrReverse, srcXor, blend, addPin
 addOver, subPin, transparent
 adMin, addMax
 
 If you check all paint features available
 from Skia Library: https://skia.org/user/api/skpaint
 there are many useful features that LC9
 could implement, like:
 setTextScaleX (and setTextScaleY)
 SkPathEffect
 SkLine2DPathEffect
 SkDiscretePathEffect
 SkComposePathEffect
 SkSumPathEffect
 Two-Point Conical Gradient Shader
 Fractal Perlin Noise Shader
 Turbulence Perlin Noise Shader
 Compose Shader
 Blur Mask Filter
 
 Could LC implement first some of
 these Skia features like Perlin Noise
 and Blur filter?
 
 Al
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your
 subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: [ANN] This Week in LiveCode 82

[Mark Waddingham via use-livecode]

SrcCopy is identical to blendSrcOver - the latter is its alpha-aware 
counterpart. The engine makes no distinction between the two - except on groups 
where it determines if the group should be rendered first and then composited 
(blendSrcOver), or if its children should be directly composites into the 
group's parent.

That won't change.

In terms of notSrcCopy then there are other blends which do a similar thing - 
although in that specific case I'd suggest perhaps letting users set colours in 
the script editor would be a better approach ;)

Mark.

Sent from my iPhone

On 15 May 2017, at 20:21, hh via use-livecode  
wrote:

>> Mark W. wrote:
>>> and most of these legacy Blend Modes:
>>> clear, noop, notSrcAnd, notSrcAndReverse,
>>> notSrcCopy, notSrcOr, notSrcOrReverse,
>>> notSrcXor, reverse, set, srcAnd,
>>> srcAndReverse, srcCopy, srcOr,
>>> srcOrReverse, srcXor, blend, addPin
>>> addOver, subPin, transparent
>>> adMin, addMax
> 
>> We're still on the fency about all of these - I do wonder how
>> much they are used anymore particularly as they do not fit into
>> the RGBA rendering model which everyone uses anymore and as such
>> are incredibly inefficient. (They will never be acceleratable,
>> for example).
> 
>> I'd be surprised if people couldn't get similar effects by using
>> appropriate blend inks - if they are still in use at all.
> 
>> Ali L. wrote:
>> To be fair, the docs claim the legacy blend modes have been deprecated
>> since LC 5! We've supported them for quite a long time post-deprecation...
> 
> 1. Please read this twice and don't cry ...
> 
> The default blendLevel of each and every LC object that has an ink is
> "srcCopy" --- 'incredibly inefficient' as you judge it.
> 
> 2. How do you define a "similar" effect?
> 3. Please tell me for example which "similar" blend effect allows a dark
>   theme in the script editor which is currently simly done by setting the
>   fields ink to "notSrcCopy".
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: [ANN] This Week in LiveCode 82

[Mark Waddingham via use-livecode]

On 2017-05-15 20:40, Alejandro Tejada via use-livecode wrote:

Read about new developments in LiveCode open source
and the open source community in today's edition of
the "This Week in LiveCode" newsletter!
Read issue #82 here: https://goo.gl/8HNhau


Looks like Skia Graphics Library dropped support
for some features and LC9 will not show anymore
these types of gradients:
'XY', 'SqrtXY', 'Diamond' and 'Spiral'


These are back in - Michael managed to get them working again.


and most of these legacy Blend Modes:
clear, noop, notSrcAnd, notSrcAndReverse,
notSrcCopy, notSrcOr, notSrcOrReverse,
notSrcXor, reverse, set, srcAnd,
srcAndReverse, srcCopy, srcOr,
srcOrReverse, srcXor, blend, addPin
addOver, subPin, transparent
adMin, addMax


We're still on the fency about all of these - I do wonder how
much they are used anymore particularly as they do not fit into
the RGBA rendering model which everyone uses anymore and as such
are incredibly inefficient. (They will never be acceleratable,
for example).

I'd be surprised if people couldn't get similar effects by using
appropriate blend inks - if they are still in use at all.


If you check all paint features available
from Skia Library: https://skia.org/user/api/skpaint
there are many useful features that LC9
could implement, like:
setTextScaleX (and setTextScaleY)
SkPathEffect
SkLine2DPathEffect
SkDiscretePathEffect
SkComposePathEffect
SkSumPathEffect
Two-Point Conical Gradient Shader
Fractal Perlin Noise Shader
Turbulence Perlin Noise Shader
Compose Shader
Blur Mask Filter

Could LC implement first some of
these Skia features like Perlin Noise
and Blur filter?


Our first aim is to get the new Skia in and working as much as it
did before :)

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: Transparent browser widgets?

[Mark Waddingham via use-livecode]

On 2017-05-15 19:10, Roger Eller via use-livecode wrote:
I have to agree with Richard on this.  It seems tis always time to add 
new
and cool features to iOS and Mac, but not enough time to repair what 
has
been broken.  Linux isn't as mainstream, but it does have a decent base 
of
committed users.  I do believe they too would enjoy functional 
audio/video

content in their LC apps.  Just sayin'.


Um - where did I say the request was going to be implemented NOW? 
Nowhere that I can see...


I filed an enhancement request so the suggestion wasn't lost - why did 
I?


Because I recalled adding an opaque property to the mobileControl 
"browser" API years ago that did what was requested (on both iOS and 
Android, IIRC). Given that Mac now uses WebView and not CEF, and thus 
benefits from the flexibility of NSViews directly, it seemed reasonable 
that the same approach used then would work on Mac too.


Therefore, it seemed a reasonable thing to record this fact - it gives 
no indication of when it might get done, if at all (of course, being 
open-source means that someone who is not us might do it).


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: Transparent browser widgets?

[Mark Waddingham via use-livecode]

On 2017-05-15 16:43, Richard Gaskin via use-livecode wrote:

Any chance we'll see the ability to play audio and video at all in
Linux restored?


I'm not quite sure what relation that has to 'Transparent Browser 
Widget'...


Re-implementing audio and video in Linux is not currently on our near 
term

todo list.

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: Transparent browser widgets?

[Mark Waddingham via use-livecode]

I've added:

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

As an enhancement request for an 'opaque' property - at least on
Mac, Android and iOS.

There is also this:

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

Which, again, should be feasible on Mac, Android and iOS.

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: Transparent browser widgets?

[Mark Waddingham via use-livecode]

On 2017-05-13 19:35, Jonathan Lynch via use-livecode wrote:
Apparently, both WebView (android) and uiwebview (iOS) have transparent 
modes.


Would it be easy for the LC team to implement a transparent mode for
browser widgets, where the background color is transparent, allowing
other objects to show through?

This would obviate the need for some the processor intensive image
transfers in and out of the widget.

I know one would have to set the background-color of the body element
to transparent and set a couple of settings in the WebView calls. Is
that all it would take?


The browser widget uses a system 'view' (UIView on Mac, View on Android,
HWND on Windows, NSView on Mac and X11 Window on Linux) to host the 
browser

control - thus whether or not they can be composited with a transparent
background depends on the system.

For Mac, Android and iOS it is probably possible by just toggling a flag
to say whether the view is opaque or not (although I've not looked into
it).

For Windows, Linux things are more tricky - as it requires that child
windows composite into the parent window. The 'traditional' model on 
those
platforms is that child windows are islands-on-their-own. That being 
said,

CEF does have a windowless mode in more recent versions which might be
usable to get a similar effect. However, I'm not sure what would be 
involved

in providing that as a choice.

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: SVG widget?

[Mark Waddingham via use-livecode]

On 2017-05-14 00:58, hh via use-livecode wrote:

Scott R. wrote:
Maybe it’s more accurate to say "one single path definition"
because you aren't limited to a single vector path. You can
create compound graphics from multiple paths as is done in
many icons and graphics.
For example:
go url "http://tactilemedia.com/download/svg_sample.livecode;


Yes. If you define path by "connected points" (I haven't seen
that in any specification).



SVG paths are an extension of PostScript paths - these are a sequence
of disjoint subpaths. You can have as many such subpaths as you like.

However, they are always rendered as 'one thing' which is where the
fillRule (evenodd or nonzero) and direction of the subpaths comes into
play to decide which parts are filled and which parts are not.

A good illustrated example is given here:

  http://commons.oreilly.com/wiki/index.php/SVG_Essentials/Paths

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: WannaCry [OT]

[Mark Waddingham via use-livecode]

On 2017-05-13 16:53, Richmond Mathewson via use-livecode wrote:

" The WannaCry virus only infects machines running Windows"

http://www.bbc.com/news/technology-39896393

Err . . . Linux


*cough* Heartbleed *cough* ;)

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