Re: Writing Extensions

[Mark Wieder via use-livecode]

On 05/18/2017 07:14 PM, Alejandro Tejada via use-livecode wrote:

Now that we are talking about widgets and extensions, many thanks again
Mark Wieder for updating Peter Thirkell multicolor svg widget.

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


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




If you have time, Could you compile this same widget for LCB of LC 8.1.3?
I am curious to learn if deploying a widget for both LC8 and LC9 is too
difficult or just requires some simple changes.


Here's a link to the folder for the LC8.1.3 version - no changes to the 
source required, but the Extension Builder popped up a few extraneous 
windows during the process. I just canceled out of them and the widget 
seems to work.




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


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

news about the new Google Play policy

[Alejandro Tejada via use-livecode]

Singularity? Maybe yes, maybe no, but
I am not going to say it was Aliens... :-)
http://images.memes.com/meme/30936.jpg
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: news about the new Google Play policy

[Mark Wieder via use-livecode]

On 05/18/2017 07:46 PM, J. Landman Gay via use-livecode wrote:

Colin, you are an incredibly handy person to know. :) What a stroke of
luck that you were there exactly when the new policy changes were released.


Hmmm. Coincidence? I think not.
Colin seems to be a magnet for these things.
He's like a lightning rod - you can feel the electricity crackle, and 
then Zap! there's just the person you need to talk with or Zap! there's 
an unannounced product release or Zap! there's the singularity...


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

[Kay C Lan via use-livecode]

On Tue, May 16, 2017 at 6:46 PM, Mark Waddingham via use-livecode
 wrote:
>
> I'd at least hope that 'smart cars' software is engineered to a much
> higher standard than other places:
>
Well it may not even be 'smart' cars, even just modern cars may have
problems depending on circumstances. This article also raises an
interesting issue with regard to Uber and/or similar:

https://www.theguardian.com/technology/2015/aug/12/hack-car-brakes-sms-text

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

Re: news about the new Google Play policy

[J. Landman Gay via use-livecode]

Colin, you are an incredibly handy person to know. :) What a stroke of 
luck that you were there exactly when the new policy changes were released.


Thank you.

On 5/18/17 9:39 PM, Colin Holgate via use-livecode wrote:

At Google I/O they have one building which is called Office Hours, and in there 
you can queue up and get to ask Google team members any questions you have. 
Most teams are represented, with an hour for each session.

One of the teams there wasn’t even on the schedule, but I had been pointed to 
them by someone else. The mystery team was the Google Play Policy team. So I 
went and asked some questions.

It’s down to chance who you will get, but I happened to get the person is the 
manager of the team that does app reviews and rejections, so certainly the 
right person to speak to!

I asked about whether downloaded images would be allowed under the new policy, 
he thought that would be no problem, as its static data. Without naming the 
tool, I described how a LiveCode app might download new scripts, and how it 
wasn’t compiled code, but it just wasn’t JavaScript. He seemed think that would 
be ok.

I also asked if it would be possible for LiveCode to get in touch to explain to 
someone on his team what the nature of LiveCode apps is, in the hope that the 
review team would have LiveCode on a list somewhere, as being a tool that would 
be allowed to download scripts after the app was already in the store.

So, if anyone at LiveCode would be interest in getting in touch with Google, to 
give a rough explanation about how scripts might be used, I have the main man’s 
email address. It may well be that he would put you touch with the right person 
on his team, rather than handle it on his own.

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




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


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

news about the new Google Play policy

[Colin Holgate via use-livecode]

At Google I/O they have one building which is called Office Hours, and in there 
you can queue up and get to ask Google team members any questions you have. 
Most teams are represented, with an hour for each session.

One of the teams there wasn’t even on the schedule, but I had been pointed to 
them by someone else. The mystery team was the Google Play Policy team. So I 
went and asked some questions.

It’s down to chance who you will get, but I happened to get the person is the 
manager of the team that does app reviews and rejections, so certainly the 
right person to speak to!

I asked about whether downloaded images would be allowed under the new policy, 
he thought that would be no problem, as its static data. Without naming the 
tool, I described how a LiveCode app might download new scripts, and how it 
wasn’t compiled code, but it just wasn’t JavaScript. He seemed think that would 
be ok.

I also asked if it would be possible for LiveCode to get in touch to explain to 
someone on his team what the nature of LiveCode apps is, in the hope that the 
review team would have LiveCode on a list somewhere, as being a tool that would 
be allowed to download scripts after the app was already in the store.

So, if anyone at LiveCode would be interest in getting in touch with Google, to 
give a rough explanation about how scripts might be used, I have the main man’s 
email address. It may well be that he would put you touch with the right person 
on his team, rather than handle it on his own.

Let me know what you think.
___
use-livecode mailing list
use-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: Seeking recommendations / suggestions for use of library stacks.

[Andre Garzia via use-livecode]

I usually follow Alis approach. I have a separate initialization handler
which I can call repeatedly if needed. The librarystack call just call it
once but if needed I can call it from the messagebox as well.

