Re: What is "Open Language"?

[Mark Waddingham]

On 2015-10-24 21:00, Richmond wrote:

Well, what to one person is 'natural language' may not be to another:
and a "10,000 different, often incompatible and sometimes confusing,
custom syntax options" does seem to sum that problem up fairly 
effectively.


Indeed - what is 'natural' to me is different to others. However, 
language is about communication between individuals and groups. Each 
develops their own idea of 'naturality' in that context.


I have to say that what people do in the privacy of their own homes and 
with friends is entirely up to them and generally of little interest to 
me - if they wish to spend a great deal of time developing weird and 
wonderful ways of setting the rect of a button then, you know what, they 
can go 'knock themselves out' and have as much fun as they can possibly 
have with such an endevaour (I certainly won't be spending any time 
doing so).


However, when 'these' people have to interact with others outside of 
such small groups, then they will find that *unless* their new approach 
fits entirely within the constraints of the group they are proffering it 
to and is demonstrably 'better' or gives more benefits than the existing 
one, then they will most likely find limited support.



It is an unreachable ideal for the plain and simple reason that
computers do not work in the
same way as human brains.


Interesting - I must confess I'm not quite up to date with the latest 
frontier research on that subject but certainly last time I did dig into 
it that was still an unanswered question.


If you are absolutely sure about your assertion and have a proof for it 
then I suggest you write up a paper right now and submit it for peer 
review in an appropriate academic journal - you would quickly find 
yourself probably being inline for a sizeable prize or two, and 
international renown (and indeed probably have a whole array of job 
offers at many prestigious academic and research institutions around the 
world).


(Just for the sake of others, I should explain - asserting that 
'computers do not work in the same way as human brains' means that the 
human brain is fundamentally capable of solving a greater set of 
problems than modern computers - i.e. the human brain is not a Turing 
Machine but something more)


Of course, whilst intellectually interesting, the reality is that 
computers have gotten pretty darn good (and continue to get better) at 
approximating the outward effects of the human brain in every increasing 
areas; which means whether or not their computational models are 
equivalent or not is really not that relevant on a day-to-day basis.


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: What is "Open Language"?

[Monte Goulding]

I agree with you. I hate synonyms. They should be replaced by auto-completion.

Sent from my iPhone

> On 26 Oct 2015, at 8:00 pm, Mark Waddingham  wrote:
> 
> (One could also argue that the problem of synonyms and abbreviations is far 
> better handled in the script-editing environment... Although nobody ever 
> seems to agree with me on that one - even though the resulting effect would 
> be identical for all intents and purposes ;)).

___
use-livecode mailing list
use-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: What is "Open Language"?

[Terry Judd]

I¹d be happy with auto-completion and fewer (or no) synonyms.

Terry...

On 26/10/2015 8:26 pm, "use-livecode on behalf of Monte Goulding"
 wrote:

>I agree with you. I hate synonyms. They should be replaced by
>auto-completion.
>
>Sent from my iPhone
>
>> On 26 Oct 2015, at 8:00 pm, Mark Waddingham  wrote:
>> 
>> (One could also argue that the problem of synonyms and abbreviations is
>>far better handled in the script-editing environment... Although nobody
>>ever seems to agree with me on that one - even though the resulting
>>effect would be identical for all intents and purposes ;)).
>
>___
>use-livecode mailing list
>use-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

What happens when enabling Hi-DPI scaling?

[Tiemo Hollmann TB]

Hello,

since LC 6.7.6 or 6.7.7 you can enable Hi-DPI scaling in the standalone
builder settings for windows.

I don't have a Hi-DPI monitor and didn't found anything in the forum about
it, so I am unsure what happens with my stack if I would enable this
setting? What exactly happens when it says "if enabled, the stack will be
scaled to fit"? A Hi-Res monitor has a higher pixel density, but my program
windows and objects have fixed sizes in pixel. My understanding is, if I
don't enable this setting, my stacks will be displayed smaller on a Hi-DPI
monitor? Correct? And enabling this setting, are they scaled to the "same
appearance", as on a standard monitor? Or what happens? If yes, probably
images get blurred, when being scaled, so you shouldn't enable this option
when you use images, correct?

Why is the Hi-DPI support for Windows a chooseable option and for OS X it is
standard since 6.7.6 (6.7.7)? Do images don't get blurred, when the stack is
resized on OS X? Why can't I disable this option on OS X?

How do you handle this option? Do you always enable it?

Thanks for your experiences

Tiemo

 

 

 

 

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

Re: What is "Open Language"?

[Mark Waddingham]

On 2015-10-26 10:26, Monte Goulding wrote:
I agree with you. I hate synonyms. They should be replaced by 
auto-completion.


How about 'spelling assist' too - referencing a dynamic dictionary based 
on context.


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: What is "Open Language"?

[Mark Waddingham]

On 2015-10-24 22:47, Mark Wieder wrote:

On 10/24/2015 12:21 PM, Peter TB Brett wrote:


* hilite -> highlight


Actually I filed a bug report on that six years ago.
http://quality.runrev.com/show_bug.cgi?id=8211

It got confirmed and ignored.
I just submitted a pull request.
Figured I might as well fix this myself.


There's a slippery slope here (in terms of the current engine parsing 
implementation at least) which means that just adding synonyms because 
the lack of them 'annoy' a small set of people (and/or because you can) 
really isn't something which makes sense.


It is clear that originally 'hilite' was the chosen spelling for that 
operation - it is an 'informal' spelling of 'highlight' which has been 
historically used in GUI frameworks (probably because it is a good deal 
shorter than 'highlight' - something which those who are fond of 'grp', 
'fld', 'ac, 'cd' etc. should feel at home with ;))


There was obviously clearly some contention over whether 'dehilite' or 
'unhilite' should be the antonym - given that even 'dehighlight' nor 
'unhighlight' tend to appear in dictionaries this is probably not 
surprising.


So, clearly someone 'complained' at some point (which is probably why 
dehilite and unhilite both exist) and 'highlight' was added. Indeed, 
there are actually the following fundamental synonyms for 'hilite' in 
the engine:

  - highlight
  - highlighted
  - highlite
  - highlited
  - hilite
  - hilited

So that is 6 ways to write exactly the same thing. (It gets better in a 
moment)


We now have the following 'compound' property names involving 'hilite':
  - hiliteborder
  - hilitecolor
  - hilitefill
  - hiliteicon
  - hilitepattern
  - hilitepixel

We also have the following 'compound' property names involving 
'hilited':

  - hilitedbutton
  - hilitedbuttonid
  - hilitedbuttonname
  - hilitedicon
  - hilitedline
  - hilitedtext

There are also the following 'other' properties:
  - autohilight
  - autohilite
  - linkhilitecolor
  - multiplehilites
  - noncontiguoushilites
  - sharedhilite
  - showhilite
  - threedhilite
  - togglehilites

So, there are (in fact) the following variations on 'hilite' currently 
in use in the engine:

  - hilite
  - highlite
  - hilight
  - highlight

Which, if accounted for in synonyms would mean we would end up with (I 
believe) 72 keywords if we ignore the 'ed' forms, and 144 if we have 
both the preset and past participles. Also, it means that every time 
anyone wants to add a property containing 'hilite', they need to add 4 
(maybe 8) variants. This kind of 'blow-up' suggests that there is 
something wrong with the approach.


So, I do think that in this case it would be far better to *choose* what 
variant spelling is the normative one and deprecate all the other 
synonyms at least until there is a much better mechanism in place for 
parsing and resolving synonyms (i.e. when compound properties are 
specified as separate words, and synonyms are substitutions done as a 
pre-processing step).


For anything like there has to a policy and my policy has always been - 
you choose a single representative for a single concept and you stick to 
it. In this case 'hilite' is a perfectly valid word to use (given its 
domain - i.e. GUIs); indeed, it is just as valid a choice for 
'highlight' as 'color' is for 'colour' and 'behavior' is for 
'behaviour'. At the end of the day this is a computer language and as 
such logical and sensible choices have to be made. (One could also argue 
that the problem of synonyms and abbreviations is far better handled in 
the script-editing environment... Although nobody ever seems to agree 
with me on that one - even though the resulting effect would be 
identical for all intents and purposes ;)).


Now, I'm not saying this won't change - clearly there is a want for 
synonyms as a fair few people seem quite fond of them. However, there 
needs to be a good mechanism in place to deal with them in the engine 
and there currently is not (particularly when considering compound 
forms) so caution is hugely advisable.


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

show/hide or open/close stack. What is good practice?

[Tiemo Hollmann TB]

Hello,

if I have stacks, which are frequently shown, like dialog windows, what is
good practice. Open once and only show/hide, when using? Or should you close
those kind of stacks always and toplevel/modal them again every time when
needed? When I need to change anything in those stacks on the fly, like
button labels, I open them only once and hide/show them when needed.

Is this just a personal preference or is there a guideline on "how to" in
LC?

What do you think about this?

Tiemo

 

 

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

Re: What is "Open Language"?

[Mark Waddingham]

On 2015-10-24 18:53, Richard Gaskin wrote:

Two questions:

1. Do we have a projected timeline for that?


LiveCode 9.


2. Isn't the goal so that we can have 10,000 different, often
incompatible and sometimes confusing, custom syntax options for doing
basic things like setting the rect of a button?  :)  (This is why I
get food thrown at me while speaking at LiveCode conferences)


