Re: Us and them? [was Re: Livecode Dictionary]

[Curry Kenworthy via use-livecode]

Richard:

> Curry Kenworthy wrote:
>> What people need most in the Script Editor is to view and edit the
>> code itself smoothly, without jitters or delays

> Not hard to make one.  A frontScript trapping the editScript message
> lets you do whatever you want.

It's interesting when we take a comment out of context and spin it in 
another direction by treating it as a different request or problem! :)


Neither this thread nor my own message was primarily about the SE. 
Feedback (including my own) was requested on a plan for a project wiki 
... located where? Yep, you guessed it - in the LiveCode Script Editor.


My feedback was to keep any addition simple and watch performance, 
because there are some issues and (as you quoted me) the primary feature 
of Script Editor is code editing; that is its priority.


The wiki sounds like a neat project. Simplicity helps, and whether to 
locate it in the SE is a consideration. Besides performance, another 
issue is that the original proposal here was adding user comments back 
to the Dictionary.


A project wiki would fit in the SE better than it would the Dictionary, 
of course, it would have more features and I could see that being a tab. 
But then again user keyword comments would fit the Dictionary very well, 
they could simply be added there. Having a separate LC window for a 
project wiki is another approach. I would say the tab would be handier 
and more integrated into workflow, but the separate window might be good 
for performance and memory.


I mentioned the SE relative to its inclusion in the wiki plan, so just 
clarifying (ahem) that SE alternatives aren't directly related to or a 
response to my own quoted comment. Ah, the wonders of context!


Nice thoughts though. Some people like to downplay IDE issues, perhaps 
in order to focus all possible resources on certain engine issues. 
That's fine, as are alternatives, but personally I like to see LC 
looking good out of the box too, so I believe both are important and I 
prefer to use and help improve the official SE. Many things I like about 
the SE. (A good, but different, topic!) Thanks Richard.


Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.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: Us and them? [was Re: Livecode Dictionary]

[Bob Sneidar via use-livecode]

+1 for Sublime. I do not code in it much, but there are plugins like for 
comparing two scripts to see differences. If I ever get around to converting my 
main app to Levure, I would probably use it more. 

Bob S


> On Jan 23, 2019, at 10:52 , Trevor DeVore via use-livecode 
>  wrote:
> 
> On Wed, Jan 23, 2019 at 12:39 PM Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> 
>> And then there are the countless third-party text editors, some of which
>> have LC-specific add-ons crafted by our community for them, like
>> Trevor's plugin for Atom.  I've been using Atom enough in web
>> development that I'm considering using it with LC.  It's very nice.
>> 
> 
> The Atom plugin was written by somebody else. I think it was Peter Brett. I
> maintain the plugin for Sublime Text.
> 
> -- 
> Trevor DeVore
> CTO - ScreenSteps
> www.screensteps.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: Us and them? [was Re: Livecode Dictionary]

[Richard Gaskin via use-livecode]

Trevor DeVore wrote:

> On Wed, Jan 23, 2019 at 12:39 PM Richard Gaskin wrote:
>>
>> And then there are the countless third-party text editors, some of
>> which have LC-specific add-ons crafted by our community for them,
>> like Trevor's plugin for Atom.  I've been using Atom enough in web
>> development that I'm considering using it with LC.  It's very nice.
>
> The Atom plugin was written by somebody else. I think it was Peter
> Brett. I maintain the plugin for Sublime Text.

Ah, thanks Trevor.  With Sublime, one more option is available to let LC 
cater to every taste.


--
 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: Thoughts on Livecode Server

[Richard Gaskin via use-livecode]

David Bovill wrote:

> Does anyone have any thoughts on where Livecode server should go / is
> going?

So far it goes wherever I take it, so I haven't given much thought 
beyond one enhancement request for init optimization (useful for CGI, 
will make no difference for any use as a persistent process):

https://quality.livecode.com/show_bug.cgi?id=14115


> *Full power of Livecode?*
> My first question is what are the actual limits of what you can do on
> the server, as compared with the desktop version? I haven't pushed
> this to the limit so maybe yo have?

LC Server is designed to run under CGI.  As with any other CGI, anything 
you can do in launch-run-reply-quit command-line scenario will work 
whether it's local or on a server.