On the topic of libraries, it is good to follow a "functional programming"
approach where you try not to rely on script local and global variables. If
you library functions need nothing but their own parameters to work on, it
becomes easier to test them and calling them over and over seldon generate
side effects. It is way easier to test (and debug) a function that doesn't
touch anything outside of its own script (as in it processes data and
return data but doesn't cause changes outside itself).



On Tue, May 16, 2017 at 8:34 AM, pink via use-livecode <
use-livecode@lists.runrev.com> wrote:

> what about putting the process into the library stack files themselves?
>
> For example, when I use my CouchDB library I also load fastJSON:
>
> on libraryStack
>  if "couchDBLib" is not among the lines stacksInUse then start using
> stack "couchDBLib"
>  if "fastJSONlib" is not among the lines stacksInUse then start using
> stack "fastJSONlib"
> end libraryStack
>
> on releaseStack
>  if "couchDBLib" is among the lines stacksInUse then stop using stack
> "couchDBLib"
>  if "fastJSONlib" is among the lines stacksInUse then stop using stack
> "fastJSONlib"
> end releaseStack
>
> note that using "is among" and "is not among" is not optional otherwise you
> end up in an infinite loop
>
>
>
> -
> ---
> Greg (pink) Miller
> mad, pink and dangerous to code
> --
> View this message in context: http://runtime-revolution.
> 278305.n4.nabble.com/Seeking-recommendations-suggestions-
> for-use-of-library-stacks-tp4714836p4714910.html
> Sent from the Revolution - User mailing list archive at Nabble.com.
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
http://www.andregarzia.com -- All We Do Is Code.
http://fon.nu -- minimalist url shortening service.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Writing Extensions

[Alejandro Tejada via use-livecode]

Now that we are talking about widgets and extensions, many thanks again
Mark Wieder for updating Peter Thirkell multicolor svg widget.

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

If you have time, Could you compile this same widget for LCB of LC 8.1.3?
I am curious to learn if deploying a widget for both LC8 and LC9 is too
difficult or just requires some simple changes.

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

Re: User friendly functions to replace MySQL queries?

[Andre Garzia via use-livecode]

auhaauhahuuhahauauhahu yes, it has been how long? years? :-P

On Thu, May 18, 2017 at 10:09 PM, Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 05/18/2017 11:41 AM, Andre Garzia via use-livecode wrote:
>
>> Aloha Friends,
>>
>> I have been away for a while...
>>
>
> I believe we have a winner in the understatement of the week contest.
>
> --
>  Mark Wieder
>  ahsoftw...@gmail.com
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
http://www.andregarzia.com -- All We Do Is Code.
http://fon.nu -- minimalist url shortening service.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Writing Extensions

[J. Landman Gay via use-livecode]

On 5/18/17 8:08 PM, Mark Wieder via use-livecode wrote:

"this me" still seems wrong to me. Or at least to this me


I still chuckle about that. But I had the occasion to need it once and 
for the life of me, I couldn't think of a better definition. It fits all 
the syntax parameters. So now I see it as an adorable addition to the 
language.


--
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: User friendly functions to replace MySQL queries?

[Mark Wieder via use-livecode]

On 05/18/2017 11:41 AM, Andre Garzia via use-livecode wrote:

Aloha Friends,

I have been away for a while...


I believe we have a winner in the understatement of the week contest.

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

[Mark Wieder via use-livecode]

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

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





I wouldn't say we have a 'reticence' to make syntax changes but it requires
a great deal more care than in LCB for several reasons:


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


--
 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: browser print?

[Richard Gaskin via use-livecode]

hh wrote:
>> RG wrote:
>> Thanks, but you know how bitmaps are. I'd really like crisp print-res
>> output if I can.
>
> The browser widget isn't rendering at 300 dpi or more ...
> You need something like Adobe Acrobat (which does the HTML2PDF for
> you) for getting web pages as true PDF.
> And simply printing to PDF doesn't mean you get rid of bitmaps.

Depends on the renderer.  And of course elements that are inherently 
bitmaps, like images, can only print at the resolution they have.  But 
modern text is vector, and it's text I'm most interested in for crispness.


Most browsers will render at device resolution, so on screen that's the 
screen resolution but when printing it's much higher.


I believe revBrowser tapped into that browser printing method for that 
command.


It would be nice if the same method were available for the browser widget.

--
 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: browser print?

[hh via use-livecode]

> RG wrote:
> Thanks, but you know how bitmaps are. I'd really like crisp print-res
> output if I can.

The browser widget isn't rendering at 300 dpi or more ...
You need something like Adobe Acrobat (which does the HTML2PDF for you)
for getting web pages as true PDF.
And simply printing to PDF doesn't mean you get rid of bitmaps.

___
use-livecode mailing list
use-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: Snaptshot of Browser Widget in iOS?

[Jonathan Lynch via use-livecode]

There are some JavaScript libraries that can convert an HTML page into an image 
(not just a canvas object) - that could be your backup if all else fails.

Sent from my iPhone

> On May 18, 2017, at 6:26 PM, JOHN PATTEN via use-livecode 
>  wrote:
> 
> Hi All!
> 
> I am trying to lay some objects (text fields, graphics, etc.) over a browser 
> widget. I am essentially just taking a screen capture and then layering the 
> objects on top of the image. Here is my script:
> 
> on mouseUp
> lock screen
> put the rect of current stack into tCoord
> 
> set the width of image 1 to the width of current stack
> set the height of image 1 to the height of current stack
> set the topleft of image 1 to 0,0
> export snapshot from rect tCoord to file specialFolderPath("documents") & 
> "File1.png"
> set the visible of widget "browser" to false
> set the filename of image id 1008 to ""
> wait 2
> set the filename of image id 1008 to SpecialFolderPath("documents") & 
> "File1.png"
> -- I believe i needed the three previous lines to get this to work for some 
> reason???
> show image id 1008 with visual effect dissolve slowly
> unlock screen
> 
> end mouseUp
> 
> 
> This works fine on my Mac, but when I test it in the iOS simulator it does 
> not work. Is it not possible to take a snapshot of the browser widget in iOS?
> 
> Thank you!
> 
> John Patten
> SUSD
> ___
> use-livecode mailing list
> use-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

English Like?

[Alejandro Tejada via use-livecode]

on Thu May 18 2017, William Prothero wrote:

> I think that comments by relative newbies, who don’t have
> the same experience with LC are very important.
> I’ve mentioned several times that some of the tutorials
> and lessons can miss things that the author takes for
> granted. I’m particularly sensitive to this because of
> my long experience teaching college students having
> them use my software.

In my personal experience, most teachers and students
just want that every computer program looks and
behave like Microsoft Word... :-(

> It is very difficult for the developer of the software
> to avoid making assumptions based on experience and
> it takes special attention. One organization I worked
> with did eye-tracking with naive users to validate their
> web applications. I don’t think that’s needed for livecode,
> but more attention to this, when publishing teaching
> documents would be very helpful.

Probably, the answer is HyperText...
In every tutorial or Livecode Lesson, please include hypertext
links or modal pop ups that explain most programming concepts
and LiveCode Script (LCS) keywords. Then, check which
links are most visited and include that information in
other tutorials. This information is really valuable
for creating new tutorials.

> This was a very significant problem with the first course
> on using LC to make apps that came with the iPhone.
> I ended up dropping out because I was wasting so much of
> my time trying to figure out bugs and what should have been
> in the tutorial. These resources may be the first time a
> person really gets into Livecode and the kinds of difficulties
> I encountered could be very off-putting to a new user.

Ideally, every course or lesson should start with a
downloadable stack or executable. In this way, you would
know beforehand if this code will run in your own setup...
for example: All multimedia tutorials are useless in Linux,
because still we could not play sounds or movies.

> Anyway, I encourage the authors of tutorial software
> to pay significant attention to learning resources
> they put out for the public to make sure the learning
> goes smoothly.

An indispensable feature for 21st century tutorials is
the ability for changing content to match users
personal learning's style.

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

Re: browser print?

[Richard Gaskin via use-livecode]

hh wrote:

>> Richard G. wrote:
>> Does the browser widget support printing like the older revBrowser
>> external did?
>
> No. AFAIK it doesn't support "window.print()", had no success here.
>
> But you can use javascript to get the window's content or part of it
> (e.g. container by Id) as a rendered image, not a screenshot, and then
> print via LC Script.

Thanks, but you know how bitmaps are.  I'd really like crisp print-res 
output if I can.


The older revBrowser external might be an option, but alas no Linux with 
that.


Dear dev team: any plans to bring the browser widget into feature parity 
with revBrowser?  In addition to printing there were some other goodies 
like built-in screenshots and text resizing that are very useful.


--
 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: browser print?

[hh via use-livecode]

> Richard G. wrote:
> Does the browser widget support printing like the older revBrowser
> external did?

No. AFAIK it doesn't support "window.print()", had no success here.

But you can use javascript to get the window's content or part of it
(e.g. container by Id) as a rendered image, not a screenshot, and then
print via LC Script.

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

browser print?

[Richard Gaskin via use-livecode]

Does the browser widget support printing like the older revBrowser 
external did?


--
 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: Sort so that "Hello" is always before "hello"

[hh via use-livecode]

Correction, sorry.

> I wrote:
> But because lower(a-zA-Z) is _always_ not equal to upper(a-zA-Z) ...

This handles only one case of casesensitivity. Should read:

If the casesensitive is true then
lower(a-zA-Z) is _always_ not equal to upper(a-zA-Z)

If the casesensitive is false then
lower(a-zA-Z) is _always_ equal to upper(a-zA-Z)

[So this gives no further distinction for sorting.]

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

Snaptshot of Browser Widget in iOS?

[JOHN PATTEN via use-livecode]

Hi All!

I am trying to lay some objects (text fields, graphics, etc.) over a browser 
widget. I am essentially just taking a screen capture and then layering the 
objects on top of the image. Here is my script:

on mouseUp
lock screen
put the rect of current stack into tCoord

set the width of image 1 to the width of current stack
set the height of image 1 to the height of current stack
set the topleft of image 1 to 0,0
export snapshot from rect tCoord to file specialFolderPath("documents") & 
"File1.png"
set the visible of widget "browser" to false
set the filename of image id 1008 to ""
wait 2
set the filename of image id 1008 to SpecialFolderPath("documents") & 
"File1.png"
-- I believe i needed the three previous lines to get this to work for some 
reason???
show image id 1008 with visual effect dissolve slowly
unlock screen

end mouseUp


This works fine on my Mac, but when I test it in the iOS simulator it does not 
work. Is it not possible to take a snapshot of the browser widget in iOS?

Thank you!

John Patten
SUSD
___
use-livecode mailing list
use-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: Sort so that "Hello" is always before "hello"

[hh via use-livecode]

> Richard E.H. wrote:
> ... the possibility of something like
>
>   sort lines of theData by word 1 of each & \
> (lower(char 1 of each) <> upper(char 1 of each))
>
> But I don't think I can use multiple each's like that, can I?

Your approach is to use a sort function, a powerful tool.

The multiple "each" are no problem. "Each" points simply to the current line.
But because lower(a-zA-Z) is _always_ not equal to upper(a-zA-Z) you mean 
probably

set the casesensitive to false -- is default, just to be clear here
sort theData by each & \ 
   ( charToNum(char 1 of each) <> charToNum(lower(char 1 of each)) )

Then you have (each & "false") if char 1 of each is an upper case what comes
in the ascending order before (each & "true").

[But this will be, TMHO, usually a bit slower than multiple sorts].



___
use-livecode mailing list
use-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: Sort so that "Hello" is always before "hello"

[Kaveh Bazargan via use-livecode]

Brilliant, thank you. I have tried to fall out of love with LiveCode but it
is hard!

I used HyperCard since pre-release version ;-)

On 18 May 2017 at 22:28, hh via use-livecode 
wrote:

> You want a sort with co-sort:
>
> set the casesensitive to true -- secondary sort:
> sort myContainer
> set the casesensitive to false -- primary sort:
> sort myContainer
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
Kaveh Bazargan
Director
River Valley Technologies
@kaveh1000
+44 7771 824 111
www.rivervalleytechnologies.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: Sort so that "Hello" is always before "hello"

[Dr. Hawkins via use-livecode]

On Thu, May 18, 2017 at 2:43 PM, hh via use-livecode <
use-livecode@lists.runrev.com> wrote:

> on mouseUp
>   set the casesensitive to true -- secondary sort:
>   sort myContainer
>   set the casesensitive to false -- primary sort:
>   sort myContainer
> on mouseUp
>

Now *that* is clever.

At first I read you as having a slew of containers, which led to the
possibility of something like

sort lines of theData by word 1 of each & (lower(char 1 of each) <>
upper(char 1 of each))


But I don't think I can use multiple each's like that, can I?


-- 
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: Sort so that "Hello" is always before "hello"

[Dr. Hawkins via use-livecode]

On Thu, May 18, 2017 at 2:20 PM, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> What you are wanting to do is a recursive function that sorts within each
> word. If the first character is all you care about, it would be easy
> enought to code, but if *every* character comes into play, the problem
> becomes grossly complex. This isn't a sort problem. It's a filing order
> problem


so

sort the lines of mycontainer by mysort of each


where mysort is a function previously defined.

Or, perhaps more creatively

repeat for each line theLin in theData

put theLin into arry[mysort(theLin)

end repeat

put the keys of arry into srtVals

sort lines of srtVals

repeat for each line theLin in srtVals

put arry[theLin] & cr after newData

end repeat


where mysort() simply rearranges the characters into order AaBb etc.  (so
"A" maps to "a", "a" maps to "b", and so forth, leaving the rest of the
ascii intact.  Or perhaps it could remap the symbols & numbers to
preference, too.   There are something like 95! possible mappings . . .

-- 
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: Sort so that "Hello" is always before "hello"

[hh via use-livecode]

> Kaveh B. wrote:
> I have the following lines when a list of words is sorted: Hello
> hello Hello hello hello so there is no hierarchy between upper and
> lower case chars. I want caps to go first. How do i do that pls? 

Let me explain a bit more.

You want a sort with co-sort. LC allows this because it's sort is stable:

The secondary sort or 'co-sort' has to be done before the sort. It sets the
sort order for the case that chunks in the following primary sort function.

Here are first all upper case chunks sorted before the lower case chunks.
Then, with casesensitive false, LC doesn't change the sort order for
chunks that are equal in the current sort function.

on mouseUp
  set the casesensitive to true -- secondary sort:
  sort myContainer
  set the casesensitive to false -- primary sort:
  sort myContainer
on mouseUp

For example

Hello
hello
hello
hallo
Hallo
Guest
guest
Guest

becomes

Guest
Guest
guest
Hallo
hallo
Hello
hello
hello


___
use-livecode mailing list
use-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: User friendly functions to replace MySQL queries?

[Andre Garzia via use-livecode]

Friends,

I have fixed the page for the library
http://andregarzia.com/en/projects/dblib. I am also using github to track
development now and moved all the data to a repository linked on that page.
The library continues to be dual-licensed, GPL or Commercial, depending on
your needs.

I have just made a new release tagged v1.18 that moves from binary stacks
to plain-text stacks. New features will be added shortly. Previous
customers should be receiving an automated update email from sendowl with a
link.

Cheers
andre

On Thu, May 18, 2017 at 3:41 PM, Andre Garzia  wrote:

> Aloha Friends,
>
> I have been away for a while but I am about to make some cool
> announcements today. I will be releasing some updates in the next few days
> for all libraries including this one. Also re-uploading them to my site.
>
> om om
> andre
>
> On Mon, May 8, 2017 at 1:30 PM, Kaveh Bazargan via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> Sounds great. Yes please Bob...
>>
>> On 8 May 2017 at 16:21, Bob Sneidar via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>>
>> > sqlYoga is awesome. The learning curve is a bit steep at first, but once
>> > you get it, it's great. I wrote functions and a database setup interface
>> > that makes it all fairly transparent to use. I can share if you like.
>> >
>> > Bob S
>> >
>> >
>> > > On May 7, 2017, at 13:55 , Kaveh Bazargan via use-livecode <
>> > use-livecode@lists.runrev.com> wrote:
>> > >
>> > > Hi all
>> > >
>> > > Writing MySQL queries using LiveCode is a bit painful, so I thought of
>> > > writing some higher level functions to produce the queries, a bit like
>> > > these from Ken Ray:
>> > >
>> > > http://www.sonsothunder.com/devres/livecode/tips/data005.htm
>> > >
>> > > But before I start I wonder if anyone else has done these.
>> > >
>> > > I know André Garcia wrote a big package, but his site seems down:
>> > >
>> > > http://www.andregarzia.com/page/revspark
>> > >
>> > > Any pointers please?
>> > >
>> > > --
>> > > Kaveh Bazargan
>> > > Director
>> > > River Valley Technologies
>> > > @kaveh1000
>> > > +44 7771 824 111
>> > > www.rivervalleytechnologies.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
>> >
>>
>>
>>
>> --
>> Kaveh Bazargan
>> Director
>> River Valley Technologies
>> @kaveh1000
>> +44 7771 824 111
>> www.rivervalleytechnologies.com
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
>
>
> --
> http://www.andregarzia.com -- All We Do Is Code.
> http://fon.nu -- minimalist url shortening service.
>



-- 
http://www.andregarzia.com -- All We Do Is Code.
http://fon.nu -- minimalist url shortening service.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Sort so that "Hello" is always before "hello"

[hh via use-livecode]

You want a sort with co-sort:

set the casesensitive to true -- secondary sort:
sort myContainer
set the casesensitive to false -- primary sort:
sort myContainer 

___
use-livecode mailing list
use-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: Sort so that "Hello" is always before "hello"

[Bob Sneidar via use-livecode]

What you are wanting to do is a recursive function that sorts within each word. 
If the first character is all you care about, it would be easy enought to code, 
but if *every* character comes into play, the problem becomes grossly complex. 
This isn't a sort problem. It's a filing order problem. 

Bob S


> On May 18, 2017, at 14:15 , Bob Sneidar  wrote:
> 
> Then that is not a sort! 
> 
> Bob S
> 
> 
>> On May 18, 2017, at 14:13 , Kaveh Bazargan via use-livecode 
>>  wrote:
>> 
>> Thanks Phil
>> 
>> That works in the case I mentioned, but with different letters, All upper
>> case chars come to top, so I get:
>> 
>> Goodbye
>> Hello
>> goodbye
>> hello
>> 
>> What I need is
>> 
>> Goodbye
>> goodbye
>> Hello
>> hello
>> 
>> 
>> On 18 May 2017 at 18:19, Phil Davis via 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: Sort so that "Hello" is always before "hello"

[Bob Sneidar via use-livecode]

Then that is not a sort! 

Bob S


> On May 18, 2017, at 14:13 , Kaveh Bazargan via use-livecode 
>  wrote:
> 
> Thanks Phil
> 
> That works in the case I mentioned, but with different letters, All upper
> case chars come to top, so I get:
> 
> Goodbye
> Hello
> goodbye
> hello
> 
> What I need is
> 
> Goodbye
> goodbye
> Hello
> hello
> 
> 
> On 18 May 2017 at 18:19, Phil Davis via 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: Sort so that "Hello" is always before "hello"

[Kaveh Bazargan via use-livecode]

Thanks Phil

That works in the case I mentioned, but with different letters, All upper
case chars come to top, so I get:

Goodbye
Hello
goodbye
hello

What I need is

Goodbye
goodbye
Hello
hello


On 18 May 2017 at 18:19, Phil Davis via use-livecode <
use-livecode@lists.runrev.com> wrote:

> "set the caseSensitive to true" before sorting.
>
> Phil Davis
>
>
>
> On 5/18/17 10:10 AM, Kaveh Bazargan via use-livecode wrote:
>
>> I have the following lines when a list of words is sorted:
>>
>> Hello
>> hello
>> Hello
>> hello
>> hello
>>
>> so there is no hierarchy between upper and lower case chars. I want caps
>> to
>> go first. How do i do that pls?
>>
>>
> --
> Phil Davis
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
Kaveh Bazargan
Director
River Valley Technologies
@kaveh1000
+44 7771 824 111
www.rivervalleytechnologies.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: Sort so that "Hello" is always before "hello"

[Bob Sneidar via use-livecode]

Oh right. I forgot about that. Still, I like my way better. ;-)

Bob S


> On May 18, 2017, at 13:30 , dunbarx via use-livecode 
>  wrote:
> 
> The "caseSensitive" is a global property. It can be set like any other. if
> you do so before the "sort" command, the capital first letters precede the
> lower case.
> 
> Craig


___
use-livecode mailing list
use-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: Sort so that "Hello" is always before "hello"

[dunbarx via use-livecode]

The "caseSensitive" is a global property. It can be set like any other. if
you do so before the "sort" command, the capital first letters precede the
lower case.

Craig



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Sort-so-that-Hello-is-always-before-hello-tp4714983p4714992.html
Sent from the Revolution - User mailing list archive at Nabble.com.

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

Re: Writing Extensions

[Bob Sneidar via use-livecode]

On the other hand, the bad thing about Linux is that there are so many to 
choose from...

Bob S


> On May 18, 2017, at 13:08 , Mark Wieder via use-livecode 
>  wrote:
> 
> Heh. The nice thing about linux is there are so many to choose from...
> 
> -- 
> 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: Writing Extensions

[Mark Wieder via use-livecode]

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

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

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


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

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


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



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


Cool. That sounds promising.




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


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


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


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




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


Heh. The nice thing about linux is there are so many to choose from...

--
 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: User friendly functions to replace MySQL queries?

[Andre Garzia via use-livecode]

Aloha Friends,

I have been away for a while but I am about to make some cool announcements
today. I will be releasing some updates in the next few days for all
libraries including this one. Also re-uploading them to my site.

om om
andre

On Mon, May 8, 2017 at 1:30 PM, Kaveh Bazargan via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Sounds great. Yes please Bob...
>
> On 8 May 2017 at 16:21, Bob Sneidar via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > sqlYoga is awesome. The learning curve is a bit steep at first, but once
> > you get it, it's great. I wrote functions and a database setup interface
> > that makes it all fairly transparent to use. I can share if you like.
> >
> > Bob S
> >
> >
> > > On May 7, 2017, at 13:55 , Kaveh Bazargan via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> > >
> > > Hi all
> > >
> > > Writing MySQL queries using LiveCode is a bit painful, so I thought of
> > > writing some higher level functions to produce the queries, a bit like
> > > these from Ken Ray:
> > >
> > > http://www.sonsothunder.com/devres/livecode/tips/data005.htm
> > >
> > > But before I start I wonder if anyone else has done these.
> > >
> > > I know André Garcia wrote a big package, but his site seems down:
> > >
> > > http://www.andregarzia.com/page/revspark
> > >
> > > Any pointers please?
> > >
> > > --
> > > Kaveh Bazargan
> > > Director
> > > River Valley Technologies
> > > @kaveh1000
> > > +44 7771 824 111
> > > www.rivervalleytechnologies.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
> >
>
>
>
> --
> Kaveh Bazargan
> Director
> River Valley Technologies
> @kaveh1000
> +44 7771 824 111
> www.rivervalleytechnologies.com
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
http://www.andregarzia.com -- All We Do Is Code.
http://fon.nu -- minimalist url shortening service.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Sort so that "Hello" is always before "hello"

[Bob Sneidar via use-livecode]

doesn't look like there is a command to do this. Try creating an sqLite 
database in memory (or on disk it doesn't matter) called tempdata with a column 
called textdata, adding your words/items/lines to the database, then query the 
database with select textdata from template order by textdata. 

You could create this as a function passing the arguments pText, pChunkType, 
pOrder. pText contains your text to be sorted, pChunkType could be lines, items 
or words, and pOrder would be ascending or descending. 

Presto! Your own case sensitive sort function! 

Bob S




> On May 18, 2017, at 10:10 , Kaveh Bazargan via use-livecode 
>  wrote:
> 
> I have the following lines when a list of words is sorted:
> 
> Hello
> hello
> Hello
> hello
> hello
> 
> so there is no hierarchy between upper and lower case chars. I want caps to
> go first. How do i do that pls?
> 
> -- 
> Kaveh Bazargan
> Director
> River Valley Technologies
> @kaveh1000
> +44 7771 824 111
> www.rivervalleytechnologies.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: Writing Extensions

[Mark Waddingham via use-livecode]

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

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


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


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


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


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


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


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


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


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


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



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


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


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


Warmest Regards,

Mark.

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

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

Re: Writing Extensions

[Mark Waddingham via use-livecode]

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

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


Yes.


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


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



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


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



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


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

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

described by a regular expression.


See above (itemdelimiter).


See above (strengths of LCS vs LCB) :)

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


Warmest Regards,

Mark.

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

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

Re: English Like?

[William Prothero via use-livecode]

Richard:
Thanks for the kind words. I think that comments by relative newbies, who don’t 
have the same experience with LC are very important. I’ve mentioned several 
times that some of the tutorials and lessons can miss things that the author 
takes for granted. I’m particularly sensitive to this because of my long 
experience teaching college students having them use my software. 

It is very difficult for the developer of the software to avoid making 
assumptions based on experience and it takes special attention. One 
organization I worked with did eye-tracking with naive users to validate their 
web applications. I don’t think that’s needed for livecode, but more attention 
to this, when publishing teaching documents would be very helpful. 

This was a very significant problem with the first course on using LC to make 
apps that came with the iPhone. I ended up dropping out because I was wasting 
so much of my time trying to figure out bugs and what should have been in the 
tutorial. These resources may be the first time a person really gets into 
Livecode and the kinds of difficulties I encountered could be very off-putting 
to a new user.

Anyway, I encourage the authors of tutorial software to pay significant 
attention to learning resources they put out for the public to make sure the 
learning goes smoothly.

Best,
Bill


> 
> But posts like yours are VERY helpful for those of us who teach newcomers.  
> When we've learned these things too long ago it's easy to forget they were 
> ever unintuitive at first, which may miss opportunities for more effective 
> on-boarding.
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: Sort so that "Hello" is always before "hello"

[Phil Davis via use-livecode]

"set the caseSensitive to true" before sorting.

Phil Davis



On 5/18/17 10:10 AM, Kaveh Bazargan via use-livecode wrote:

I have the following lines when a list of words is sorted:

Hello
hello
Hello
hello
hello

so there is no hierarchy between upper and lower case chars. I want caps to
go first. How do i do that pls?



--
Phil Davis


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

Sort so that "Hello" is always before "hello"

[Kaveh Bazargan via use-livecode]

I have the following lines when a list of words is sorted:

Hello
hello
Hello
hello
hello

so there is no hierarchy between upper and lower case chars. I want caps to
go first. How do i do that pls?

-- 
Kaveh Bazargan
Director
River Valley Technologies
@kaveh1000
+44 7771 824 111
www.rivervalleytechnologies.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: Writing Extensions

[Mark Wieder via use-livecode]

It's not necessary to do any C++ (or any other language) coding to work 
with LCB.


One of the reasons for LCB's existence is to allow the language to be 
extended into linking with parts of the operating system where it can't 
currently reach, and in that sense knowledge of how to interact with the 
C++ or java or whatever libraries is essential. And much of LCB (strong 
variable typing, pointers, etc) exists for that purpose. And is 
necessary for those tasks.


But creating and working with extensions is (should be) otherwise almost 
like working in the familiar LCS environment. If you are creating a 
custom control you don't need any C++ ('canvas' isn't a C++ term, by the 
way) to do so.


My current struggles in dealing with the LCB are mainly in those areas 
where the LCS and LCB differ and the current documentation is not 
adequate to cover the differences.


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

[Mark Wieder via use-livecode]

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

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


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


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


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

[Mark Wieder via use-livecode]

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


You can define constants using:

   constant X is Y

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


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

constant quote is "\q"  ?

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



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


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

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


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





The pointer type isn't documented.


Well it is listed in the language reference ;)


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




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