That seems like quite an odd 'goal' to have... I've always thought it 
best to set 'goals' which are positive and beneficial things. I have to 
say I don't think I would have wasted any of my mental energy in working 
on something with a 'goal' such as that in mind but then, that might 
just be me.


It will be a possible side-effect - however, I suspect it would be an 
exceptionally unlikely outcome. One can spend a great deal of time 
worrying about such things and in doing so you bite your nose off to 
spite your face.


As a comparison - we are, these days, used to moving ourselves around in 
small metal boxes with explosions in front of our feet (i.e. cars). 
Statistics tend to rate this form as transport as the least safe, 
however I don't think the goal of the people who developed automotive 
transport was to kill 100,000s of people a year... At least not in my 
universe!


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: What is "Open Language"?

[Monte Goulding]

> On 27 Oct 2015, at 1:51 am, Rick Harrison  wrote:
> 
> A work around is to let all previous versions work, and put the final winning
> candidate into the dictionary, the others will no longer appear in the
> documentation.  This solves the problem with the least disruption as it
> doesn’t break anyone’s code, but helps to streamline the desired future
> syntax for the language.

Deprecation notices in the IDE would be nice. Both inline in the script editor 
and in some big list somewhere whenever we open a stack.
___
use-livecode mailing list
use-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: show/hide or open/close stack. What is good practice?

[J. Landman Gay]

On 10/26/2015 3:50 AM, Tiemo Hollmann TB wrote:

if I have stacks, which are frequently shown, like dialog windows, what is
good practice. Open once and only show/hide, when using? Or should you close
those kind of stacks always and toplevel/modal them again every time when
needed? When I need to change anything in those stacks on the fly, like
button labels, I open them only once and hide/show them when needed.

Is this just a personal preference or is there a guideline on "how to" in
LC?


It's mostly personal preference, but it depends on whether the stacks 
are substacks or not.


Substacks are always in RAM whether they are open or not, so it doesn't 
matter whether you close them or hide them.


Independent stacks take up RAM so if they are no longer needed I usually 
close and delete them.


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

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

Re: What is "Open Language"?

[Richmond]

On 26/10/15 20:55, J. Landman Gay wrote:

On 10/26/2015 1:30 PM, Richmond wrote:

Um: my endless thousands of numToChar statements in my Devawriter Pro
will have to
be rewritten should I decide to move my code-base from LC 4.5 to LC 7.*
or higher.


Not necessarily, numToChar and charToNum still work. They are 
discouraged now, but they still function. Did you try it?




No, I didn't, and should I decide to move my codebase I am sure I can 
automate

those changes relatively painlessly: I just mentioned them to
make the point about what a 'bother' lack of backwards compatibility can be.

Richmond.

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

Re: What is "Open Language"?

[Mark Waddingham]

On 2015-10-24 22:07, Geoff Canyon wrote:
This is the main thing I have been looking forward to for the past 
several

years. The goal was to allow the addition of truly new syntax and
functionality to the language. I really wanted this, and widgets is 
what it
has turned into. Not that widgets aren't a good thing, but I'd really 
like

to be able to use:
repeat for each line L in someText with index i

apply myFunction to X until the value converges

apply (+1) to every item of myList where it mod 2 = 1

...and many, many more.


