Re: HTML5 deployment: progress comes into sight

2017-06-01 Thread Roland Huettmann via use-livecode
Yes, I agree. Thanks a lot. ) Roland

On May 31, 2017 19:07, <jonathandly...@gmail.com> wrote:

> A callback is not synchronous, his point was that it would be nice to
> communicate synchronously between LC and JS, rather than use complex
> callback chains.
>
> I agree with him, but I don't think there is a universal way to do that,
> just because some things in JavaScript, like rendering an image or using a
> webworker, are inherently asynchronous.
>
> Sent from my iPhone
>
> > On May 31, 2017, at 12:36 PM, Roland Huettmann via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > @BR wrote: ... "What's very difficult, as you write in detail, are
> > "callbacks" for _synchronous_communication..."
> >
> > Callback functions?
> >
> > In my mind, a "callback" is always asynchronous -? Let us say in
> Javascript
> > - passing the function name and parameters of Javascript through LCS/LCB
> > and then somehow the result is put into a variable while I am continuing
> > processing other stuff. Maybe I am wrong? I am calling a server, waiting
> > for the result, but I could wait forever and the result will possibly
> never
> > come. So it would be blocking doing other things. A callback would free
> me
> > from waiting for nothing. Is this a right definition for "callback"?
> >
> > What defines "callback"? I could understand though that I am calling a
> > function in the browser widget (using the "callback" name of the
> function)
> > which will be executed through Javascript and will be returning a value
> for
> > further processing. What means "synchronous" or "asynchronous" in this
> > context?
> >
> > Again, in my mind, a callback is when I send off a parcel to my friend
> with
> > an instruction to tell me that it arrived and the confirmation of
> arrival.
> > The confirmation is the callback. Then I know my friend received the
> > parcel. Or in another analogy, I am calling someone by phone asking to
> call
> > me back. The person may call immediately or may call never or in a couple
> > of days. This is asynchronous.
> >
> > How would a callback become synchronous? Is it then still a "callback"?
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: HTML5 deployment: progress comes into sight

2017-05-31 Thread Roland Huettmann via use-livecode
@BR wrote: ... "What's very difficult, as you write in detail, are
"callbacks" for _synchronous_communication..."

Callback functions?

In my mind, a "callback" is always asynchronous -? Let us say in Javascript
- passing the function name and parameters of Javascript through LCS/LCB
and then somehow the result is put into a variable while I am continuing
processing other stuff. Maybe I am wrong? I am calling a server, waiting
for the result, but I could wait forever and the result will possibly never
come. So it would be blocking doing other things. A callback would free me
from waiting for nothing. Is this a right definition for "callback"?

What defines "callback"? I could understand though that I am calling a
function in the browser widget (using the "callback" name of the function)
which will be executed through Javascript and will be returning a value for
further processing. What means "synchronous" or "asynchronous" in this
context?

Again, in my mind, a callback is when I send off a parcel to my friend with
an instruction to tell me that it arrived and the confirmation of arrival.
The confirmation is the callback. Then I know my friend received the
parcel. Or in another analogy, I am calling someone by phone asking to call
me back. The person may call immediately or may call never or in a couple
of days. This is asynchronous.

How would a callback become synchronous? Is it then still a "callback"?
___
use-livecode mailing list
use-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

2017-05-18 Thread 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


LiveCode.org

2017-05-01 Thread Roland Huettmann via use-livecode
Referencing: Community Coding Standards, Naming Conventions, Best Practice
Richard Gaskin wrote:"These are good questions"...

put "Thank you, Richard" into myArrayKey ["private"]
put "It seems Richard is spending all his days and nights here in the
mailing lists and forums. There must be thousands of messages by now
attached to his name. But it is really enjoyable to read all his posts.
Thanks to him for this huge effort. I think I could state that all others
here feel the same" into my Array ["public"].

And very good answers are coming from all sides. I enjoy reading.

---