For example, line and item chunks are actually an incarnation of what
you might call a 'delimited chunk' - they have identical semantics, apart
from where the delimiter to use is fetched from (the *delimiter property
in local context).

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


See above (itemdelimiter).

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

[Colin Holgate via use-livecode]

The policy does tell you that if an existing app is not allowed you have 30 
days to submit an update. So, a little slower that ASAP.


> On May 18, 2017, at 7:51 AM, Bob Sneidar via use-livecode 
>  wrote:
> 
> Dam! I was almost ready to deploy my new iOS app, Jerky 2.0! 
> 
> Bob S
> 
> 
>> On May 17, 2017, at 16:08 , Richard Gaskin via use-livecode 
>>  wrote:
>> 
>> Of course any app that violates any of the other policies outlined on that 
>> page will be dumped ASAP, regardless of how they handle updates. So folks, 
>> don't write jerk apps and let's keep things safe and user-friendly.
>> 
>> -- 
>> Richard Gaskin
> 


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

Re: Android policy update

[Bob Sneidar via use-livecode]

Dam! I was almost ready to deploy my new iOS app, Jerky 2.0! 

Bob S


> On May 17, 2017, at 16:08 , Richard Gaskin via use-livecode 
>  wrote:
> 
> Of course any app that violates any of the other policies outlined on that 
> page will be dumped ASAP, regardless of how they handle updates. So folks, 
> don't write jerk apps and let's keep things safe and user-friendly.
> 
> -- 
> Richard Gaskin


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