> For instance if I want to integrate Javascript / node.js code into my
> server, can I use the built in two way communication between
> Javascript and Livecode?

I haven't used LC Server for persistent processes, only CGI. I have used 
standalones for that, however (run with the -ui flag).


Pierre Sahores has done extensive benchmarking on using LC behind a 
reverse proxy (NGineX IIRC?), and I did some tests in a related thread 
using standalones as HTTP daemons directly.


I don't have enough familiarity with Node.js configuration to have an 
opinion about integrating with that specifically, but Pierre might. 
Most folks seem content with CGI use.



> This also leads on to the more general question about the headless
> Livecode environment of the server - are then any limits to script
> that does stuff like create a stack, add a browser element to the
> stack

A browser is a GUI element.  What would its role be in the server 
environment?


If you need to make HTTP requests you can do that far more efficiently 
directly in LC, without encumbering it with an entire separate complex 
browser app embedded in a GUI widget.



> set behaviors

Common features like frontscripts, backscripts, libraries, and behaviors 
all work whether running GUI or CLUI.



> communicate with the newly created stack

In the same process, as easy as with GUI.  Across processes with sockets 
or pipes, or polling in /run/shm/ or other useful location.



> (and hence Javascript

Node-specific stuff is outside my current experience, but given that LC 
supports the most commonly used forms of IPC I can't imagine it couldn't 
be integrated in one way or another.



> destroy the stack and return a result to the browser?

As CGI no need to destroy anything, since everything in the process goes 
away after the reply is delivered to Apache or whatever else calls it.



> I'll be testing this soon, but are there limits to this approach
> (apart form speed)?

Speed is a concern in CGI environments, where the entire runtime life 
cycle from launch to quit happens with each request; each request spawns 
a new process, so every millisecond counts.


CGI keeps things discrete and easy to work with (which is how we got the 
"C" in "CGI" ), but lazy or complex programming on a sufficiently 
buzy server can create bottlenecks with CPU time and/or RAM.


But that's not an LC thang, that's just how CGI works. Comparing some 
custom scripts to popular frameworks like Drupal shows LC is quite lean 
and performant by comparison (averaging 1/3 CPU time and 1/5 RAM across 
the few scenarios I've benchmarked).


It's an unfair comparison, given the scope of what Drupal does, but was 
enough to encourage me to continue pursuing custom solutions in LC, as I 
can write things from scratch more quickly in LC than I can figure out 
how to move from Drupal 7 to Drupal 8. ;)


Many get hung up on the "But does it scale?" question, but Guy Kawasaki 
and others remind us how many startups fail because they overspent on 
scaling for a market they never grew into because they'd spent all their 
money prematurely on scaling. :)


Look at the number of even reasonably popular sites running through 
Wordpress/PHP on a shared host.  Scaling is overrated for many projects 
that don't have significant marketing budgets to warrant accommodating 
such traffic loads.



> *Emscripten export?*
> How about using the exported javascript in the server? Could we have a
> node.js based server which server-side uses the big fat Livecode
> javascript engine, and exported Livecode HTML5 exported stacks as
> server side code?

The main benefit of the HTML export is to provide a GUI for browser 
clients.  I can't think of any advantage in using an interpreted version 
of the engine on a server when a machine-code-compiled version is available.



> *Livecode Docker behind reverse proxy*
> This is sort of the default I would say in moving on from Nginx or
> Apache based hosting of Livecode server. Does anyone have any plans /
> experience of doing this?

I don't have the URLs handy at the moment, but Pierre's benchmarks 
posted here a couple years ago were easy enough to find last time I 
searched for them.  He doesn't post here often, so anything 

Re: Us and them? [was Re: Livecode Dictionary]

[Trevor DeVore via use-livecode]

On Wed, Jan 23, 2019 at 12:39 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> And then there are the countless third-party text editors, some of which
> have LC-specific add-ons crafted by our community for them, like
> Trevor's plugin for Atom.  I've been using Atom enough in web
> development that I'm considering using it with LC.  It's very nice.
>

The Atom plugin was written by somebody else. I think it was Peter Brett. I
maintain the plugin for Sublime Text.