I read a lot of very critical and even nasty remarks regarding the
www.livecode.org site. And really, it needs improvement. Is there someone
in charge of that site? Because it could be a good ground to publish ideas
and guidelines in a central place. I am willing to contribute, but I can
not manage such site.

This could be the location to place Community Coding Standards, Naming
Conventions, Best Practice, etc.

Just here are some first ideas from my first brainstorming out of the blue
for the content development of such site. It is just an unordered
brainstorming list to help to establish a real community platform.

- Big invitation to the Community (and community version)
- Download Community version together with a functional useful
professionally made application that works everywhere
- Download of more ready-made solutions and starting stacks with a very
up-to-date GUI for all devices
  (Of course well documented in all details, a guide for newbies to
understand each line of code)
- What is LiveCode and what it is not?
--- What makes LiveCode unique in comparison? = Unique Selling Proposition
--- Comparison with other similar programming languages
--- Comparison with very popular languages
--- Comparison with other OOP implementations, dot notation, etc.
- LiveCode's worldwide market (why not open up more to other regions in the
world?)
- LiveCode terminology (abbreviations, acronyms, glossary)
- LiveCode system architecture (how is the engine working? Compiler...
deeper insight)
- LiveCodes (LCS and LCB), even driven system, messaging
   (And of course, explanations why it is as it is)
- LiveCode language features
 LCS and LCB
- Coding standards
- Naming standards
- IDE guide
- Deployment guide (always updated to latest)
- Online interactive language learning course
- Online dictionary of certain computer and LiveCode terms (Chinese,
Japanese, Arabic, French,.. )
- Associations/representations in various countries (speaking their local
language, organizing local workshops)
- Best practice (A huge section for best practice with code examples and
snippets)
- Stack exchange (the one on livecode.com has a lot of "old" stacks, but
very few new ones
- Marketplace, stacks, LCB widgets, LCS widgets
- Reviews
- Community projects
- Articles from users (blog)
- Sponsoring (attracting sponsors as well)
- .Ads section (publishing paid ads)
- Links
- Support

Mmh. It is pretty much work to build and maintain ). We should find a
sponsor. )

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


Community Coding Standards, Naming Conventions, Best Practice in LiveCode Script for community contribution work

2017-04-27 Thread Roland Huettmann via use-livecode
I am referring to the note from Richard and to our discussion about
Contribution From The Community - expanding the developer base to "hundreds
and thousands of users" -- even if only 10 will remain?.

Richard wrote:
> At the bottom of the "Contributing" page for the LC code base there are
> links to C++ style guides:
> https://github.com/livecode/livecode/blob/develop/CONTRIBUTING.md

These are just a few more links found with a quick search.

http://www.fourthworld.com/embassy/articles/scriptstyle.html#Naming
http://forums.livecode.com/viewtopic.php?f=7=22946
http://lessons.livecode.com/m/4603/l/284467-variables-in-livecode
http://forums.livecode.com/viewtopic.php?f=7=5265
http://stackoverflow.com/questions/16746794/what-are-some-best-practices-for-function-naming-in-livecode-runrev
http://use-livecode.runrev.narkive.com/ZPvn2z2N/object-naming-conventions
http://use-livecode.runrev.narkive.com/8REAd9JD/any-convention-on-naming-conventions

I kind of find it very important for joint work and contributions. Maybe
there should be a page from LiveCode offering at least a semi-official
Community Standards Guide (or whatever it would be called) for
LiveCode Script.

Or will we all switch to LCB and slowly forget about LCS? (I am not sure
here.)))

For local variables, I also do not like long expressions for simple
counters which are created "on the fly". The most widely adopted standard
is using i, j, k, l ... (not x and not tCount) -- but otherwise, local
variables in LCS start with "t" in LCS as tSomething. But something should
be recommended for all others to follow, and not just say "do as you like"
-- if there is any joint community effort expected.

Yes, I am using pSomething for parameters even though there could be
arguments against it. But I find them quickly in my script and know what
they mean.