Re: Writing Extensions

[Roland Huettmann via use-livecode]

I am following this discussion about extensions with great interest.

Still, partially it goes over my head and as a simple LCS scripter, I
sometimes feel a bit lost.

As I read from different beginners sources, the best is always to know C
and C++ as the "mothers" of languages to then being able to appreciate and
understand higher level languages much better. But unfortunately, I do not
have the time to spend the next 12 months in going deeply into C/C++.

The examples and lessons for LCB provided so far from different sources are
possible to follow, but we "normal" LCS users not knowing other languages
lack the deeper understanding to be able to use such LCB tool without a lot
of explanation and a lot of examples.

And such explanation and examples should be based on the notion that all a
typical user knows is a medium level knowledge of LCS and nothing much more.

Sometimes it is good to just assume a user who is a complete newbie. Coming
also from the field of advertising, I was always told to text in such a way
that my grandmother will understand it, or a 12-year-old schoolmate. If
they understand then everyone will understand.

I hope that there is somebody who is willing to spend the time unfolding
the potential of LCB to the "rest of us" since who would not like to work
with more sophisticated widgets or execute them in a fraction of time and
at least be able to twist things the way we want?

Or what do I have to learn to actually using LCB based on a fractional and
medium level of understanding -- enough for LCS, but not enough for more.