-- 
Trevor DeVore
CTO - ScreenSteps
www.screensteps.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: Us and them? [was Re: Livecode Dictionary]

[Richard Gaskin via use-livecode]

Curry Kenworthy wrote:

> What people need most in the Script Editor is to view and edit the
> code itself smoothly, without jitters or delays

Not hard to make one.  A frontScript trapping the editScript message 
lets you do whatever you want.


You can make a stack with a field and a Save button for the simplest 
form as a starting point.


Or clone MC IDE's SE as a starting point.

I used to maintain my own SE for many years, until the big Waddingham 
overhaul that became the foundation for what we use now.  I'm happy 
enough with the current SE that I stopped work on custom ones, but 
they're not hard to make for basic editing; the tough part is adding 
features without impairing performance, a valuable exercise.


And then there are the countless third-party text editors, some of which 
have LC-specific add-ons crafted by our community for them, like 
Trevor's plugin for Atom.  I've been using Atom enough in web 
development that I'm considering using it with LC.  It's very nice.


And of course LC's SE is fully open.  Anyone can fork it, improve it, 
share it with anyone, and even submit the improvements back to the core 
team for inclusion in the master build.


So many solutions so widely available

--
 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: Displaying or identifying emoji

[David V Glasgow via use-livecode]

> On 23 Jan 2019, at 2:15 pm, Stephen MacLean via use-livecode 
>  wrote:
> 
> You say you are importing them? From where? A text file or DB?

Basically, Stephen, I take what I am given.  

Could be plain text, Word, HTML , even spreadsheetn- and often I don’t know any 
intermediate steps between the original chat record (on whatever device and in 
whatever software was involved), and the final format I receive.  Usually I get 
a digital record, but the last one I received was a scan of a fax of a Word 
document.

I was hoping for easy way to back translate, gobbledegook to emoji ID/code, but 
it looks like maybe there isn’t one.  

Thanks to all who chipped in.

Cheers,

David Glasgow



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

Re: global is empty

[JJS via use-livecode]

i had to put the global behind global. i was a mistake i looked over. so 
no bug.


Op 23-1-2019 om 04:51 schreef Tom Glod via use-livecode:

has this been resolved?

when you moved the global declaration to the top it worked?

I keep an eye on reports like this because they are the most
worrisome kinds of things.

But I always trust that the programmer will find the error in their ways.



On Mon, Jan 21, 2019 at 5:44 PM J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:


On 1/21/19 12:06 PM, JJS via use-livecode wrote:

Foolishly i putted this global behind the locals on the top line. And
blindly trusting myself that it was correct i did not notice it.

I didn't realize the order mattered. Seems like it shouldn't.

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

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


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


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

Re: global is empty

[JJS via use-livecode]

i had to put the global behind global, not behind local. it was a 
mistake i looked over. so no bug.


Op 23-1-2019 om 04:51 schreef Tom Glod via use-livecode:

has this been resolved?

when you moved the global declaration to the top it worked?

I keep an eye on reports like this because they are the most
worrisome kinds of things.

But I always trust that the programmer will find the error in their ways.



On Mon, Jan 21, 2019 at 5:44 PM J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:


On 1/21/19 12:06 PM, JJS via use-livecode wrote:

Foolishly i putted this global behind the locals on the top line. And
blindly trusting myself that it was correct i did not notice it.

I didn't realize the order mattered. Seems like it shouldn't.

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

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


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


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

Re: Displaying or identifying emoji

[scott--- via use-livecode]

Please post. I would find this very useful.

Scott Morrow

Elementary Software
(Now with 20% less chalk dust!)
web   http://elementarysoftware.com/
email sc...@elementarysoftware.com
booth 1-800-615-0867
--