And when I put something into the messages box, I ALWAYS type "put ... into
msg" instead of simply "put ..." because then I can find such instances
with the search and disable or enable such instructions. There are too many
"puts" to search for otherwise. Little things that make life easier.

But more important, an adopted COMMUNITY standard should be widely
available and prominently placed to allow new users and everyone to access
it at any time - maybe even as a separate section in the dictionary? I
suggest a section discussing the STANDARD way of naming, writing code,
naming functions, naming keywords, ways of commenting, what to avoid, what
to care for, warning from pit holes, how to publish to the community, how
to open new projects to the community, best way of debugging, best way of
implementing error detection in general, best way of avoiding the script
editor to open when users are using our app, single/multi user approaches
with a rights management, best way implementing a database management
system with remote databases depending on security issues and number of
concurrent users considerations, how to implement design concepts (such as
Googles material design), etc.

And it could also be argued that data-driven applications use a lot of
databases, and the naming conventions for such databases should be
maintained, for example not to use the "_" underscore as a first char for
field names, or not to use upperLower (camel case) naming when the database
distinguishes between upper and lower characters, because easily, simple
typing mistakes can create hours of searching the problem.

The best STANDARD here is to look for the LOWEST COMMON DENOMINATOR when
interfacing with other languages and systems. And we will interface sooner
or later.

The document should also talk about best practice in general, and for
specific cases. Let us not reinvent the wheel when others before us already
have found the optimal solution for a given problem. Yes, things can be
done in different ways, but then it would be up to the community to test
and do benchmarking and detect the better and decide for the best (rating
with stars?). There could be a competition to beat the benchmarks and a
gold medal for the best contribution.

What really means "quality" code here? Who can guide me, others, everyone?

Again, how can we (could I) contribute making this a reality? Who can
answer?)

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


Make numberFormat even better

2017-04-26 Thread Roland Huettmann via use-livecode
Thank you, Richard, Curry, Mark...

It is a very nice approach that Curry already realized: and it is available:
http://curryk.com/ck-num-format.pngn better

But what I do not yet understand is how to make a joint effort with
hundreds of developers ))) available to ALL of us in practical terms --
seamlessly.

For any newbie and for those using formatting all the time, do we have to
load a separate library or would it be supported out of the IDE? For
example, could the numberFormat or format() functions be overwritten so
that simply using LiveCode Script it would work the way we defined and this
out of the engine?

Or is it a new function? And could it be shipped with the product if
approved? Again, we are thinking of Excel style formatting that any user,
even non-programmers, often enough know about.

And how can we contribute? Is it a joint effort where someone is delegating
the task? Or is it the work of someone taking the time to write it for ALL
of us? And, also I wrote about this, I feel a bit shy to think that I could
provide code that would or could really be seen as a viable contribution. I
do not know what really makes LiveCode Script be quality code?

Is there any guide telling that such LiveCode Script following certain
style and rules and using the best performant way will be accepted as
"quality code"?

I know about naming variables (naming conventions), and I assume that
comments could also follow style (comments disabling parts of code,
comments to the code, etc.), and even possibly assigning variable names
that are common to everybody -- for example, I have a style to always name
sames types of variables the same way: For example for variables containing
file information: tFileName (with extension), tFilePath (full absolute
path), tFolderPath (without ending slash), tShortFileName (without
extension), tFileExtension (just the extension), or i, j, k... as counters.
Because I am lazy, I find such conventions (for private use, or for
community use) very helpful. I assume there are 30-50 standardized names
that could be shared to make code easily readable and that also newbies
should know about.

Then, again to be practical, how would we name fields and how would we name
custom properties indicating how code should work with a field and format
such field?

Assumed, there is a currency style field with a format such as
"$#,###.00":=  "$1,000.00" where a style property would be set for this
field. This field also serves as a database field and should "know" to
which data source it is connected and also may know in which order database
fields appear. That is another custom property. So, a command saving to the
database would look up all such fields, convert strings to numbers the
database understands, already know the underlying database field name
without any further scripting, and simply saves whatever is there. And,
yes, there is a behavior script assigned to such field - and it depends
whether data is entered manually, or it is put into the field through a
script.