For a newbie, it is already difficult understanding what a "canvas" is
since that term is not used in LCS. And there is more to learn.

And I would appreciate --- I am not knowledgeable myself enough to do this,
otherwise I would -- if there would be an easy to read article on how all
this fits together, how LCS and LCB work, what a parser actually is, what
it means to compile, what is done using C++ behind the curtain, and how the
computer / the processor would understand our instructions given in
near-English LCS language. And then -- especially following examples and
working with them -- some knowledge will dawn. All this could be done in
the context of LCS, LCB, and even C++ as the source of all.

Maybe, really, I should start learning C++ now.)

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

HTML5 deployment: progress comes into sight

[hh via use-livecode]

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

> > Mark Waddingham wrote on May 18, 2017:
> > What are the consequences of that [team] change for the HTML5 deployment?
> > There was no progress with that for half a year. Is it now 'stopped'?
> 
> No - it never stopped. Admittedly the last *feature* to be added to the
> HTML5 engine was 'do as javascript' (which is actually a feature which
> enables anyone who knows javascript to get the HTML5 engine to do a 
> whole
> lot), but remember that the HTML5 engine is just another platform like
> any other, so work on the platform as a whole benefits HTML5 too.
> 
> That being said, recently we are a hair's breadth away from getting
> widgets working in HTML5 (hopefully running a little quicker than they
> did before too):
> 
>  https://github.com/livecode/livecode/pull/5428
> 
> (Yes, the name of the PR sounds unrelated to HTML5, but the purpose of
> doing what it said was to get widgets working *in* HTML5 - but it has
> a couple of other fringe benefits as well - a slight performance bump
> for LCB execution in general)
> 
> We've also been looking at how to abstract the FFI work we've done as
> part of the Infinite LiveCode campaign to allow LCB to bind to 
> JavaScript
> APIs (which will allow greater type fidelity than is possible using
> 'do as javascript' from LCS).