No - widgets is not what it has turned into. Widgets are entirely 
orthogonal - they about extending the controls you can use in LiveCode, 
not the syntax (after all having lots of nice syntax is great, but if 
you don't have the things you can instruct to do things with it, then it 
perhaps isn't very useful).


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

[OT] GUI templates

[Richmond]

https://pixelbuddha.net/freebies/tag/ui-kits

look like fun.

Richmond.

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

Re: parentheses within string break value()

[J. Landman Gay]

On 10/26/2015 3:25 PM, Dr. Hawkins wrote:


There is a custom property (call it theProp) with a value like

"SELECT foo FROM " & tableName & " WHERE (bar > 7) AND (animal<>'cat');"



So those quotes and & are in the string to be evaluated.

My understanding of parsing is that the first piece should evaluate to

SELECT foo FROM


the second to

SELECT foo FROM


and the third to

WHERE (bar > 7) AND (animal<>'cat');


and when concatenated produce a string of

SELECT foo FROM theRealTableName WHERE (bar > 7) AND (animal<>'cat');

That is, I should get three strings, the first and last literals, and the
middle from evaluation of the variable name, which in turn should
concatenate by the &.

Instead, though, the quotation marks in the third string are ignored, and
instead of treating it as as string literal, an attempt is made to evaluate
it.


I'd use the merge command here. Make a custom property like this:

SELECT foo FROM [[theRealTableName]] WHERE [[compare1]] AND [[compare2]];

In the script:

put "(bar > 7)" into compare1
put "(animal<>'cat')" into compare2
put "realName" into theRealTableName
put merge(the cProp of me) into tCmd
revExecuteSQL tID,tCmd

You may need to add some quotation marks somewhere in there.

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

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

Re: parentheses within string break value()

[Dr. Hawkins]

On Mon, Oct 26, 2015 at 9:49 AM, Bob Sneidar 
wrote:

> Now I get "Abc"45"123(def)" in tTest. I'm not sure what you are expecting,
> but that is what is getting passed to value(). If you asked me to resolve
> that, I would probably toss a few errors, not to mention a few brews, back
> myself.
>

I seem to have mis-parsed that myself.

There is a custom property (call it theProp) with a value like

"SELECT foo FROM " & tableName & " WHERE (bar > 7) AND (animal<>'cat');"



So those quotes and & are in the string to be evaluated.

My understanding of parsing is that the first piece should evaluate to

SELECT foo FROM


the second to

SELECT foo FROM


and the third to

WHERE (bar > 7) AND (animal<>'cat');


and when concatenated produce a string of

SELECT foo FROM theRealTableName WHERE (bar > 7) AND (animal<>'cat');

That is, I should get three strings, the first and last literals, and the
middle from evaluation of the variable name, which in turn should
concatenate by the &.

Instead, though, the quotation marks in the third string are ignored, and
instead of treating it as as string literal, an attempt is made to evaluate
it.


-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
use-livecode mailing list
use-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: What is "Open Language"?

[Monte Goulding]

> On 27 Oct 2015, at 6:08 am, Mark Waddingham  wrote:
> 
>> repeat for each line L in someText with index i
>> apply myFunction to X until the value converges
>> apply (+1) to every item of myList where it mod 2 = 1
>> ...and many, many more.
> 
> No - widgets is not what it has turned into. Widgets are entirely orthogonal 
> - they about extending the controls you can use in LiveCode, not the syntax 
> (after all having lots of nice syntax is great, but if you don't have the 
> things you can instruct to do things with it, then it perhaps isn't very 
> useful).

You seem to have answered all the questions apart from the control structure 
ones. 

As far as gentle goes the good news is I’ve managed to find the control 
structures in grammar.g… The bad news is I loose the trail once I get to 
types.g… 

It’s all very interesting… a compiler for a language for making compilers that 
is compiling a language that is a compiler… 

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

[OT] SMTP Diagnostic Tool

[Bob Sneidar]

Looks like someone beat me to it.

http://www.socketlabs.com/smtp-server-connection-diagnostics-tool/

Bob S


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

Re: What is "Open Language"?

[Mark Wieder]

Mark-

Well. *This* certainly seems to have hit a nerve.

I would be fine with having everything be "hilite". Or with everything 
being "highlight". Or with everything being "blxxqvy". The point of the 
original bug report was that there's no consistency in the language. 
Sometimes you can use the "highlight" form and sometimes you have to use 
the "hilite" form. The problem is trying to remember which is which.


So that's what my pull request fixes.

I agree with what you're saying about the proliferation of synonyms. I'm 
not wild about most of the other synonyms in the language either... 
"cd", "fld", etc (although I'd hate to give up "loc" and "rect") But 
right now we're trying to have it both ways. To my eye the "hilite" form 
looks cutesy and unprofessional, but I do understand developers are lazy 
and don't like typing, so I'd be fine with that. It's in the 
documentation already.


But really... let's move in the direction of some consistency.

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

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

Re: What is "Open Language"?

[Monte Goulding]

Well there’s two ways to look at this. Either we agree that hilite was a 
mistake. Implement highlight everywhere then deprecate hilite. Or we agree that 
highlight was a mistake and we deprecate the small number of uses of that. When 
I say deprecate I just mean making a note in the dictionary at this stage. 

Either way we are on a slippery slope here. Will we add synonyms for every 
instance of Rect to give us Rectangle.

Personally I’d be relatively happy for the development engine to quietly fix 
instances of synonym use in the background when a script is compiled. Doing 
that you could drop all synonyms without too many issues. I mean is there any 
logical reason we need to be able to refer to a folder with the folder, the 
defaultFolder and the directory… Or create a folder using create folder, create 
directory, new folder or new directory???

I’m sure at some point someone decided that they could import projects from 
other platforms by creating all these synonyms. A few seconds thought on that 
and they might have realised that parsing the scripts to change them to use the 
common syntax would have been much cleaner.

Cheers

Monte

> On 27 Oct 2015, at 1:07 pm, Mark Wieder  wrote:
> 
> Mark-
> 
> Well. *This* certainly seems to have hit a nerve.
> 
> I would be fine with having everything be "hilite". Or with everything being 
> "highlight". Or with everything being "blxxqvy". The point of the original 
> bug report was that there's no consistency in the language. Sometimes you can 
> use the "highlight" form and sometimes you have to use the "hilite" form. The 
> problem is trying to remember which is which.
> 
> So that's what my pull request fixes.
> 
> I agree with what you're saying about the proliferation of synonyms. I'm not 
> wild about most of the other synonyms in the language either... "cd", "fld", 
> etc (although I'd hate to give up "loc" and "rect") But right now we're 
> trying to have it both ways. To my eye the "hilite" form looks cutesy and 
> unprofessional, but I do understand developers are lazy and don't like 
> typing, so I'd be fine with that. It's in the documentation already.
> 
> But really... let's move in the direction of some consistency.
> 
> -- 
> Mark Wieder
> ahsoftw...@gmail.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: What is "Open Language"?

[Mark Waddingham]

On 2015-10-26 19:30, Richmond wrote:

Um: my endless thousands of numToChar statements in my Devawriter Pro
will have to
be rewritten should I decide to move my code-base from LC 4.5 to LC
7.* or higher.


I'm not sure that is necessarily true. I believe you use 'unicodeText' 
in your code-base, and numToChar() when 'useUnicode' is true. This 
combination of things should work as it did before and will continue to 
do so (if it doesn't then let me know and we'll take a look to advise - 
as it could be there is a bug lurking there).


However, if you want to take advantage of the 'transparent' Unicodeness 
of 7+, then you will need to change the uses of 'unicodeText' to 'text' 
and 'numToChar' to 'numToCodepoint'.


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: What is "Open Language"?

[J. Landman Gay]

On 10/26/2015 1:30 PM, Richmond wrote:

Um: my endless thousands of numToChar statements in my Devawriter Pro
will have to
be rewritten should I decide to move my code-base from LC 4.5 to LC 7.*
or higher.


Not necessarily, numToChar and charToNum still work. They are 
discouraged now, but they still function. Did you try it?


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

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

Re: What is "Open Language"?

[gcanyon]

I wrote something like this about a dozen years ago: a script pre-processor 
that worked with the script editor to store the pre-processed script as a 
custom property for use later. 

I remember implementing default values for parameters like so:

on someHandler paramOne=27, paramTwo=13

Which would translate to:

on someHandler paramOne, paramTwo
if paramOne is empty then put 27 into paramOne
if paramTwo is empty then put 13 into paramTwo

and a few other preprocessor commands as well. 


gc

> On Oct 26, 2015, at 5:00 AM, Mark Waddingham  wrote:
> 
> One could also argue that the problem of synonyms and abbreviations is far 
> better handled in the script-editing environment... Although nobody ever 
> seems to agree with me on that one - even though the resulting effect would 
> be identical for all intents and purposes ;)).

___
use-livecode mailing list
use-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: What is "Open Language"?

[Roland Huettmann]

Originally I had thought that "Open Language" means to allow LiveCode to
run other scripting languages within it's framework, for example using
Python, or somehow link such languages into LiveCode.

I started hating "machines" who started "understanding" me and making
assumptions about what I want. Already I hate when at Google confines me to
a certain earthly region and that it became almost impossible or very
difficult to change language. Again I want to become a "free" user of the
Internet. Or at least, there should be a button to switch OFF all
assumption about who I am and what I want.

I would love LiveCode NOT to understand the uncertainty of me. Computers
should not be behave being as ambiguous as we humans are. We love them
because they do what we want them to do, and not the other ways around, and
computer language should not leave much space for interpretation. It
follows a logic, and as long as it does that, it is acceptable. And we love
LiveCode because it allows to express logic in a way which is near to human
language - but will never replace it (I hope at least).

So, I like Monte's suggestion to have an auto-correct feature to help
correcting wrong input and wrong spelling - the correct one being defined
in the dictionary with as few synonyms as possible, but not force us not to
do something wrong. In case of wrong-doing, the compiler should bark at us,
or the application will misbehave - and we have learnt from doing wrong and
may have a chance to correct ourselves.

(The new scripting environment of FileMaker 14 is not so bad in
accomplishing some of this. A good place to take lessons from. As much as I
hated the old scripting environment, the new one has nice edges and really
is supportive...)

The language should grow not in the sense of making things more ambiguous
as they already are, but just advance the capabilities of expression within
limitations. If these limitations would be removed, the river will not find
it's bed to the ocean and spread all over in an uncontrolled way. We would
have big problems understanding each-other, and the effect will be simply
chaotic programming style.

I do not believe that the need for programming will die in 20 years as
someone here stated. Such prognosis was there already 20 years ago that
soon machines will program themselves. At least I do not want it - or only
as much as boundaries can be clearly defined. We could also state that
logic will not be needed in 20 years, or that we all started stop using our
mental capabilities and hand over our brain to the computer.

I do not want the computer to switch on the light in my room when I enter,
and know in advance what I am going to do or think or wish - unless I
completely control its behavior. Thinking further, this leads to quite a
philosophical discussion and touches the base of our human existence and
the notion about who we are.

Think of musical notes. Would Mozart have been able to communicate his
genius without them? Musical notes leave all the space for expression, but
still confine the basic intention into a framework of the limitations of a
language.

Why do we love LiveCode? Or why would students love it? Because it gives
freedom of expression within a set of limitations - using simple English
expressions. How would a Chinese learn all the intricacies of English
vocabulary? He will not. Keep it simple and "stupid" within it's own set,
as musical notes are not that difficult to learn, but using them is quite
an interesting and different matter.

When there is a flow of beauty in such language, people will catch on. But
do not make it to be really English. Let us rather focus on thinking what
such typical user might expect when writing a statement. Will the machine
act accordingly? Or will there be unexpected results? And if there are
unexpected results, there must be "work-rounds", and then things become
ugly.

In this sense I would raise my voice against "Open Language".

But I am all for more and more beauty in LiveCode, and for ever growing
power accomplishing things that we want the machines to do in the most
logical way possible using LiveCode. And I think the "team" is trying to
just accomplish this - step by step. I admire them.

People are not against learning as long as there is a fruit to be
gained.And if we do not challenge our brain with ever growing
sophistication then it will also just die away. )

Roland



On 26 October 2015 at 11:09, Mark Waddingham  wrote:

> On 2015-10-26 10:26, Monte Goulding wrote:
>
>> I agree with you. I hate synonyms. They should be replaced by
>> auto-completion.
>>
>
> How about 'spelling assist' too - referencing a dynamic dictionary based
> on context.
>
> 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, 

Re: What is "Open Language"?

[Rick Harrison]

Hi Mark,

Whenever one deprecates code, it destroys someone’s code somewhere.
Don’t do it.

I had a project I had worked on for 10 years of my life.  It encompassed
over 70,000 lines of hard won hand-written code.  One day the company
who was producing the language decided to make some major changes
deprecating much of the language.  There was no migration tool provided
by the company to make the changes painless.

I spent yet another year of my life hand coding the changes to get the code
working again.  Two years later, the company did the same thing yet again!
I couldn’t afford to go through the process yet again.  My code was
basically destroyed by the company by deprecation of the code base.

A work around is to let all previous versions work, and put the final winning
candidate into the dictionary, the others will no longer appear in the
documentation.  This solves the problem with the least disruption as it
doesn’t break anyone’s code, but helps to streamline the desired future
syntax for the language.

Just my 2 cents for the day.

Cheers,

Rick




 
> On Oct 26, 2015, at 5:00 AM, Mark Waddingham  wrote:
> 
> So, I do think that in this case it would be far better to *choose* what 
> variant spelling is the normative one and deprecate all the other synonyms at 
> least until there is a much better mechanism in place for parsing and 
> resolving synonyms (i.e. when compound properties are specified as separate 
> words, and synonyms are substitutions done as a pre-processing step).

___
use-livecode mailing list
use-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: Print stack as PDF

[Richard Gaskin]

Spookier that you happened to be reading that particular message from 
2008 in 2015.


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



stephen barncard stephenREVOLUTION2 at barncard.com
Sun Oct 25 06:32:46 CET 2015
Previous message: parentheses within string break value()
Next message: Open Language and stability
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, Aug 29, 2008 at 7:50 AM, Rob Cozens wrote:


- Charles Reich, The Greening of America
___



This is so spooky. At this very moment, I was passing along the email of
Charles Reich to a crew that's working on a new GD documentary. Charles did
a noted interview with Jerry Garcia for rolling stone at Jerry's house in
1972 and I was involved in 'mastering' the 3 hours of interviews for
intelligibility at my home studio in Sausalito.
I copied back on to a cassette for Charles back then,  kept the work tape
for 40 years, and digitized it recently.

sqb



___
use-livecode mailing list
use-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: glx2

[Bob Sneidar]

A few notes about GLX2. There are no red dot breakpoints in GLX2 (unless I am 
missing something). 

So you might be tempted to turn on and off GLX2 as needed. Problem is, GLX2 has 
it's own versioning system  that allows you to go back x compiles to a prior 
version. The built-in compiler does not know about this, so switching from GLX2 
back to the built-in debugger has a surprise for you. It will load a prior 
version of your script without all the changes you may have recently made. 

There is a feature to account for this, warning you that the version it's 
loading and the version it expected are not the same, but I have found this 
unreliable at times, and I have lost edits switching back and forth with a 
stack open. So don't get into the habit of turning it on and off in a session. 
Use it, or don't. 