> On Jan 23, 2019, at 7:13 AM, Stephen MacLean via use-livecode 
>  wrote:
> 
> In my testing so far, word works while trueWord doesn’t, although that 
> testing is still preliminary...
> 
> In my case, I need to strip them out. Single codepoint ones like the smiley 
> are easy, they are one codepoint and 1 word. The ones, like red haired man, 
> are tougher because they are multple codeponts. However, they are still 1 
> word.
> 
> I’ve built a sample library stack that contains all the emoji’s, their 
> codepoints and some routines that I’m using to work through this all. I hope 
> to have my testing done in the next day or two and will post for anyone who 
> wants to play with it.
> 
> Best,
> 
> Steve MacLean
> 
>> On Jan 23, 2019, at 9:59 AM, Ralph DiMola via use-livecode 
>>  wrote:
>> 
>> "Also, depending on the emoji, it may be 1 codepoint or many. Use the 
>> keyword “word” when finding, etc."
>> 
>> Word or "true word"? Does it matter?
>> 
>> Ralph DiMola
>> IT Director
>> Evergreen Information Services
>> rdim...@evergreeninfo.net
>> 
>> -Original Message-
>> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf 
>> Of Stephen MacLean via use-livecode
>> Sent: Wednesday, January 23, 2019 9:15 AM
>> To: How to use LiveCode
>> Cc: Stephen MacLean
>> Subject: Re: Displaying or identifying emoji
>> 
>> Hi David,
>> 
>> Looks like you are running into some of the same issues I had when learning 
>> to work with them…
>> 
>> You say you are importing them? From where? A text file or DB?
>> 
>> Make sure that the encoding is set to UTF-8 or higher when you import. Next, 
>> you need to textDecode() them, again making sure that encoding matches.
>> 
>> One MAJOR caveat that I ran into with using mySQL. After opening the 
>> connection, you need to add the following code to fore the connection to 
>> unicode:
>> 
>> ## Set utf8mb4
>> 
>> revExecuteSQL tDatabaseID, "SET NAMES 'utf8mb4'"
>> 
>> 
>> Or whatever your encoding is on that table. Otherwise it will default to 
>> ascii and you will get those characters.
>> 
>> Also, depending on the emoji, it may be 1 codepoint or many. Use the keyword 
>> “word” when finding, etc.
>> 
>> Hope this helps!
>> 
>> Best,
>> 
>> Steve MacLean
>> 
>>> On Jan 23, 2019, at 7:34 AM, David V Glasgow via use-livecode 
>>>  wrote:
>>> 
>>> Hello folks,
>>> 
>>> I am working on imported text messages from various sources, and which have 
>>> been through various (unknown) processes/displays before I get them.  Some 
>>> retain emoji intact, but others render them as an odd series of characters 
>>> (presumably having been substituted when stored in a non-unicode 
>>> environment):
>>> 
>>> 582 hexman555 (04/17/15 11:13:54 PM): I'll be here 😊❤️
>>> 600 hexman555 (04/17/15 11:32:15 PM): Me too ❤️
>>> 615 hexman555 (04/17/15 11:49:18 PM): Thank you ❤️💋
>>> 625 hexman555 (04/17/15 11:52:29 PM): ❤️❤️❤️
>>> 
>>> I would like to know which emoji were being used, either by displaying them 
>>> in the field or substituting "‚ù§Ô∏è” etc with parenthetic text describing 
>>> the emoji.  I have tried to break emojis down, but can’t find an app that 
>>> doesn’t display them - or rather mangles them in this way.  Similarly, I 
>>> have looked at the ascii and hex of the component characters of the 
>>> gobbledegook, but can’t see a pattern.
>>> 
>>> Any suggestions?
>>> 
>>> 
>>> Best Wishes,
>>> David Glasgow
>>> 
>>> 
>>>  
>>> 
>>>  
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: Displaying or identifying emoji

[Stephen MacLean via use-livecode]

In my testing so far, word works while trueWord doesn’t, although that testing 
is still preliminary...

In my case, I need to strip them out. Single codepoint ones like the smiley are 
easy, they are one codepoint and 1 word. The ones, like red haired man, are 
tougher because they are multple codeponts. However, they are still 1 word.

I’ve built a sample library stack that contains all the emoji’s, their 
codepoints and some routines that I’m using to work through this all. I hope to 
have my testing done in the next day or two and will post for anyone who wants 
to play with it.

Best,

Steve MacLean