That sounds so great, not only all HTML5-license owners look forward to
these improvements.
Especially a javascript FFI would allow to 'connect' the HTML5 canvas
element and the LC Builder canvas object.

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

Re: Writing Extensions

[Mark Waddingham via use-livecode]

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

LCB bug reports by me only:

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

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

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


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


Thanks for the list, though :)

Warmest Regards,

Mark.

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

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

Re: Writing Extensions

[hh via use-livecode]

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

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

LCB bug reports by me only:

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

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

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


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

Re: Android policy update

[Mark Waddingham via use-livecode]

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

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

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


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

in my previous post.

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

are.

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


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

speaking?

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

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

app store.

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

Warmest Regards,

Mark.

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

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

Re: Android policy update

[Colin Holgate via use-livecode]

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

Also, does Google’s policy suggest that you can’t even update an image in the 
app?
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Writing Extensions

[Mark Waddingham via use-livecode]

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

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

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


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


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


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

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


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

Warmest Regards,

Mark.

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

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

Re: Writing Extensions

[Mark Waddingham via use-livecode]

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

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

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


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

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

produce files what work in that major version.

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

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

V+1.

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

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

Warmest Regards,

Mark.

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

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

Re: LC core team

[Mark Waddingham via use-livecode]

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

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


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


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


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

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

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

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

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

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

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