Another field could present a scientific notation and accept and display
scientific notations.

This can grow to become a very dynamic behavior when strictly following a
certain style that is used by everybody.

Or am I thinking into the wrong direction?

I am not worrying doing it for myself. I am more thinking when we are
offering this as an adopted standard.

With dates, there is always a problem in Central Europe because the system
date displays a date string that is not seen by the engine to be a date. It
is NOT a date for LiveCode Script. Here, we have DD/MM/YYY or DD.MM..
So, I must always convert such date anyway to allow LiveCode testing it to
be a valid date. For SQLite and other databases we need it to be
"-MM-DD" and internally we might just use the seconds.

Then, adding field "A" of type date to field "B" of type date (or
variables/arrays representing such fields) should result in a new date
without even having to think.

And I assume it would be best for users setting the field format using a
context menu clicking on the field in questions and setting such behavior
and formatting options -- if this is not part of the Property Inspector.
Such context menu could open some Settings pane when needed.

Or can we, should we, simple users, modify the Property Inspector?

I assume it would be best if someone following the guides and with deep
experience would implement while the rest of us could contribute with
testing, discussing, etc. ?

And because of all this, and for joint work especially, I would really
appreciate more standards, more guides for "best practice", even strict
rules -- not to make things not work when breaking such rules, but to make
things easier and more transparent in the other 99% of cases.

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

Make numberFormat even better AND Cognitive Load

2017-04-25 Thread Roland Huettmann via use-livecode
With reference to the past suggestions, and the last one from Richard
Gaskin:

"Even if the core team were in a position to drop other priorities to add
formatting to fields, they couldn't do it any faster than a scripter who
has the advantage of doing it in LiveCode itself."

I have been thinking about the underlying reasons why we are discussing. I
agree with Richard that a lot of what we have in mind can be done simply
using LiveCode script and behaviors for fields. But are we not doing this
already most of the time?

===
 AGAIN -- having read all - I vote for the LC-NATIVE "Excel style" number
format (enhanced numberFormat in LC, not a new one, no depreciation, but
just different ways to achieve the same) and the ability of fields (text
controls) to express at least the same styling properties that fields
(cells) in Excel support, or text boxes in the web browser without having
to write my own functions. I would like to have it "built-in". It is a
wish. LiveCode should grow so that the team developing it will consist of
100 core developers. It is a wish. Maybe someone else can help developing.
We can fund it. Whatever. It is a wish. And I do not want to stop wishing
just because there is "no time left" for the core developer team to care
for such minor (???) details. They need more support and more funding in
such case. Would they not deserve it? And are there not billions of dollars
around, often enough just wasted for what? ))). Why should not a clever
large company see LiveCode as a way to enhance their public awareness and
sponsor it?
===

Expanding the "numberformat" going beyond...

I favor great visual style and I would love when people start using
LiveCode as a development platform even for the web, as a design system, as
a way to translate to HTML/CSS, Javascript and PHP using ONE base, as a
workshop for great content management systems -- and a lot has been done in
this way during the last three years.

And I am also asking myself, why am I spending time over and over writing
lines of code that are just repeating themselves for me and others, more or
less. And my own library is just my own. I use it. I could share it, but it
is not part of the community really. (And I feel too shy to share it unless
it was reviewed and tested a hundred times.)

So basically, we are not so much discussing about ourselves -- at least not
when there is some experience gained developing with LiveCode -- we are
discussing about the LANGUAGE as we believe it deserves to be spreading out
into the world to 100x or 1000x more developers or people wishing to at
least using such jewel for their fun at home, for in-house development,
just to solve some problems that otherwise would require a professional and
very costly setup.

We know that we can already solve lots of such questions about formats
(number formats, date formats, colors, forms, visual appearance in general)
just reverting to scripting. For example, to just have a bottom border
underlined, I can of course just use a line object and have it set where I
want it to be. But is this really how it should be in today's world? I
would rather like to focus on even more abstract levels and not having to
care too much about the daily standard routines.