Other than that, I like it a lot, especially the clarvoyance feature which 
presents a popup of similar matches after typing x characters. That is mainly 
what I use it for, along with the breadcrumbs feature which adds a link to 
where you were when you clicked a handler to go to that handler. 

Bob S


> On Oct 25, 2015, at 20:01 , Sannyasin Brahmanathaswami  
> wrote:
> 
> wow… I didn’t fully realize that glx2 was still alive. I bought a license 
> from Jerry for that years ago… loved it, 
> 
> just downloaded, 
> 
> thanks Mark
> 
> But: ha! forgot how it works… where is the documentation?
> 
> I see the sub bar gray notification underneath LC ide toolbar (7.1GM for me 
> right now)  and the blue to gray to blue toggle on the GLX2 label.
> 
> How do you launch into it?
> 
> 
> 
> 
> 
> 
> 
> 
> On 10/22/15, 11:08 PM, "use-livecode on behalf of Terry Judd" 
>  terry.j...@unimelb.edu.au> wrote:
> 
>> I¹d forgotten how much I liked GLX2. Thanks so much for maintaining it
>> Mark.
>> 
>> Terry...
>> 
> ___
> use-livecode mailing list
> use-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

What is "Open Language"?

[Georges Malamoud]

Don’t forget other possibilities of this future open language :
Allow scripts to be written in a non-english language - french in my case for 
example - especially for kids and students from non english speaking developing 
countries.
Different words and slightly different syntax.

These foreign scripts would be translated in Livecode open language (which 
could by the way be translated in english after).
There were comments at Kickstarter times about such possibilities (low priority 
on the list, but still there and announced).
Of course it covers also British to american ;)

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

[ANN] This Week in LiveCode 6

[Peter TB Brett]

Hi all,

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 #6 here: https://goo.gl/p5uWxk


This is a weekly newsletter about LiveCode, focussing on what's been 
going on in and around the open source project.  New issues will be 
released weekly on Mondays.  We have a dedicated mailing list that will 
deliver each issue directly to you e-mail, so you don't miss any!


If you have anything you'd like mentioned (a project, a discussion 
somewhere, an upcoming event) then please get in touch.


 Peter

--
Dr Peter Brett 
LiveCode Open Source Team

LiveCode on reddit: https://reddit.com/r/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: Sending encrypted and authenticated emails

[Bob Sneidar]

Actually, I was playing around with the Exchange connectors, and inadvertently 
disable the default connector. DOH!

Bob S


> On Oct 25, 2015, at 19:19 , Mark Wieder  wrote:
> 
> On 10/25/2015 05:10 PM, Glen Bojsza wrote:
>> Hi Bob,
>> 
>> I tried contacting via bobsnei...@iotecdigital.com but the mail bounced.
> 
> I bounced an email to Bob as well.
> No doubt a temporary server glitch, although the Exchange headers in the 
> bounce message are pretty scary.
> 
> 10/25/2015 11:39:19 PM - Remote Server at 
> na01-internal.map.protection.outlook.com (10.58.52.27) returned '451 4.4.0 
> Primary target IP address responded with: "421 4.3.2 Service not available." 
> Attempted failover to alternate host, but that did not succeed. Either there 
> are no alternate hosts, or delivery failed to all alternate hosts. The last 
> endpoint attempted was 198.24.239.75:1701'
> 
> -- 
> Mark Wieder
> ahsoftw...@gmail.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: What is "Open Language"?

[Mark Waddingham]

On 2015-10-24 23:25, Richard Gaskin wrote:

I've worked with OS APIs in Pascal, C, and two xTalks, Tookbook's
OpenTalk scripting language which provides that built-in, and
CompileIt for HyperTalk.


This is true - they did. However, they come from a time when almost all 
OS APIs were procedural, and quite simple.


(Also, due to the limitations of what one can represent in 'stringy' 
languages - of which LiveCode Script is one - such a facility is 
incredibly fiddly, error prone and difficult to build nice abstractions 
around).



The one thing I've learned from that is that the language you're using
isn't all that important, because no matter what you're writing in the
OS you're talking to expects C:  it uses C data types and structures,
provides tons of great sample source but all in C, and requires that
you think like a C programmer, understanding and managing data in ways
a good xTalk normally insulates from even having to think about - the
difference between a pointer and a handle isn't interesting to most
xTalkers, but can be essential in C.


This isn't true. Most of Android's APIs are Java. Most of iOS / Mac's 
APIs are Objective-C. A lot of Windows functionality is provided through 
COM - which is an object-based API. Oh, and in the browser (HTML5) world 
the APIs are JavaScript (another object-based language).



By the time you become fluent enough in C to understand OS APIs well
enough to use them, you've already learned enough to write in it as
well.


This is simply not the case - there's a huge chasm between being able to 
understand C-style APIs and data-structures enough to use them and being 
able to write C (at least to any degree of use / proficiency).


Indeed, given that we are talking about (in many cases) very well 
defined APIs, which have been (ignoring Win32 and MacClassic ;)) very 
well designed - you actually don't need to understand much C to use 
them.


All you need to understand is what the values they take and return are, 
and how they can be appropriately marshalled. Indeed, the goal is that 
LiveCode Builder will do most of the marshalling for you - so as long as 
you have enough of an understanding to read the API definitions and map 
them to LCB forms, you can then use a language which is a great deal 
more familiar to use them (to be fair we still have a fair bit more work 
to do on the marshalling front...).



Monte's done an amazing job showing off what the externals SDK can do
for extending LC.  It would be great to see more people jump on board
with it.


Externals don't really go away with LCB - they just get renamed. All 
that happens is that LCIDLC which is used to simplify the interface 
between Engine and External goes away and is replaced by an LCB file 
containing nothing but foreign handler declarations. Of course, you then 
get the benefit of being able to mix you LCB and C in any way you 
choose.


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

[Mark Talluto]

I used to use this script editor full time back in the day. It is really nice 
to see that you are keeping it going Mark. Thought I might give it a try again 
and see how it goes.

I am getting an answer dialog with what appears to be executionContext values 
after almost every action I do. I am using GLX_Code19 beta.rev, date: 
2015-10-21.
Using with LC 6.6.5 on Mac 10.10.5.

Any ideas?


Best regards,

Mark Talluto
canelasoftware.com 
CassiaDB: The rapid development, free local storage database, made for LiveCode 
developers: livecloud.io 





___
use-livecode mailing list
use-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: parentheses within string break value()

[Bob Sneidar]

As always, put it into a variable, copy the contents of the variable to the 
clipboard, either programmatically, or from the debugger, paste it into an SQL 
editor, and it should show you where the error occurs. 

Bob S


> On Oct 25, 2015, at 08:19 , Dr. Hawkins  wrote:
> 
> On Sat, Oct 24, 2015 at 5:58 PM, Scott Rossi  wrote:
> 
>> Is 123 a function?  If yes, I believe you need to remove the quotes
>> surrounding it.
>> 
> 
> Just some text.  I'm trying to concatenated strings, but livecode is
> looking at punctuation inside of the quoted literal.
> 
> That was a simplified version; the actual is something like
> 
> "SELECT uniqDNA FROM " & dhtbl_dna & " WHERE (cname||cadr NOT NULL) AND
> (chrType <> 'K');"
> 
> 
> where dhtbl_dna holds a table name and the rest are *supposed* to be string
> literals
> 
> -- 
> Dr. Richard E. Hawkins, Esq.
> (702) 508-8462
> ___
> use-livecode mailing list
> use-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: parentheses within string break value()

[Dr. Hawkins]

On Mon, Oct 26, 2015 at 8:29 AM, Bob Sneidar 
wrote:

>
>
> on mouseUp
>put "Abc" & 45 & "123(def)" into tTest
>put  value (tTest)
> end mouseUp
>
> tTest results in Abc45123(def) so you are trying to get the value of the
> result of a function called Abc45123() where you pass a value in a variable
> called def. At run time, do you have a function Abc45123()? Is there a
> variable def? If the answer is no to either of these, well there's your
> problem! :-)
>

But that's not quite what I'm looking at here.

 put quote & "Abc" & quote & 45 & quote & "123(def)"  & quote into tTest


gives the type of string I'm looking at.  That is, 123(def) is surrounded
by quotes *in the string* being fed to value, and therefore should be
treated as a literal, shouldn't it?

-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

LaunchServicesError error 0 - simulator

[Alan Stenhouse]

After installing LC 6.7.8 RC1 and testing an app under it, I now find that 
opening the same app in LC 6.7.6 and attempting to run it on the simulator 8.2 
results in the error

“Unable to start simulation: The operation couldn’t be completed. 
(LaunchServicesError error 0.)”

The app previously ran fine. And it also seems to run ok under 6.7.8 RC1.

Anyone come across this before??  If interested some relevant messages from the 
system.log are below.

OSX 10.9.5

cheers

Alan

—
msgs from system log (abbreviated for readability):

0xb0093000 realpath_parent_no_symlink: Found symlink at destination path  ….

0xb0093000 make_and_check_dest_path: Failed to realpath parent of ….

0xb0093000 hardlink_copy_hierarchy: Failed to make dest path for file 
CrosshairSelector.png