> On Jan 23, 2019, at 9:59 AM, Ralph DiMola via use-livecode 
>  wrote:
> 
> "Also, depending on the emoji, it may be 1 codepoint or many. Use the keyword 
> “word” when finding, etc."
> 
> Word or "true word"? Does it matter?
> 
> Ralph DiMola
> IT Director
> Evergreen Information Services
> rdim...@evergreeninfo.net
> 
> -Original Message-
> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf 
> Of Stephen MacLean via use-livecode
> Sent: Wednesday, January 23, 2019 9:15 AM
> To: How to use LiveCode
> Cc: Stephen MacLean
> Subject: Re: Displaying or identifying emoji
> 
> Hi David,
> 
> Looks like you are running into some of the same issues I had when learning 
> to work with them…
> 
> You say you are importing them? From where? A text file or DB?
> 
> Make sure that the encoding is set to UTF-8 or higher when you import. Next, 
> you need to textDecode() them, again making sure that encoding matches.
> 
> One MAJOR caveat that I ran into with using mySQL. After opening the 
> connection, you need to add the following code to fore the connection to 
> unicode:
> 
> ## Set utf8mb4
> 
> revExecuteSQL tDatabaseID, "SET NAMES 'utf8mb4'"
> 
> 
> Or whatever your encoding is on that table. Otherwise it will default to 
> ascii and you will get those characters.
> 
> Also, depending on the emoji, it may be 1 codepoint or many. Use the keyword 
> “word” when finding, etc.
> 
> Hope this helps!
> 
> Best,
> 
> Steve MacLean
> 
>> On Jan 23, 2019, at 7:34 AM, David V Glasgow via use-livecode 
>>  wrote:
>> 
>> Hello folks,
>> 
>> I am working on imported text messages from various sources, and which have 
>> been through various (unknown) processes/displays before I get them.  Some 
>> retain emoji intact, but others render them as an odd series of characters 
>> (presumably having been substituted when stored in a non-unicode 
>> environment):
>> 
>>  582 hexman555 (04/17/15 11:13:54 PM): I'll be here 😊❤️
>>  600 hexman555 (04/17/15 11:32:15 PM): Me too ❤️
>>  615 hexman555 (04/17/15 11:49:18 PM): Thank you ❤️💋
>>  625 hexman555 (04/17/15 11:52:29 PM): ❤️❤️❤️
>> 
>> I would like to know which emoji were being used, either by displaying them 
>> in the field or substituting "‚ù§Ô∏è” etc with parenthetic text describing 
>> the emoji.  I have tried to break emojis down, but can’t find an app that 
>> doesn’t display them - or rather mangles them in this way.  Similarly, I 
>> have looked at the ascii and hex of the component characters of the 
>> gobbledegook, but can’t see a pattern.
>> 
>> Any suggestions?
>> 
>> 
>> Best Wishes,
>> David Glasgow
>> 
>> 
>>  
>> 
>>  
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode



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

RE: Displaying or identifying emoji

[Ralph DiMola via use-livecode]

"Also, depending on the emoji, it may be 1 codepoint or many. Use the keyword 
“word” when finding, etc."

Word or "true word"? Does it matter?

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of 
Stephen MacLean via use-livecode
Sent: Wednesday, January 23, 2019 9:15 AM
To: How to use LiveCode
Cc: Stephen MacLean
Subject: Re: Displaying or identifying emoji

Hi David,

Looks like you are running into some of the same issues I had when learning to 
work with them…

You say you are importing them? From where? A text file or DB?

Make sure that the encoding is set to UTF-8 or higher when you import. Next, 
you need to textDecode() them, again making sure that encoding matches.

One MAJOR caveat that I ran into with using mySQL. After opening the 
connection, you need to add the following code to fore the connection to 
unicode:

## Set utf8mb4

revExecuteSQL tDatabaseID, "SET NAMES 'utf8mb4'"


Or whatever your encoding is on that table. Otherwise it will default to ascii 
and you will get those characters.

Also, depending on the emoji, it may be 1 codepoint or many. Use the keyword 
“word” when finding, etc.

Hope this helps!

Best,

Steve MacLean