I am thinking of the ATTRACTION TO THE LANGUAGE especially for NEWBIES,
young people, retired people, who have not much or no experience at all
with computer languages. There is a huge market.

So, I am stretching out beyond numberFormat -- more into Cognitive Load --
another nice discussion we are having.

Why should not retired people have fun developing on a computer? Would not
LiveCode be the only and truly ideal way to learn and enjoy results
immediately? It can be a business by itself. There are growing numbers of
them, millions and millions of retired people who even have all the time to
not allowing their brains to rust. It is "just" a question of proper
worldwide marketing.

Or think of Africa with hundreds of millions of young people who have not
much chance to even touch any computer, even if almost every of their
elderly brothers and sisters owns a cheap Android phone to be proud of.
There are hundreds of millions of young people eager to get involved. And
some of them could even make a living using it. And there are funds with
hundreds of millions just for such young people.

I want the language to shine bright, really be able to compete, and even
when acknowledging that it is probably impossible to win much ground
against Javascript or PHP or Python. The base for such other languages is
too big. The support such languages enjoy from largest companies can not be
argued against.

But still, I feel, that I would love to see LiveCode gaining ground, be the
first choice at least for beginners. (And I say this because I have fun
using it.)

Who will start with the expanded "numberformat" to be shipped with newer
versions? )

Roland

P.S. I hope this contribution message is not too much missing the point --

Maje numberFormst even better

2017-04-25 Thread Roland Huettmann via use-livecode
Very interesting discussion. Many thanks to all for deeper insight!

Here is a link for Excel cell formatting:

https://support.microsoft.com/en-us/help/264372/how-to-control-and-understand-settings-in-the-format-cells-dialog-box-in-excel

Millions of users know this formatting style. Why reinvent the wheel?
Numberformat could eventually be enhanced to this direction...

I still also wished to see it as a property-set of fields, but built in,
not "just" as a custom property. Dreaming...). It is a simple user wish,
not a recipe about how to do it. I understand that it is difficult to do.

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


Subject: Re: Don't amputate numberformat

2017-04-24 Thread Roland Huettmann via use-livecode
Mike Kerner: "Well, that would be a nice thing to have in a field widget,
but I run into
formatting issues with databases, as well, especially when sorting."

I am using all kinds of formatting functions with databases. There is
always this overhead which could be minimized using a database adapter as
provided in other languages, or writing your own.

But fields, the visual objects used most, are a focus for any data
management. They always deserve attention, and unless there will be such
new widget, actually our already nice fields would be candidate for such
and other improvements.

And also, it is a widely adopted standard that left, top, right and bottom
boundaries could be formatted separately.

I do not know much about the internal workings of the machine, but could
such work be outsourced? Maybe someone could raise funding? I would rather
like to see the improvements in the core engine instead of as a LC Builder
widget since it is so basic.

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


Don't ampute numberformat

2017-04-23 Thread Roland Huettmann via use-livecode
I get around with numberformt, format() and own custom functions. But the
discussion is interesting nevertheless, even when repeating.

But it would be better to have consistent support throughout the IDE with
one preferred method covering also international formatting edge cases.

What I really would love to see are fields and lists (columns at least)
where a field/column/cell has a formatting property similar to Excels cell
formatting.

It would make life much easier to simply set such property from predefined
options. Or formats will be user-define manually or through script.

90% of overhead in formatting would be gone when entering or displaying
data this way. And dependent on the field formatting, the engine would
internally convert data types when addressing such field:

"put 1000 into field 1" would render "$1,000.00" if the format property
would have been set as such. And entering 1000 would format the field in
the same way. Using such values in mathematical operations would be
possible without the need to strip "$" and comma symbols or thousand
seperators, the  engine would convert text to number automatically even for
such formats.

Only for the output or numbers/dates rendered as part of a text string,
individual formatting of numbers/dates will still be needed sometimes.

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