Warmest Regards,

Mark.

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

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

Re: Android policy update

[Colin Holgate via use-livecode]

I haven’t been following this topic, but I happen to be at Google I/O. If there 
are any short questions I could ask while I’m here I could ask around.

One thing I’m going to go to this morning involves Google Play policies.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Writing Extensions

[hh via use-livecode]

> hh wrote:
>> But I wait for my next examples until there is a stable
>> widget format (we have meanwhile three formats that work on
>> some LC versions only, not on the others).
> Mark Waddingham wrote:
> Unfortunately we aren't going to be guaranteeing binary-level 
> compatibility of the LCB module format for quite some time - it will 
> likely change in every major version for quite a while yet.

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

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

> hh wrote:
>>> To adjust these costs too much time, simply recompiling 
>>> worked here only in 1 of 20 cases.
> 
> Mark Waddingham wrote:
> Can you elaborate by 'recompiling only worked here in 1 of 20 cases'?
> 
> There's probably something we can do here. Currently widget source code
> is included in the extension when built using the extension builder (this
> will always be true of the community edition, and when we have our
> 'extensions store/sharing portal', it will be one way we can ensure people
> aren't doing anything nefarious (any widget which is to be accessible from
> community will require the source is in the extension, and also that the
> compiled module in the extension matches the included source). So, we
> could actually tweak things so that we generate the module file at
> extension installation time.