> On Jan 23, 2019, at 7:34 AM, David V Glasgow via use-livecode 
>  wrote:
> 
> Hello folks,
> 
> I am working on imported text messages from various sources, and which have 
> been through various (unknown) processes/displays before I get them.  Some 
> retain emoji intact, but others render them as an odd series of characters 
> (presumably having been substituted when stored in a non-unicode environment):
> 
>   582 hexman555 (04/17/15 11:13:54 PM): I'll be here 😊❤️
>   600 hexman555 (04/17/15 11:32:15 PM): Me too ❤️
>   615 hexman555 (04/17/15 11:49:18 PM): Thank you ❤️💋
>   625 hexman555 (04/17/15 11:52:29 PM): ❤️❤️❤️
> 
> I would like to know which emoji were being used, either by displaying them 
> in the field or substituting "‚ù§Ô∏è” etc with parenthetic text describing 
> the emoji.  I have tried to break emojis down, but can’t find an app that 
> doesn’t display them - or rather mangles them in this way.  Similarly, I have 
> looked at the ascii and hex of the component characters of the gobbledegook, 
> but can’t see a pattern.
> 
> Any suggestions?
> 
> 
> Best Wishes,
> David Glasgow
> 
> 
>  
> 
>  
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

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


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

Re: Displaying or identifying emoji

[Stephen MacLean via use-livecode]

Hi David,

Looks like you are running into some of the same issues I had when learning to 
work with them…

You say you are importing them? From where? A text file or DB?

Make sure that the encoding is set to UTF-8 or higher when you import. Next, 
you need to textDecode() them, again making sure that encoding matches.

One MAJOR caveat that I ran into with using mySQL. After opening the 
connection, you need to add the following code to fore the connection to 
unicode:

## Set utf8mb4

revExecuteSQL tDatabaseID, "SET NAMES 'utf8mb4'"


Or whatever your encoding is on that table. Otherwise it will default to ascii 
and you will get those characters.

Also, depending on the emoji, it may be 1 codepoint or many. Use the keyword 
“word” when finding, etc.

Hope this helps!

Best,

Steve MacLean

> On Jan 23, 2019, at 7:34 AM, David V Glasgow via use-livecode 
>  wrote:
> 
> Hello folks,
> 
> I am working on imported text messages from various sources, and which have 
> been through various (unknown) processes/displays before I get them.  Some 
> retain emoji intact, but others render them as an odd series of characters 
> (presumably having been substituted when stored in a non-unicode environment):
> 
>   582 hexman555 (04/17/15 11:13:54 PM): I'll be here 😊❤️
>   600 hexman555 (04/17/15 11:32:15 PM): Me too ❤️
>   615 hexman555 (04/17/15 11:49:18 PM): Thank you ❤️💋
>   625 hexman555 (04/17/15 11:52:29 PM): ❤️❤️❤️
> 
> I would like to know which emoji were being used, either by displaying them 
> in the field or substituting "‚ù§Ô∏è” etc with parenthetic text describing 
> the emoji.  I have tried to break emojis down, but can’t find an app that 
> doesn’t display them - or rather mangles them in this way.  Similarly, I have 
> looked at the ascii and hex of the component characters of the gobbledegook, 
> but can’t see a pattern.
> 
> Any suggestions?
> 
> 
> Best Wishes,
> David Glasgow
> 
> 
>  
> 
>  
> 
> ___
> use-livecode mailing list
> use-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

Displaying or identifying emoji

[David V Glasgow via use-livecode]

Hello folks,

I am working on imported text messages from various sources, and which have 
been through various (unknown) processes/displays before I get them.  Some 
retain emoji intact, but others render them as an odd series of characters 
(presumably having been substituted when stored in a non-unicode environment):

582 hexman555 (04/17/15 11:13:54 PM): I'll be here 😊❤️
600 hexman555 (04/17/15 11:32:15 PM): Me too ❤️
615 hexman555 (04/17/15 11:49:18 PM): Thank you ❤️💋
625 hexman555 (04/17/15 11:52:29 PM): ❤️❤️❤️

 I would like to know which emoji were being used, either by displaying them in 
the field or substituting "‚ù§Ô∏è” etc with parenthetic text describing the 
emoji.  I have tried to break emojis down, but can’t find an app that doesn’t 
display them - or rather mangles them in this way.  Similarly, I have looked at 
the ascii and hex of the component characters of the gobbledegook, but can’t 
see a pattern.