0xb0093000 -[MIInstallableBundlePatch applyPatchWithError:]: 82: Could not 
hardlink copy  …..

0xb0093000 -[MIInstaller performInstallationWithError:]: Preflight stage failed

0xb0115000 __MobileInstallationInstallForLaunchServices_block_invoke240: 
Returned error Error Domain=MIInstallerErrorDomain Code=8 "Could not hardlink 
copy …… UserInfo=0x7c97b5a0 {LegacyErrorString=PackagePatchFailed, 
FunctionName=-[MIInstallableBundlePatch applyPatchWithError:] …..  
SourceFileLine=82}

CoreSimulatorBridge[1056]: ERROR: MobileInstallationInstallForLaunchServices 
returned nil





___
use-livecode mailing list
use-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: Keep Selection Focus When Switching to Substack

[Bob Sneidar]

I think the reply was to trap for suspendStack in your apps, save the current 
selection and selectedObject, then trap for resumeStack and set it again. It's 
the only way I've found to do it. It's a pain, but not difficult to implement. 
I agree that the selection for a stack should not deselect when switching to 
another stack or app. I suppose then that the selection should be a stack 
property instead of a global one, but I don't see how they could change it now. 

Bob S


> On Oct 23, 2015, at 19:51 , Sannyasin Brahmanathaswami  
> wrote:
> 
> I think I asked this before, 
> 
> but… is there a way to keep the selection when switching to a substack that 
> is set to palette?
> 
> The goal is to have buttons that operate on selected text, but in a separate 
> stack.
> 
> Brahmanathaswami
> 
> ___
> use-livecode mailing list
> use-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: What is "Open Language"?

[Mark Waddingham]

On 2015-10-26 15:51, Rick Harrison wrote:

Whenever one deprecates code, it destroys someone’s code somewhere.
Don’t do it.


Indeed, we have tried and do continue to try our very best not to break 
people's code as the platform evolves (even though this is a huge 
constraint to put on a programming environment which evolved from 
something born in the late 1980's - it makes the assumption that all 
decisions taken then and up until were correct then and correct relative 
to any future consequence and thus have no forward consequences - which 
is definitely not the case).


However, I'm not going to commit us to never deprecating things - we do 
and will continue to do so as needed. Deprecated features will continue 
to work for as long as it is feasible to do so.


A work around is to let all previous versions work, and put the final 
winning

candidate into the dictionary, the others will no longer appear in the
documentation.  This solves the problem with the least disruption as it
doesn’t break anyone’s code, but helps to streamline the desired future
syntax for the language.


The problem here is that you are assuming it is possible for 'all 
previous versions to work' from now until some arbitrary point in the 
future. This just isn't the case - code ages and computer technology 
continual renews.


For example, the 'liveResizing' property no longer does anything. Why? 
Because Cocoa has no facility to turn liveResizing off.


Similarly, things like the 'pixmapId' properties and such used to allow 
you to do really funky things on certain platforms which it was not 
possible to continue to make work when we brought the graphics 
capabilities up to scratch with other environments in 2.7. (Fortunately, 
long before these 'funky things' stopped working we provided a much 
better way to have the same effect - i.e. export/import snapshot from 
object).


In terms of syntax / synonym related suggestions - then the situation is 
much easier. We might deprecate some, just to make it clear what the 
'preferred' form is and to discourage further usage. We would never 
remove them until such a point that we do have a suitable migration tool 
/ method of expressing them which means people can choose to use them, 
or not, depending on their own personal preference.


In terms of current functionality (from a semantics point of view) there 
are a growing list of 'anomalies' in the bug database which are things 
which really aren't 'correct' at the moment (and never have been). It 
would be better for all new code and new users if they were not ladened 
with the baggage of those things being how they currently are. However, 
again, we aren't going to change that functionality until we can 
implement a compatibility mechanism meaning you don't have to update old 
code.


I suspect the environment you have been bitten by in the past was one 
which was hugely monolithic in terms of implementation. They probably 
redid the internals with little regard for backwards compatibility 
(because it wasn't a viable business avenue for them to be concerned 
about it - or they simply did not know how to) to reduce the engineering 
burden and to breath new life into it in the modern era (and thus 
continue to be viable).


The difference in LiveCode's case is that whilst the entire refactoring 
project, widgets and (eventually) Open Language is about turning 
something monolithic and hugely constrained into something modular and 
open, we are trying to do it in such a way that will ensure existing 
code will continue to 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: parentheses within string break value()

[Bob Sneidar]

I did

on mouseUp
   put "Abc" & 45 & "123(def)" into tTest
   put  value (tTest)
end mouseUp

tTest results in Abc45123(def) so you are trying to get the value of the result 
of a function called Abc45123() where you pass a value in a variable called 
def. At run time, do you have a function Abc45123()? Is there a variable def? 
If the answer is no to either of these, well there's your problem! :-)

Bob S

 
> On Oct 24, 2015, at 17:46 , Dr. Hawkins  wrote:
> 
> I am finding that parentheses within strings break value()
> 
> put  value ("Abc" & 45 & "123(def)")


___
use-livecode mailing list
use-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: What is "Open Language"?

[Walt Brown]

We've seen this before...

https://sites.google.com/site/hoytssecretlair/resources/s-1

Walt

On Mon, Oct 26, 2015 at 10:51 AM, Rick Harrison 
wrote:

> Hi Mark,
>
> Whenever one deprecates code, it destroys someone’s code somewhere.
> Don’t do it.
>
> I had a project I had worked on for 10 years of my life.  It encompassed
> over 70,000 lines of hard won hand-written code.  One day the company
> who was producing the language decided to make some major changes
> deprecating much of the language.  There was no migration tool provided
> by the company to make the changes painless.
>
> I spent yet another year of my life hand coding the changes to get the code
> working again.  Two years later, the company did the same thing yet again!
> I couldn’t afford to go through the process yet again.  My code was
> basically destroyed by the company by deprecation of the code base.
>
> A work around is to let all previous versions work, and put the final
> winning
> candidate into the dictionary, the others will no longer appear in the
> documentation.  This solves the problem with the least disruption as it
> doesn’t break anyone’s code, but helps to streamline the desired future
> syntax for the language.
>
> Just my 2 cents for the day.
>
> Cheers,
>
> Rick
>
>
>
>
>
> > On Oct 26, 2015, at 5:00 AM, Mark Waddingham  wrote:
> >
> > So, I do think that in this case it would be far better to *choose* what
> variant spelling is the normative one and deprecate all the other synonyms
> at least until there is a much better mechanism in place for parsing and
> resolving synonyms (i.e. when compound properties are specified as separate
> words, and synonyms are substitutions done as a pre-processing step).
>
> ___
> use-livecode mailing list
> use-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: What is "Open Language"?

[Mark Waddingham]

On 2015-10-24 22:55, JB wrote:

If you do get Open Language what will it do to the
speed?  They said LC8 would be good because it
will make it easier for developers to write code in
LC which needed to be and external before.


We're still working on the 'foreign function interface' in LCB, so it is 
not yet as mature as we would like. The benefits of doing it from LCB 
rather than in C is that you don't have to deal with C compilers, 
toolchains and IDEs. (This is particularly pertinent if you are wanting 
to wrap an existing library which you don't have to compile yourself!).



Then after releasing it they said it is slower to use
than a external written in C.


Given that most OS APIs do quite heavyweight things execution speed is 
not really a concern. After all, if you are asking the OS 'please render 
this PDF page here', then it matters not one iota what the cost of 
abstraction is to call that OS supplied rendering function - it will 
always be orders of magnitude less than rasterizing millions of pixels.


In most cases, I think you'll generally find that speed of writing code 
for these kind of things is much more important than the speed of the 
bit which marshals things appropriately to call the API.


Now, that is not to say that speed of LiveCode Builder is not important 
to us - because it critically is. We are designing the language to try 
and ensure that it can be compiled and run at speeds which are not too 
dissimilar to native code in the future - this is why variables are 
typed, type conversions are more strict and handler calls are 'static' 
(not determined at runtime) rather than dynamic.


Indeed, the plan is that LiveCode Script (as it is now) and LiveCode 
Builder will eventually sit atop the *same* underlying bytecode-based VM 
so both can benefit from a native compilation strategy (probably based 
on LLVM). The *difference* is that the scope of optimization of LiveCode 
Script will be a great deal less than that for LiveCode Builder due to 
its dynamic design and use.


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: parentheses within string break value()

[Bob Sneidar]

The text I copied didn't have the quotes. I'll try again.

Bob S


On Oct 26, 2015, at 08:48 , Dr. Hawkins 
> wrote:

put quote & "Abc" & quote & 45 & quote & "123(def)"  & quote into tTest

___
use-livecode mailing list
use-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: What is "Open Language"?

[Richard Gaskin]

Mark Waddingham wrote:


Of course, whilst intellectually interesting, the reality is that
computers have gotten pretty darn good (and continue to get better) at
approximating the outward effects of the human brain in every increasing
areas; which means whether or not their computational models are
equivalent or not is really not that relevant on a day-to-day basis.


When we get to a place where Noam Chomsky, Daniel Everett, and Peter 
Norvig to agree on what the rules should be, I agree that at that time 
we'll have had plenty of time for the AI community to figure out how to 
implement those rules. ;)


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

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

Re: What is "Open Language"?

[Richard Gaskin]