There are "public, non-LC-staff" lcb files on github (by TrevorDeVore)
or here (forum/LC Builder/Community widgets):
http://forums.livecode.com/viewtopic.php?f=93&t=28020

Feel free to take one as demo for what is not running in new LC versions.
The one connected most to the bug-triage link above is #42 ("SVG-Text"),
downloadable via livecodeshare or "Sample Stacks".


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

LC core team

[hh via use-livecode]

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

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

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

Re: Writing Extensions

[Ali Lloyd via use-livecode]

Thanks Mark, those comments on the docs are really helpful! I've filed bugs
for the core language features, the fixed width font in the extension
builder, script object docs and misleading CamelCase naming.

On Thu, May 18, 2017 at 8:59 AM Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2017-05-17 23:43, Mark Wieder via use-livecode wrote:
> > Yes. In fact it's the areas where they differ that make for a
> > difficult learning curve. There are features in LCB that I wish were
> > backported to LCS. I appreciate the team's reticence to make syntax
> > changes to the core xtalk language, but even as a long-time C
> > programmer,
> >
> > put tHexNumber converted from base 16 into tDecimalNumber
> >
> > seems so much more readable than
> >
> > put format("%02x", tHexNumber) into tDecimalNumber
>
> I wouldn't say we have a 'reticence' to make syntax changes but it
> requires
> a great deal more care than in LCB for several reasons:
>
> - The current implementation of LCS has no notion of versioning for
> its
>   syntax or semantics - so every change to syntax / addition has to
> be done
>   in a way which will not break user scripts.
>
> - All the syntax in the engine is done using hand-coded parsing - it
> is very
>   easy to introduce unintended ambiguities and syntactic forms which
> we did
>   not intend.
>
> - It is quite labour intensive to add / change syntax which means
> experimenting
>   with it (which you need to do to get it 'just right') is hugely
> costly.
>
> In contrast, all of LCB's syntax (beyond the core control structures and
> definiton
> structures) is defined in LCB itself, and binds direct to handlers which
> implement
> that syntax (in contrast, in LCS, you have to write C++ code both to
> parse a piece
> of syntax, and to dispatch it to the implementation). For example, the
> syntax you
> mention above is defined like this:
>
> syntax BaseConvert is left binary operator with conversion precedence
>   "converted" "from" "base" 
> "to" "base" 
> begin
>  MCMathEvalConvertBase(Operand, Source, Target, output)
> end syntax
>
> With 'MCMathEvalConvertBase' being a (foreign) handler implemented in
> C++ which performs
> the action of the syntax.
>
> The main limitation with LCB's syntax right now is that it has to be
> compiled into
> a parser spec ahead of time - i.e. at creation of the lc-compile tool -
> but even with
> that restriction, 'playing' with syntax is possible by just a tweak to a
> code file and a click of
> a button (albeit in a native code IDE), rather than spending many hours
> hand modifying
> some rather old (and in some places very complex) C++ code.
>
> Of course, one valid retort here would be - then why don't you just make
> it easier to
> do this by changing how the engine works in this regard? And the simple
> answer is that
> we are - in order to do that we need an architecture and method of doing
> so, and LCB is
> that architecture.
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Writing Extensions

[Mark Waddingham via use-livecode]

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

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

put tHexNumber converted from base 16 into tDecimalNumber

seems so much more readable than

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


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

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

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

 in a way which will not break user scripts.

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

 not intend.

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


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

mention above is defined like this:

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

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

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

the action of the syntax.

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

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

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

that architecture.

Warmest Regards,

Mark.

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

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

Re: Writing Extensions

[Mark Waddingham via use-livecode]

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

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


You can define constants using:

   constant X is Y

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


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


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

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


The pointer type isn't documented.


Well it is listed in the language reference ;)


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


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

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


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


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

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

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

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

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


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


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

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

then that's also true of the language itself.

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

how to use it!

Warmest Regards,

Mark

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

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

Re: Writing Extensions

[Mark Waddingham via use-livecode]

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

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


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



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


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

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


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


Warmest Regards,

Mark.

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

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

Re: Writing Extensions

[Mark Waddingham via use-livecode]

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

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


That works fine for batch processing type scenarios, certainly.

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


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

Warmest Regards,

Mark.

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

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