Any suggestions?


Best Wishes,
David Glasgow


  

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

Re: Us and them? [was Re: Livecode Dictionary]

[Richmond via use-livecode]

Oh, let's get campy.

In a perfect world there should not really be a need for "us" and "them" 
camps with LiveCode,
it should cater to all people along a continuum stretching from "us" to 
"them".


While LiveCode may be tending to introduce more "them" features 
(arguably because all
"us" features are already in place), as long as that does not detract or 
break any of the

"us" features there should be nothing to argue about.

When I teach programming with LiveCode I stick to the "us" features 
because I believe skills
learnt there are more basic and portable to other languages; but I am 
not so narrow minded to see
that many of the "them" features have their place and use in the great 
scheme of things.


This is why my "prayer" is that the good folks at LiveCode central only 
deprecate features

when that is absolutely unavoidable.

Richmond.

On 23.01.19 г. 7:13 ч., Richard Gaskin via use-livecode wrote:

Graham Samuel wrote:

> It’s OK, I think, to provide more facilities for the ‘big picture’
> professionals, such as making it easier to use version control and
> to work in teams, and to have an ever-expanding set of functions
> and even platforms; but it’s not OK if this is at the expense of
> the kind of user who doesn’t want to distort the way LC works,
> for example by deprecating stacks that contain both scripts and
> UI elements...

Stack files have not been in any way deprecated.  Nothing has change 
in that regard.


What has happened is exactly what you describe as ideal above: new 
capabilities have been added that support a much wider range of uses 
for LC, while preserving the methods in place for decades. Definite 
win-win.


I think some of this (a lot of this?) sort of discussion comes down to 
deciding who is "us" and who is "them"?


I used to be squarely in what I presume is the "us" camp, and in many 
ways I still prefer the simplicity of with-the-grain xTalk workflows.


But I also work in other languages on things outside of LC, and the 
tools and habits acquired there are also valuable.


Being able to adapt old habits, and enhance the learning of new ones, 
by mixing the best of what I learn from each has become a rewarding 
adventure.


In fact, I'm no longer sure which camp I'm in, since I'm not fully 
"us" and not full "them", but a mish-mash of both and a lot of moving 
around in between those polarities.


As long as each of us can use the workflows we prefer, does the 
distinction matter?




> A typical casualty of this conflict is the cancelling of the ability
> of these ordinary users to add notes to the dictionary, without
> apparent thought for the negative consequences.

I'm surprised no one in the community has made a LC Plugin that acts 
as a custom GitHub client for LC docs.


That would seem the best of both worlds: a pleasant UI that's as easy 
to use as it is to build, and those who prefer working directly on the 
docs in Markdown can continue to do so.


A custom GitHub client for the main repository solves many problems, 
chiefly (and so far uniquely) the issue of having learning materials 
spread out across an ever-broader range of disparate systems.  All the 
advantages of multiple intput streams, with the advantage of a single 
output stream that we all have installed and available with LC.





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

Re: Us and them? [was Re: Livecode Dictionary]

[Richmond via use-livecode]

Well, Curry, at the risk of causing you terminal disappointment, I can 
do nothing but support

your request for the thing to be a simple as possible.

"my budget hardware"

my "budgetist" hard ware is a Pentium 4 I picked up 12 years ago, second 
had, for $12 . . .


It has "2000" written on the back of it!

Oddly enough it runs LC 9.0 under Xubuntu 18.04 without a backward glance.

Richmond.

However, having played around with it when I bought it, 12 years ago, 
with Windows XP,

that was glacially slow back then

On 23.01.19 г. 1:06 ч., Curry Kenworthy via use-livecode wrote:


David:

> I'm working on a solution for this

> collaborative with the minimal possible barrier to entry
> integrated into developer workflow - that means the script editor

> personal project wiki's for the software a developer is working
> on directly from the script editor

> Thoughts? Feedback on this?

As a "KISS man" (bet Richmond will have fun with that!) my only advice 
is: Don't make it one bit more complex than it must be.