Mark Waddingham wrote:


On 2015-10-24 23:25, Richard Gaskin wrote:

I've worked with OS APIs in Pascal, C, and two xTalks, Tookbook's
OpenTalk scripting language which provides that built-in, and
CompileIt for HyperTalk.


This is true - they did. However, they come from a time when almost all
OS APIs were procedural, and quite simple.


Agreed, modern OS frameworks require much more study, hence:


The one thing I've learned from that is that the language you're using
isn't all that important, because no matter what you're writing in the
OS you're talking to expects C:  it uses C data types and structures,
provides tons of great sample source but all in C, and requires that
you think like a C programmer, understanding and managing data in ways
a good xTalk normally insulates from even having to think about - the
difference between a pointer and a handle isn't interesting to most
xTalkers, but can be essential in C.


This isn't true. Most of Android's APIs are Java. Most of iOS / Mac's
APIs are Objective-C. A lot of Windows functionality is provided through
COM - which is an object-based API. Oh, and in the browser (HTML5) world
the APIs are JavaScript (another object-based language).


By the time you become fluent enough in C to understand OS APIs well
enough to use them, you've already learned enough to write in it as
well.


This is simply not the case - there's a huge chasm between being able to
understand C-style APIs and data-structures enough to use them and being
able to write C (at least to any degree of use / proficiency).


The gap between understanding low-level data types, structures, 
frameworks, and APIs and being able to write in the lower-level language 
they were designed for is smaller than the gap between knowing only 
xTalk and having to learn to think in terms of low-level data types, 
structure, frameworks, and APIs.


Indeed, that's the point of xTalk.

Don't get me wrong, it's cool where Builder can help make that gap a bit 
smaller.


But it'll be there, so I think it's useful to help manage expectations 
on this.  The people who currently write externals will be able to make 
excellent use of it, but it may become disappointing for anyone who 
believes Builder alone can substitute for learning the many details 
beyond the language needed to make good use of it.


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

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

Re: parentheses within string break value()

[Bob Sneidar]

Now I get "Abc"45"123(def)" in tTest. I'm not sure what you are expecting, but 
that is what is getting passed to value(). If you asked me to resolve that, I 
would probably toss a few errors, not to mention a few brews, back myself. 

Bob S


> On Oct 26, 2015, at 08:48 , Dr. Hawkins  wrote:
> 
> But that's not quite what I'm looking at here.
> 
> put quote & "Abc" & quote & 45 & quote & "123(def)"  & quote into tTest
> 
> 
> gives the type of string I'm looking at.  That is, 123(def) is surrounded
> by quotes *in the string* being fed to value, and therefore should be
> treated as a literal, shouldn't it?
> 
> -- 
> Dr. Richard E. Hawkins, Esq.


___
use-livecode mailing list
use-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: What is "Open Language"?

[Bob Sneidar]

[FAIR WARNING: BLOVIATION TO FOLLOW]

Mark Waddingham wrote:

> Of course, whilst intellectually interesting, the reality is that
> computers have gotten pretty darn good (and continue to get better) at
> approximating the outward effects of the human brain in every increasing
> areas; which means whether or not their computational models are
> equivalent or not is really not that relevant on a day-to-day basis.

I proceed on the assumption you are talking about artificial intelligence. If 
not, read no further. 

If by "approximating" you really meant "simulating" I'm right there with you. 
But if you meant something like "approaching functional identity" I couldn't 
disagree more. I could theoretically express a mathematical model of a kitchen 
table so intricate that it took into account every variance in color, density, 
size, weight etc. and the minor vairances of each aspect in an extremely 
granular three dimensional space. But the mathematical model would never become 
a table. Maybe I do this using a binary model, or perhaps an analog one would 
be better. 

If I could then render the table into some kind of three dimensional image, I 
might be able to produce a very convincing replica of the table, so that you 
could not tell the difference with the naked eye. Just don't try to put 
anything *ON* the table. It's not a table, it is a model of one. A simulation. 

I am even less convinced that you can reproduce what we call Rational Thought 
with a computer. It is not really certain what the phenomenon is. I know there 
is a theory that the massive numbers of synapses in the brain are responsible 
for producing self awareness, and eventually rational thought, but if so then I 
cannot regard rational thought itself as anything but an illusion. An accident. 
A byproduct of biological order on an immense almost unimaginable scale. 

And if that is what I, devoid of my body am, and you can eventually reproduce 
me in a laboratory, without all the negative aspects attached to the biological 
creature I call "me", well then shoot me off into space and open the hatch, 
because at that point it will be obvious that everything I thought mattered was 
really only an illusion. 

Bob S



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

Re: What is "Open Language"?

[Richard Gaskin]

Mark Waddingham wrote:

> On 2015-10-24 18:53, Richard Gaskin wrote:
>> Two questions:
>>
>> 1. Do we have a projected timeline for that?
>
> LiveCode 9.
>
>> 2. Isn't the goal so that we can have 10,000 different, often
>> incompatible and sometimes confusing, custom syntax options for doing
>> basic things like setting the rect of a button?  :)  (This is why I
>> get food thrown at me while speaking at LiveCode conferences)
>
> That seems like quite an odd 'goal' to have...

Agreed.  Apparently the combination of both a smiley face and a 
reference to having food thrown at me wasn't enough to clarify that I 
wasn't being serious with that wording.


I was merely having fun with some of expectations among the readers here 
for what Open Language might be used for.


Personally, I don't mind comma-delimited arguments, and am generally 
happy with any syntax that let's me get my work done.


I'm fine with whatever there's budget to provide to let folks explore 
novel syntax, even more so with your reminder here that Open Language is 
among the last of the enhancements in queue, long after being able to 
play a video file on Linux without crashing and other less glamorous but 
useful things.


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


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

Re: LaunchServicesError error 0 - simulator

[Alan Stenhouse]

Please ignore the last message - this seems to now be resolved. Not totally 
sure why though…

Sorry for the disturbance… :-)

cheers

Alan

On 26 Oct 2015, at 5:09 pm, Alan Stenhouse  wrote:

> After installing LC 6.7.8 RC1 and testing an app under it, I now find that 
> opening the same app in LC 6.7.6 and attempting to run it on the simulator 
> 8.2 results in the error
> 
> “Unable to start simulation: The operation couldn’t be completed. 
> (LaunchServicesError error 0.)”
> 
> The app previously ran fine. And it also seems to run ok under 6.7.8 RC1.
> 
> Anyone come across this before??  If interested some relevant messages from 
> the system.log are below.
> 
> OSX 10.9.5
> 
> cheers
> 
> Alan
> 
> —
> msgs from system log (abbreviated for readability):
> 
> 0xb0093000 realpath_parent_no_symlink: Found symlink at destination path  ….
> 
> 0xb0093000 make_and_check_dest_path: Failed to realpath parent of ….
> 
> 0xb0093000 hardlink_copy_hierarchy: Failed to make dest path for file 
> CrosshairSelector.png
> 
> 0xb0093000 -[MIInstallableBundlePatch applyPatchWithError:]: 82: Could not 
> hardlink copy  …..
> 
> 0xb0093000 -[MIInstaller performInstallationWithError:]: Preflight stage 
> failed
> 
> 0xb0115000 __MobileInstallationInstallForLaunchServices_block_invoke240: 
> Returned error Error Domain=MIInstallerErrorDomain Code=8 "Could not hardlink 
> copy …… UserInfo=0x7c97b5a0 {LegacyErrorString=PackagePatchFailed, 
> FunctionName=-[MIInstallableBundlePatch applyPatchWithError:] …..  
> SourceFileLine=82}
> 
> CoreSimulatorBridge[1056]: ERROR: MobileInstallationInstallForLaunchServices 
> returned nil
> 
> 
> 
> 


___
use-livecode mailing list
use-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: What is "Open Language"?

[Richmond]

On 26/10/15 12:06, Mark Waddingham wrote:

On 2015-10-24 21:00, Richmond wrote:

Well, what to one person is 'natural language' may not be to another:
and a "10,000 different, often incompatible and sometimes confusing,
custom syntax options" does seem to sum that problem up fairly 
effectively.


Indeed - what is 'natural' to me is different to others. However, 
language is about communication between individuals and groups. Each 
develops their own idea of 'naturality' in that context.


I have to say that what people do in the privacy of their own homes 
and with friends is entirely up to them and generally of little 
interest to me - if they wish to spend a great deal of time developing 
weird and wonderful ways of setting the rect of a button then, you 
know what, they can go 'knock themselves out' and have as much fun as 
they can possibly have with such an endevaour (I certainly won't be 
spending any time doing so).


However, when 'these' people have to interact with others outside of 
such small groups, then they will find that *unless* their new 
approach fits entirely within the constraints of the group they are 
proffering it to and is demonstrably 'better' or gives more benefits 
than the existing one, then they will most likely find limited support.



It is an unreachable ideal for the plain and simple reason that
computers do not work in the
same way as human brains.


Interesting - I must confess I'm not quite up to date with the latest 
frontier research on that subject but certainly last time I did dig 
into it that was still an unanswered question.


If you are absolutely sure about your assertion and have a proof for 
it then I suggest you write up a paper right now and submit it for 
peer review in an appropriate academic journal - you would quickly 
find yourself probably being inline for a sizeable prize or two, and 
international renown (and indeed probably have a whole array of job 
offers at many prestigious academic and research institutions around 
the world).


(Just for the sake of others, I should explain - asserting that 
'computers do not work in the same way as human brains' means that the 
human brain is fundamentally capable of solving a greater set of 
problems than modern computers - i.e. the human brain is not a Turing 
Machine but something more)


No: that is not what is meant. What is meant by the assertion 'computers 
do not work in the same way as human brains' is that computers can only 
work in whole numbers (digitally), while brains work in a quite 
different way. I ma quite sure that computers are capable of solving a 
greater set of problems than human brains in certain fairly clearly 
defined areas, and human brains are far better at solving problems in 
quite different areas.


Stating that the assertion 'computers do not work in the same way as 
human brains' "means that the human brain is fundamentally capable of 
solving a greater set of problems than modern computers - i.e. the human 
brain is not a Turing Machine but something more" is rather like using 
Marxist terminology to define how Market systems work, when there are 
quite different ways of describing them that are equally, or possibly 
more, valid. This is defining the capabilities of the human mind in a 
totally mechanistic framework that ultimately is how computers are defined.


To illustrate this point think about yourself smelling a flower.

A computer smelling a flower would be capable of telling you all the 
component chemicals that make up its aroma, and possibly the DNA 
structure of the flower.


When I smell a flower my interpretation of its smell will be heavily 
affected by the fact that I first smelt a flower of that type at 
Drumbreddan bay


https://www.google.bg/maps/place/Drumbreddan+Bay,+United+Kingdom/@54.7501439,-5.0087908,4792m/data=!3m2!1e3!4b1!4m2!3m1!1s0x486233eae64a548d:0x906d7bbd8f5d9c93?hl=en

And, should you be in the area, well worth a day with a picnic!

in 1977 while lying on the grass on a lovely sunny day in late August, 
having had a swim. It will also be affected by the fact that I had had a 
horrible adolescent set-to with my Mum about 30 minutes earlier.




Of course, whilst intellectually interesting, the reality is that 
computers have gotten pretty darn good (and continue to get better) at 
approximating the outward effects of the human brain in every 
increasing areas; which means whether or not their computational 
models are equivalent or not is really not that relevant on a 
day-to-day basis.


That is also true.

However, I do think we can say, quite safely, "the human brain is not a 
Turing Machine but something else."




Warmest Regards,

Mark.



Richmond.

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

Re: What is "Open Language"?

[Richmond]

On 26/10/15 16:17, Roland Huettmann wrote:

Originally I had thought that "Open Language" means to allow LiveCode to
run other scripting languages within it's framework, for example using
Python, or somehow link such languages into LiveCode.

I started hating "machines" who started "understanding" me and making
assumptions about what I want. Already I hate when at Google confines me to
a certain earthly region and that it became almost impossible or very
difficult to change language. Again I want to become a "free" user of the
Internet. Or at least, there should be a button to switch OFF all
assumption about who I am and what I want.

I would love LiveCode NOT to understand the uncertainty of me. Computers
should not be behave being as ambiguous as we humans are.


That is THE STATEMENT that sums everything up that is odd about the
idea of 'Open Language'.

Why do I also have a funny feeling that all that any attempt at 'Open 
Language'

would do is serve to close the minds of those working with it???

Richmond.

  We love them
because they do what we want them to do, and not the other ways around, and
computer language should not leave much space for interpretation. It
follows a logic, and as long as it does that, it is acceptable. And we love
LiveCode because it allows to express logic in a way which is near to human
language - but will never replace it (I hope at least).

So, I like Monte's suggestion to have an auto-correct feature to help
correcting wrong input and wrong spelling - the correct one being defined
in the dictionary with as few synonyms as possible, but not force us not to
do something wrong. In case of wrong-doing, the compiler should bark at us,
or the application will misbehave - and we have learnt from doing wrong and
may have a chance to correct ourselves.

(The new scripting environment of FileMaker 14 is not so bad in
accomplishing some of this. A good place to take lessons from. As much as I
hated the old scripting environment, the new one has nice edges and really
is supportive...)

The language should grow not in the sense of making things more ambiguous
as they already are, but just advance the capabilities of expression within
limitations. If these limitations would be removed, the river will not find
it's bed to the ocean and spread all over in an uncontrolled way. We would
have big problems understanding each-other, and the effect will be simply
chaotic programming style.

I do not believe that the need for programming will die in 20 years as
someone here stated. Such prognosis was there already 20 years ago that
soon machines will program themselves. At least I do not want it - or only
as much as boundaries can be clearly defined. We could also state that
logic will not be needed in 20 years, or that we all started stop using our
mental capabilities and hand over our brain to the computer.

I do not want the computer to switch on the light in my room when I enter,
and know in advance what I am going to do or think or wish - unless I
completely control its behavior. Thinking further, this leads to quite a
philosophical discussion and touches the base of our human existence and
the notion about who we are.

Think of musical notes. Would Mozart have been able to communicate his
genius without them? Musical notes leave all the space for expression, but
still confine the basic intention into a framework of the limitations of a
language.

Why do we love LiveCode? Or why would students love it? Because it gives
freedom of expression within a set of limitations - using simple English
expressions. How would a Chinese learn all the intricacies of English
vocabulary? He will not. Keep it simple and "stupid" within it's own set,
as musical notes are not that difficult to learn, but using them is quite
an interesting and different matter.

When there is a flow of beauty in such language, people will catch on. But
do not make it to be really English. Let us rather focus on thinking what
such typical user might expect when writing a statement. Will the machine
act accordingly? Or will there be unexpected results? And if there are
unexpected results, there must be "work-rounds", and then things become
ugly.

In this sense I would raise my voice against "Open Language".

But I am all for more and more beauty in LiveCode, and for ever growing
power accomplishing things that we want the machines to do in the most
logical way possible using LiveCode. And I think the "team" is trying to
just accomplish this - step by step. I admire them.

People are not against learning as long as there is a fruit to be
gained.And if we do not challenge our brain with ever growing
sophistication then it will also just die away. )

Roland




Richmond.

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

Re: What is "Open Language"?

[Richmond]

On 26/10/15 16:51, Rick Harrison wrote:

Hi Mark,

Whenever one deprecates code, it destroys someone’s code somewhere.
Don’t do it.

I had a project I had worked on for 10 years of my life.  It encompassed
over 70,000 lines of hard won hand-written code.  One day the company
who was producing the language decided to make some major changes
deprecating much of the language.  There was no migration tool provided
by the company to make the changes painless.

I spent yet another year of my life hand coding the changes to get the code
working again.  Two years later, the company did the same thing yet again!
I couldn’t afford to go through the process yet again.  My code was
basically destroyed by the company by deprecation of the code base.

A work around is to let all previous versions work,


Um: my endless thousands of numToChar statements in my Devawriter Pro 
will have to
be rewritten should I decide to move my code-base from LC 4.5 to LC 7.* 
or higher.


R.


and put the final winning
candidate into the dictionary, the others will no longer appear in the
documentation.  This solves the problem with the least disruption as it
doesn’t break anyone’s code, but helps to streamline the desired future
syntax for the language.

Just my 2 cents for the day.

Cheers,

Rick




  

On Oct 26, 2015, at 5:00 AM, Mark Waddingham  wrote:

So, I do think that in this case it would be far better to *choose* what 
variant spelling is the normative one and deprecate all the other synonyms at 
least until there is a much better mechanism in place for parsing and resolving 
synonyms (i.e. when compound properties are specified as separate words, and 
synonyms are substitutions done as a pre-processing step).

___
use-livecode mailing list
use-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: What is "Open Language"?

[Richmond]

On 26/10/15 19:17, Bob Sneidar wrote:

[FAIR WARNING: BLOVIATION TO FOLLOW]


Wow: never heard of 'Bloviation' before.


Mark Waddingham wrote:


Of course, whilst intellectually interesting, the reality is that
computers have gotten pretty darn good (and continue to get better) at
approximating the outward effects of the human brain in every increasing
areas; which means whether or not their computational models are
equivalent or not is really not that relevant on a day-to-day basis.

I proceed on the assumption you are talking about artificial intelligence. If 
not, read no further.

If by "approximating" you really meant "simulating" I'm right there with you. But if you 
meant something like "approaching functional identity" I couldn't disagree more. I could 
theoretically express a mathematical model of a kitchen table so intricate that it took into account every 
variance in color, density, size, weight etc. and the minor vairances of each aspect in an extremely granular 
three dimensional space. But the mathematical model would never become a table. Maybe I do this using a 
binary model, or perhaps an analog one would be better.

If I could then render the table into some kind of three dimensional image, I 
might be able to produce a very convincing replica of the table, so that you 
could not tell the difference with the naked eye. Just don't try to put 
anything *ON* the table. It's not a table, it is a model of one. A simulation.

I am even less convinced that you can reproduce what we call Rational Thought 
with a computer. It is not really certain what the phenomenon is. I know there 
is a theory that the massive numbers of synapses in the brain are responsible 
for producing self awareness, and eventually rational thought, but if so then I 
cannot regard rational thought itself as anything but an illusion. An accident. 
A byproduct of biological order on an immense almost unimaginable scale.

And if that is what I, devoid of my body am, and you can eventually reproduce me in a 
laboratory, without all the negative aspects attached to the biological creature I call 
"me", well then shoot me off into space and open the hatch, because at that 
point it will be obvious that everything I thought mattered was really only an illusion.