Meaning simplicity both for maintenance/quality AND for performance 
speed/memory. The Script Editor is already a bit chubby, huffing and 
puffing on many machines during a modest jog, and the Dictionary is 
waddling around even slower and shakier on my budget hardware than I 
move around myself as a handicap person. :D


What people need most in the Script Editor is to view and edit the 
code itself smoothly, without jitters or delays; the primary function 
of SE. After that, debugging and variables and search are very 
helpful. Something like a project wiki would come below all those in 
priority, and better not slow things down any further. A wiki could 
just as well be external to the SE or to LC - but if it plays nice, 
doesn't use cycles or memory or real estate unless it's turned on, 
sounds cool.


Supporting a list of standards and whizbang features is nice, but user 
comments for keywords are the essence. I would just as soon have user 
comments for the Dictionary kept fairly simple and kept in the 
Dictionary, rather than in the SE. But it sounds like you have a dream 
for this, and I'm glad to see the passion. This will be interesting!


Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.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: Us and them? [was Re: Livecode Dictionary]

[David Bovill via use-livecode]

Hi Richard - yes indeed Github and GIST integration is part of the mix. I
have libraries for those and have been publishing directly from Livecode
for a few years now so it works well. My thinking on it is to use Github as
an option for offloading (large) data, and keeping the json as metadata -
light and fast to load.

So at the moment the documentation exports small wiki pages (in json) that
link direclty to Github or GIST repositories. Livecode can then use the
json for fast local / native rendering of text - as Curry Kenworthy
comments. Minimal light weight structured json. The json is basically a
serialised array store and can be converted to markdown of HTML in
Javascript, Livecode or pandoc. So it is easy for a developer to do what
they want with it, and there are libraries to make manipulation easy.

What I'm personally finding useful is the ability to write freely while
coding. I've adopted a process of writing code in which I specify it
first + a little quick software sketch. Having a wiki page for every script
gives me the space to do that - then when you publish you have the
documentation and the code in Github or your own web site. This is a
different architecture from notes + comments - it's a wiki page you can
fork and write on.

On Wed, 23 Jan 2019 at 05:13, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Graham Samuel wrote:
>
>  > It’s OK, I think, to provide more facilities for the ‘big picture’
>  > professionals, such as making it easier to use version control and
>  > to work in teams, and to have an ever-expanding set of functions
>  > and even platforms; but it’s not OK if this is at the expense of
>  > the kind of user who doesn’t want to distort the way LC works,
>  > for example by deprecating stacks that contain both scripts and
>  > UI elements...
>
> Stack files have not been in any way deprecated.  Nothing has change in
> that regard.
>
> What has happened is exactly what you describe as ideal above: new
> capabilities have been added that support a much wider range of uses for
> LC, while preserving the methods in place for decades.  Definite win-win.
>
> I think some of this (a lot of this?) sort of discussion comes down to
> deciding who is "us" and who is "them"?
>
> I used to be squarely in what I presume is the "us" camp, and in many
> ways I still prefer the simplicity of with-the-grain xTalk workflows.
>
> But I also work in other languages on things outside of LC, and the
> tools and habits acquired there are also valuable.
>
> Being able to adapt old habits, and enhance the learning of new ones, by
> mixing the best of what I learn from each has become a rewarding adventure.
>
> In fact, I'm no longer sure which camp I'm in, since I'm not fully "us"
> and not full "them", but a mish-mash of both and a lot of moving around
> in between those polarities.
>
> As long as each of us can use the workflows we prefer, does the
> distinction matter?
>
>
>
>  > A typical casualty of this conflict is the cancelling of the ability
>  > of these ordinary users to add notes to the dictionary, without
>  > apparent thought for the negative consequences.
>
> I'm surprised no one in the community has made a LC Plugin that acts as
> a custom GitHub client for LC docs.
>
> That would seem the best of both worlds: a pleasant UI that's as easy to
> use as it is to build, and those who prefer working directly on the docs
> in Markdown can continue to do so.
>
> A custom GitHub client for the main repository solves many problems,
> chiefly (and so far uniquely) the issue of having learning materials
> spread out across an ever-broader range of disparate systems.  All the
> advantages of multiple intput streams, with the advantage of a single
> output stream that we all have installed and available with LC.
>
> --
>   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