Bob S




Well said, that man; and, not as nearly as pompous had I attempted it :P

Richmond.

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

Re: What is "Open Language"?

[Rick Harrison]

Hi Mark,

I greatly appreciate your response to this topic.

> In terms of syntax / synonym related suggestions - then the situation is much 
> easier. We might deprecate some, just to make it clear what the 'preferred' 
> form is and to discourage further usage. We would never remove them until 
> such a point that we do have a suitable migration tool / method of expressing 
> them which means people can choose to use them, or not, depending on their 
> own personal preference.


It’s good to hear that you folks are willing to provide a migration tool / 
method for bringing older code up to date.

> Indeed, we have tried and do continue to try our very best not to break 
> people's code as the platform evolves…

I’m also glad to hear that the team is mindful of this issue, and weighs those 
concerns heavily.

I understand that computer hardware/software is evolving at a faster rate than 
ever, such that other companies'
changes significantly impact the LiveCode product, such that some past code of 
the LiveCode codebase simply won’t
be able to function anymore in the future.  These are mitigating circumstances 
that are unfortunately beyond our
control.  This impact however should be minimized for users of LiveCode as much 
as possible by the team.

LiveCode has to retain a solid bedrock of code for it to remain a viable 
platform for it’s users to accomplish their work.
A computer language that evolves too fast without taking that into 
consideration can become abandoned by it’s users,
simply because too many changes make it too difficult for users to keep up with 
it.  That is why “Standards Committees”
were brought into existence for the more formal languages. 

We don’t want “Open Language” for LiveCode to suddenly evolve the language  
from “English Like” into “Greek Geek Speak”
that only a few people can understand or work with.  If LiveCode somehow 
evolved into something looking more like
C++, Objective C, or something worse, users would start looking elsewhere for 
some other more “English Like” computer
language.

I realize I’m probably preaching to the choir here.  I’m glad to hear that your 
team is certainly much more concerned
about code changes than the company that totally screwed me, and many other 
users.

Thanks again for your responses, and clarifications.

Rick


> On Oct 26, 2015, at 11:27 AM, Mark Waddingham  wrote:
> 
> On 2015-10-26 15:51, Rick Harrison wrote:
>> Whenever one deprecates code, it destroys someone’s code somewhere.
>> Don’t do it.
> 
> Indeed, we have tried and do continue to try our very best not to break 
> people's code as the platform evolves (even though this is a huge constraint 
> to put on a programming environment which evolved from something born in the 
> late 1980's - it makes the assumption that all decisions taken then and up 
> until were correct then and correct relative to any future consequence and 
> thus have no forward consequences - which is definitely not the case).
> 
> However, I'm not going to commit us to never deprecating things - we do and 
> will continue to do so as needed. Deprecated features will continue to work 
> for as long as it is feasible to do so.
> 
>> A work around is to let all previous versions work, and put the final winning
>> candidate into the dictionary, the others will no longer appear in the
>> documentation.  This solves the problem with the least disruption as it
>> doesn’t break anyone’s code, but helps to streamline the desired future
>> syntax for the language.
> 
> The problem here is that you are assuming it is possible for 'all previous 
> versions to work' from now until some arbitrary point in the future. This 
> just isn't the case - code ages and computer technology continual renews.
> 
> For example, the 'liveResizing' property no longer does anything. Why? 
> Because Cocoa has no facility to turn liveResizing off.
> 
> Similarly, things like the 'pixmapId' properties and such used to allow you 
> to do really funky things on certain platforms which it was not possible to 
> continue to make work when we brought the graphics capabilities up to scratch 
> with other environments in 2.7. (Fortunately, long before these 'funky 
> things' stopped working we provided a much better way to have the same effect 
> - i.e. export/import snapshot from object).
> 
> In terms of syntax / synonym related suggestions - then the situation is much 
> easier. We might deprecate some, just to make it clear what the 'preferred' 
> form is and to discourage further usage. We would never remove them until 
> such a point that we do have a suitable migration tool / method of expressing 
> them which means people can choose to use them, or not, depending on their 
> own personal preference.
> 
> In terms of current functionality (from a semantics point of view) there are 
> a growing list of 'anomalies' in the bug database which are things which 
> really aren't 'correct' at the moment (and never have 

Re: What is "Open Language"?

[Richmond]

On 26/10/15 11:00, Mark Waddingham wrote:

On 2015-10-24 22:47, Mark Wieder wrote:

On 10/24/2015 12:21 PM, Peter TB Brett wrote:


* hilite -> highlight


Actually I filed a bug report on that six years ago.
http://quality.runrev.com/show_bug.cgi?id=8211

It got confirmed and ignored.
I just submitted a pull request.
Figured I might as well fix this myself.


There's a slippery slope here (in terms of the current engine parsing 
implementation at least) which means that just adding synonyms because 
the lack of them 'annoy' a small set of people (and/or because you 
can) really isn't something which makes sense.


It is clear that originally 'hilite' was the chosen spelling for that 
operation - it is an 'informal' spelling of 'highlight' which has been 
historically used in GUI frameworks (probably because it is a good 
deal shorter than 'highlight' - something which those who are fond of 
'grp', 'fld', 'ac, 'cd' etc. should feel at home with ;))


There was obviously clearly some contention over whether 'dehilite' or 
'unhilite' should be the antonym - given that even 'dehighlight' nor 
'unhighlight' tend to appear in dictionaries this is probably not 
surprising.


So, clearly someone 'complained' at some point (which is probably why 
dehilite and unhilite both exist) and 'highlight' was added. Indeed, 
there are actually the following fundamental synonyms for 'hilite' in 
the engine:

  - highlight
  - highlighted
  - highlite
  - highlited
  - hilite
  - hilited

So that is 6 ways to write exactly the same thing. (It gets better in 
a moment)


We now have the following 'compound' property names involving 'hilite':
  - hiliteborder
  - hilitecolor
  - hilitefill
  - hiliteicon
  - hilitepattern
  - hilitepixel

We also have the following 'compound' property names involving 'hilited':
  - hilitedbutton
  - hilitedbuttonid
  - hilitedbuttonname
  - hilitedicon
  - hilitedline
  - hilitedtext

There are also the following 'other' properties:
  - autohilight
  - autohilite
  - linkhilitecolor
  - multiplehilites
  - noncontiguoushilites
  - sharedhilite
  - showhilite
  - threedhilite
  - togglehilites

So, there are (in fact) the following variations on 'hilite' currently 
in use in the engine:

  - hilite
  - highlite
  - hilight
  - highlight

Which, if accounted for in synonyms would mean we would end up with (I 
believe) 72 keywords if we ignore the 'ed' forms, and 144 if we have 
both the preset and past participles. Also, it means that every time 
anyone wants to add a property containing 'hilite', they need to add 4 
(maybe 8) variants. This kind of 'blow-up' suggests that there is 
something wrong with the approach.


So, I do think that in this case it would be far better to *choose* 
what variant spelling is the normative one and deprecate all the other 
synonyms at least until there is a much better mechanism in place for 
parsing and resolving synonyms (i.e. when compound properties are 
specified as separate words, and synonyms are substitutions done as a 
pre-processing step).


For anything like there has to a policy and my policy has always been 
- you choose a single representative for a single concept and you 
stick to it. In this case 'hilite' is a perfectly valid word to use 
(given its domain - i.e. GUIs); indeed, it is just as valid a choice 
for 'highlight' as 'color' is for 'colour' and 'behavior' is for 
'behaviour'. At the end of the day this is a computer language and as 
such logical and sensible choices have to be made. (One could also 
argue that the problem of synonyms and abbreviations is far better 
handled in the script-editing environment... Although nobody ever 
seems to agree with me on that one - even though the resulting effect 
would be identical for all intents and purposes ;)).


Now, I'm not saying this won't change - clearly there is a want for 
synonyms as a fair few people seem quite fond of them. However, there 
needs to be a good mechanism in place to deal with them in the engine 
and there currently is not (particularly when considering compound 
forms) so caution is hugely advisable.


Warmest Regards,

Mark.



+1

As 'hilite' is the de facto standard, whether anyone likes or not, that 
would seem to be the one to stick with.


I feel similarly about all those North Americanisms: speaking as someone 
who was born in Scotland, spent all his school days
in England, and holds a Masters degree (in Linguistics) from a 
University in the States, although instinctively my lip curls at

American spellings, I am well aware that:

1. That is nothing more than my cultural subjectivity.

2. American English IS the dominant form of English in the world right 
now (and probably for the forseeable future).


So "bu**er" [not, that isn't 'butter'] the British spellings and stick 
with the Americanisms . . .


And, quite frankly, if somebody really starts banging on about "British" 
spellings [i.e. English English spellings] I shall get

awfy thrawn anent Scotticisms; 

Re: What is "Open Language"?

[Alex Tweedly]

On 26/10/2015 18:08, Richmond wrote:


2. American English IS the dominant form of English in the world right 
now (and probably for the forseeable future).


H ... true for now, but I wouldn't be surprised if Indian English 
overtook it over the next 2 to 3 decades.


Already the present continuous is becoming common (almost prevalent)  
where we traditionalists would have used the simple present - at least, 
I am thinking it is - and that was largely an influence from the Indian 
sub-continent.


-- Alex.


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