Distinguishing between tap and swipe

[Sannyasin Brahmanathaswami via use-livecode]

Mobile: To distinquish tap from swipe, I'm using the abs of the difference of 
the mouseloc on mousedown and mouseup….

private function _mouseMoved
put abs (the mouseV - item 2 of sStartLoc) into someDistance
put someDistance >= 10 into someBoolean
return someBoolean
end _mouseMoved

But this is quite "sluggish" on the any phone, meanwhile any straight forward

on mouseup
do something
end mouseup

is quite snappy.

Is there a better way to trap for swipe and immediately trigger a tap.

BR


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

Composite Set up - PreopenStack "everywhere"

[Sannyasin Brahmanathaswami via use-livecode]

We are using highly modular framework for our new app. 

Nothing like the IDE itself of course, but we are up to close to 50 
*.livecodescript  text only scripts divided into behaviors, libraries, models  
plus about 15 binarie.livecode stacks for modules and "views"…. and growing. 

I'm trying to optimize for small android devices and it seems the 
compositorType, tile size and cache limit are important. 

I have this in an init script that is a behavior on the main stack that opens 
when the app opens, card 1 has the init behavior that loads all the rest of the 
libraries and stack files

FYI the compositor was doing really, really strange things on my mac so I 
turned it off under development. Alsothe documentation and lesson on this is 
really lean, so if anyone has better, more detailed guidelines for best 
practices on this , please let us know:

I have this in the preopenstack handler

on preopenstack
   # some init routines, load and start using libraries
   # then this:

if the environment <> "development" then
 set the acceleratedRendering of this stack to "true"
 if the platform is "iphone" then
 set the compositorType of this stack to "opengl"
 else
 set the compositorType of this stack to "software"
 end if
 set the compositorTileSize of this stack to 32
 set the compositorCacheLimit of this stack to (16 * 1024 * 1024)
end if
 pass preopenstack
end preopenstack

Ok so this is working now and the rendering of the stack on my macbook pro 
doesn't go "kerpluey!" (strange rects, cropped group with black background 
other weird stuff, flickering graphic) and the app runs fine on the iphone and 
Android.

But apparently we need to have this set for every *[binary].livecode stack/view 
we launch, as the compositor setting is not persistent across a session. So the 
questions are two

1) The above is cut and paste from the online lesson on this subject. Please 
fire away with better tips on the best way to declare these settings. 
"software" obviously does not apply to all device besides iPhone, other wise it 
would not fail (intermittently) on my mac book pro.  The lesson says to 
multiply the rect of all your layers by 4… e.g. 10 layers: (10 x(400x400) x 4) 
what exactly does that mean.. ? what defines the rect of a given layer? the 
full geometric boundary around all the objects on that layer? or simply the 
rect of the card times the number of layers?

2) Given that this preopenstack handler is in a behavior on the card for the 
launching stack, it is not global. What is the best thing to do if we want the 
compositor to be set every time any other stack is opened? 

We have one lib_SivaSiva.livecodescript that we start using that serves as our 
app wide generic handlers "backscript". I have set preopenstack handles in 
backscripts before and sometimes it gets you into trouble if you start doing 
stuff that really should not be globally implemented.  But if I include this 
into that library

on preopenstack
 if the environment <> "development" then
 set the acceleratedRendering of this stack to "true"
 If the platform is "iphone" then
 set the compositorType of this stack to "opengl"
 else
 set the compositorType of this stack to "software"
 end if
 set the compositorTileSize of this stack to 32
 set the compositorCacheLimit of this stack to (16 * 1024 * 1024)
 end if
pass preopenstack
end preopenstack

Now it will fire every time any stack is opened. Is there some penalty for this 
method? My gut tells me that perhaps having these preopenstack handlers "lying 
around in the message path" is just not best practice. But maybe that just a 
"superstitious fear" 

Or maybe we should turn this into a discrete handler

command setUpCompositor
   # set the acceleratedRendering and compositor settings here

end setupCompositor

and then, call this discretely in a preopenstack handler in each separate 
stack. 
That somehow makes me feel better, not sure why.  Possibly because almost all 
the binary.lc stack in the framework *do* have preopenstack handlers already….

What do you recommend for 1) and 2)?

BR


___
use-livecode mailing list
use-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: Download LC Community: trapped.

[Richard Gaskin via use-livecode]

James Hale wrote:


Richard wrote:

Most SEO brings people to the .com site, so those on the .org
site are the subset who specifically went there the get the
open source edition of LiveCode.


I still don't understand why this distinction was made.


That was an idea I pitched to the team, and as we thought it through it 
seemed a good fit for what LiveCode Ltd. is doing.  Over time we may 
find a unified site is better, but at the moment I like where things are 
potentially headed.


Many open source projects have a .org domain for their community 
efforts, including drupal.org, apache.org, r-project.org, python.org, 
wordpress.org, getfedora.org, etc.


By splitting .org from .com, we have the opportunity to allow the 
company to hone their messaging for developers of proprietary apps at 
.com, while providing a portal at .org for not only the software itself, 
but also resources for community projects, contribution assistance, EDU 
tools and support, and more.


We're still early days with the .org site, and they haven't set set up 
the facilities to allow a community web team to augment that domain with 
relevant community info.


But we'll get there, hopefully soon.

--
 Richard Gaskin
 LiveCode Community Liaison
 rich...@livecode.org

___
use-livecode mailing list
use-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: [Blog] Infinite LiveCode Progress

[Sannyasin Brahmanathaswami via use-livecode]

heather wrote:

" Folks, in case any of you missed it, LC9 dp6 has some great new 
functionality:"

Beware: I have been doing "great work" (by that I means squashing bugs and 
running tests) in 9dp5, but 9dp6 completely trashed the android standalone 
build (on the phone only… my repository scripts and binaries are fine, I am 
filing a report)

I switched back to 9dp5, right away… and ran the test again and it performed 
perfectly, nothing wrong with our scripts.

FYI: odd but true: I'm making better progress now but targeting my android 
phone… it's faster to build and deploy, I don't have to go to Xcode → Devices 
and add the stand alone…  and whenever I do deploy on iPhone, if it is working 
on Android it always works on iPhone so…. go figure.

BR

 



___
use-livecode mailing list
use-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: Working browser widget/linux-flavour combinations?

[hh via use-livecode]

> Mark Wieder wrote:
> ... worked in 9.0-dp6 ... 64-bit Linux Mint 17.3 cinnamon.

So I tried Mint 173 cinnamon 32 bit and Mint 181 cinnamon 64 bit,
used LC 8 and LC 9, in Virtualbox on Mac and on a 64 bit Linux box.

Both show with the browser widget the "something"-window that Richmond
described and LC is to be 'killed' after trying to use the widget.

Now launching from Terminal with Panos' advice
( LC_ALL= LC_NUMERIC=C "path/to/livecode_executable" )
brings up a widget, yes. But this works sadly only "halfway":

No context-menu, not even for navigation, no connection to localhost
possible, limited HTML5 support (some files don't work which work in
Win and Mac without any problem).

Is the widget not a 'modern browser' in linux? Or is the installation
of special lib-files required to have it fully working? 


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

Nightly builds

[James Hale via use-livecode]

I just noticed one of the benefits to membership of the open source community 
is access to nightly builds.

Can anyone tell me how this is possible?
Is it only for the community version?
Is there a link or is one expected to make the build oneself?
Or is this just smoke and mirrors?

James

___
use-livecode mailing list
use-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: Download LC Community: trapped.

[James Hale via use-livecode]

Richard wrote:
> Most SEO brings people to the .com site, so those on the .org site are 
> the subset who specifically went there to get the open source edition of 
> LiveCode.  The conversion rate there is understandably much lower than 
> on the .com site.
> 
> After all, someone at the .com site is there to look for a proprietary 
> product.  Their interests are very different from the subset who move on 
> to .org.  The visitors at .com expect that if they like what they see in 
> LiveCode they'll pay.  They're predisposed to conversion.

I still don't understand why this distinction was made.
Although my professional buying was in the tertiary sector I always went to  a 
.com sites unless it didn't exist. Many of the solutions we investigated over 
the years were both open source and no cost to education as well as proprietary 
for commercial use (which may include education depending on the context of 
usage.) None that I can remember had two websites. Indeed it was always of 
value to be able to directly compare the no-cost to cost versions to see if the 
propriety offer was more suitable.
This is no longer possible on the LC .com site. It used to be.
The last time I looked at the .org site it was very much a poor cousin to the 
.com site.
None of the resource pages were to be seen, just a list of the community 
communication channels.

The membership option is new. (Well recycled) and a great idea.
Although I did notice one component being access to nightly builds.
!!!
Is this true?

James

___
use-livecode mailing list
use-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: [Blog] Infinite LiveCode Progress

[Mark Smith via use-livecode]

Speaking of Infinite, I have been asked to upgrade an older iPad product
(which was developed in 5.0) and I thought while I am in there I would like
to tackle the issue of a native look and feel. Any progress on stretch goal
3 - a native field widget? If it is going to be ready in the next month or
two it probably is worth waiting for. If not, I'll just dive in with the old
UI and tackle this in another revision.

Thanks

Mark




--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Blog-Infinite-LiveCode-Progress-tp4712933p4712963.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: IOS Provisioning Profile... again

[Mark Smith via use-livecode]

Thanks Mark. It's not the installation that is the problem - it's the fact
that the application stops working after a year then you have to get new
certificates, recompile, reinstall, etc. To parrot Donald Trump - "it's a
nightmare, a TOTAL disaster" :) (Just kidding). Its an inconvenience for me,
the developer. I don't think the client would be interested in changing
platforms for that. But maybe...

Mark




--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/IOS-Provisioning-Profile-again-tp4705953p4712965.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: Download LC Community: trapped.

[Paul Dupuis via use-livecode]

On 3/9/2017 6:18 PM, Richard Gaskin via use-livecode wrote:
> Growing the platform's audience. 


You make a good point here.

I wish i knew whether the open Source effort significantly grew the
userbase over whatever trend it was on before the OSS effort and whether
the actual number of paying customers shrunk (in real numbers, not a
percentage), or remained on a constant trend, or grew after the OSS release?

If 75% of downloads are Community and 25% paid (approximate figures
LiveCode has stated in the last year) but real numbers for both have
increased since the OSS launch, that would paint a more favorable picture.

In a way, my musings are a moot point. I have confidence in Kevin and
LiveCode, Ltd to keep the company viable and moving forward so time will
work all these questions out.



___
use-livecode mailing list
use-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: IOS Provisioning Profile... again

[Mark Schonewille via use-livecode]

If you don't want to renew the certificates every year, you can move to 
Android. Users of Android phones can (temporarily) allow for the 
installation of apk's from unknown sources (i.e. signed for development 
only).


Kind regards,

Mark Schonewille
http://economy-x-talk.com
https://www.facebook.com/marksch

Buy the most extensive book on the
LiveCode language:
http://livecodebeginner.economy-x-talk.com

Op 10-Mar-17 om 03:03 schreef Mark Smith via use-livecode:

Just a further question to this thread. Is it possible to deploy (without
going through the app store) and not have to renew the certificates every
year? It's a major bane to have to update these things all the time.

Thanks

Mark



___
use-livecode mailing list
use-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: IOS Provisioning Profile... again

[Mark Smith via use-livecode]

Just a further question to this thread. Is it possible to deploy (without
going through the app store) and not have to renew the certificates every
year? It's a major bane to have to update these things all the time.

Thanks

Mark



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/IOS-Provisioning-Profile-again-tp4705953p4712961.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: Download LC Community: trapped.

[Roger Eller via use-livecode]

On Mar 9, 2017 5:26 PM, "Richmond Mathewson via use-livecode" <
use-livecode@lists.runrev.com> wrote:
>
> Asking for an e-mail address is a small thing to ask for.
>
> But _forcing_, rather than _asking_, isn't quite the same thing.
>
>  Personal blether starts now ---
>
> I don't feel capable in a big way to contribute to LiveCode development,
> so I do try to send bug reports in when I fall over 'bugs'.
>
> I am still wondering about trying to make a simplified interface for some
sort of
> cut-down version of LiveCode using block-programming [ c.f. Scratch and
so on ].
>
> I was wondering about having a script-editor with blocks . . .

Things of the past could easily be new again.  Authoring environments come
to mind.  Amiga Vision was a favorite of mine for stringing together
multimedia with timers, synchronized narration, and even simple button
logic.  I could see kids in a beginners LiveCode class using blocks to at
least design app concepts, and simple logic structures.

https://www.youtube.com/watch?v=mqywIVs2S4w

>
> Richmond.

~Roger
___
use-livecode mailing list
use-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: Searching "teh" or tihs"

[Andre Garzia via use-livecode]

Congratulations on the fuzzysearch. I don't know how you did it but for the
English language, I remember both soundex and its refinement called
metaphone, both algorithms are made for this kind of situation. I think
that Levenshtein distance based algos are the way to go for this stuff
these days but are a bit beyond of what I am used to developing...

On Thu, Mar 9, 2017 at 9:26 PM, hh via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Searching is important for your project?
> Would you like to ask "Did you mean the?" if user searches "teh"?
>
> I've implemented a fuzzySearch algorithm in LiveCode script:
> http://forums.livecode.com/viewtopic.php?p=152202#p152202
>
> Now if you wish to look up "the" or "this" then fuzzySearch will find
> it (among others) by searching "teh" or tihs", with a penalty score of
> one only for swapping the chars.
>
>
> ___
> use-livecode mailing list
> use-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: Download LC Community: trapped

[Alejandro Tejada via use-livecode]

on Thu, 9 Mar 2017, Richard Gaskin wrote:
> The value of an email address is only non-zero
> when it's given freely. So have sign-up as an option,
> rather than a requirement, and the problem
> is very easily solved.

Emails directions could be really useful to open
a direct communication link with newcomers
and our LiveCode Community.

Most of the time, new developers in this platform
do not know about some old but useful learning
resources that longtimers take for granted, so
these essential resources are basically invisible
for us.

Probably one of the most eye opening information for
new developers is how others are using LiveCode.

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: Searching "teh" or tihs"

[hh via use-livecode]

> Peter Bogdanoff wrote:
> This looks intriguing! I’m working on a commercial project that
> could use this. What is your license?

The code is based on pseudocode from
https://en.wikipedia.org/wiki/Damerau–Levenshtein_distance

From my side it's free for non-commercial use, I only wish to have
a citation.

For commercial use of my published scripts I would like to have
1. a citation
2. an "At-least-donation", one time, for the
+ CFFL = Community Fund for LiveCoders: +
For such LiveCoders who help the community such a lot in the forums
or here in the list and who really _need_ some money (I know some).

The donation for this script here should be _at least_ $10 (one time).

The fund is a new idea.
Certainly Richard Gaskin is willing to manage such a fund (assuming he
doesn't need such funding). OK Richard?



___
use-livecode mailing list
use-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: Searching "teh" or tihs"

[Peter Bogdanoff via use-livecode]

hh,

This looks intriguing! I’m working on a commercial project that could use this. 
What is your license?

Peter Bogdanoff

On Mar 9, 2017, at 4:26 PM, hh via use-livecode  
wrote:

> Searching is important for your project?
> Would you like to ask "Did you mean the?" if user searches "teh"?
> 
> I've implemented a fuzzySearch algorithm in LiveCode script:
> http://forums.livecode.com/viewtopic.php?p=152202#p152202
> 
> Now if you wish to look up "the" or "this" then fuzzySearch will find
> it (among others) by searching "teh" or tihs", with a penalty score of
> one only for swapping the chars. 
> 
> 
> ___
> use-livecode mailing list
> use-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

Searching "teh" or tihs"

[hh via use-livecode]

Searching is important for your project?
Would you like to ask "Did you mean the?" if user searches "teh"?

I've implemented a fuzzySearch algorithm in LiveCode script:
http://forums.livecode.com/viewtopic.php?p=152202#p152202

Now if you wish to look up "the" or "this" then fuzzySearch will find
it (among others) by searching "teh" or tihs", with a penalty score of
one only for swapping the chars. 


___
use-livecode mailing list
use-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: Download LC Community: trapped.

[Richard Gaskin via use-livecode]

Paul Dupuis wrote:

> With 75% of downloads being Community, only 25% of the user base is
> paying for 100% of the development. The idea being that those that get
> LiveCode for free would, in some part, contribute back to the Open
> Source effort that, in turn, expands the commercial offerings. The
> statistics show that is only minimally happening and not in any way to
> support the cost of giving LiveCode to 75% of the user base free. I
> hope this changes.

The value of an open source edition is more than direct contributions, 
and even contribution comes in many forms.


Code contributions are minimal at this time, but that's a function of 
ecosystem size.  With any FOSS project only a percentage of users will 
have the intersection of skills, interest, and time to contribute code.


Beyond code we have larger percentages of contribution to docs, and even 
now a majority of technical support is covered outside company expense, 
through forums and other online sources and many in-person volunteers.


In short, a slow start but far beyond where we were when v6 was the 
first open source edition.


But of course we'll want to improve on that going forward.

And the best part there is that the path to success for both 
proprietary-license revenue and open source contribution is the same:


Growing the platform's audience.

LiveCode is a great technology.  The biggest thing holding it back has 
nothing to do with the product itself, it's that few have ever heard of it.


The most valuable user engagement we can pursue, more valuable than 
emailing them a solicitation for money, is first getting them to use 
LiveCode.


As many as possible.

And to do that it must be as easy as possible to get it.

Anything that lengthens the distance between "What is LiveCode?" and 
"Hey, I'm having a great time with LiveCode!" is holding the platform back.




> In this context, asking for a email address in an attempt to market to
> the people free access to LiveCode is a small thing to ask for.

For the proprietary trial edition, I wholeheartedly agree.

The issue here is specific to the open source Community Edition, and I 
believe it's worth taking the time to explore why the dynamics and 
expectations are so different:



The only value in email is a conversion to a sale.  Everything else 
related to email marketing is expense.


Conversion rates for email aren't zero, but they are commonly understood 
to be low.  In fact, if the hard cost of email marketing wasn't as low 
as it is no one would bother with it at all.  It's that low.


Most SEO brings people to the .com site, so those on the .org site are 
the subset who specifically went there to get the open source edition of 
LiveCode.  The conversion rate there is understandably much lower than 
on the .com site.


After all, someone at the .com site is there to look for a proprietary 
product.  Their interests are very different from the subset who move on 
to .org.  The visitors at .com expect that if they like what they see in 
LiveCode they'll pay.  They're predisposed to conversion.


But open source folks use software for a wide range of reasons, and the 
percentage likely to convert to a proprietary license is *much* smaller.


So while it's difficult to estimate exactly how low the value of an 
email address is to the company, there's little question how 
increasingly valuable maintaining privacy is the many people. And open 
source communities tend to be unusually well educated in matters of 
privacy and security.



Everyone here, proprietary and open source devs alike, wants to see 
LiveCode adoption expand far beyond where it is today.


That is the primary objective of all activities at this time.  Every 
other goal pales by comparison in importance.


Ecosystem size is the driver of both contributions and proprietary 
licenses, and the current small size is the most-cited reason I hear for 
choosing something else.


We need to see teachers using LiveCode, and students, and hobbyists, and 
many other categories who will not pay for a proprietary product, and 
most won't ever contribute code to the project either.


But what they will contribute is credibility for the platform.

Every person using LiveCode reduces the "I've never heard of it" factor.


As Geoff Moore reminds us in Crossing the Chasm, in early stages of 
growth adopters will tend to be the more adventurous personality types, 
those willing to try something new.


Among them will be influencers, the people their friends turn to for 
advice about what software they should use.


When we look at popular development tools today, with a handful of 
exceptions made possible only through historical circumstances that 
cannot be repeated, all of them are open source.


An open source edition is necessary in the 21st century.

And if it's going to serve the dev team at all, it must be pursued 
earnestly.


We can't afford to lose credibility with the audience most sensitive to 
privacy 

mergav exposure

[Mike Kerner via use-livecode]

Is anybody doing anything with mergAV?  It doesn't appear to be a popular
topic.  I'm having a problem with getting the exposure set to "continuous"
- it doesn't seem to do anything, even if I first set it to "auto", which
the docs suggest is the first thing that has to be done.

-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Download LC Community: trapped.

[Richmond Mathewson via use-livecode]

Asking for an e-mail address is a small thing to ask for.

But _forcing_, rather than _asking_, isn't quite the same thing.

 Personal blether starts now ---

I don't feel capable in a big way to contribute to LiveCode development,
so I do try to send bug reports in when I fall over 'bugs'.

I am still wondering about trying to make a simplified interface for 
some sort of
cut-down version of LiveCode using block-programming [ c.f. Scratch and 
so on ].


I was wondering about having a script-editor with blocks . . .

Whether that would actually constitute devloping FOR Livecode is a moot 
point.
One of my motives for considering it is that it might fuel greater 
uptake at the child-teenage-educational
end of the spectrum working on the theory that children who start with 
Livecode via block-programming

might progress to "proper" Livecode programming after a while.

Unfortunately I suspect that my idea is, like the ideas of many would-be 
contributors, quite far
down the list of my day-to-day priorities: running a school, teaching, 
developing my Devawriter Pro,
Professional Development, being a husband and a father, and so on and so 
forth . . . I do hope that
in June/Jult/August I will find both the time and the energy to get 
started on this . . . and, who knows,
some folk may deide to join in the "fun", although I haven't noticed 
much "communal'" stuff going

on in this "community" to be honest.

-- Personal blether ends 

And it is, indeed a gae richt scunner anent maist fowk's glisk til the 
free version, but I for yin

amnae ma brither's keeper nor dictator forbye.

Richmond.

On 3/9/17 11:32 pm, Paul Dupuis via use-livecode wrote:

On 3/9/2017 1:02 PM, Richmond Mathewson via use-livecode wrote:

If you decide you don't wish to donate right now you still have to
specify a name and an e-mail
address.

So: NO anonymous download unless you happen to have previously
bookmarked:

downloads.livecode.com/livecode/

Not good.


In this age of massive invasion of privacy by governments, corporations,
and unpleasant groups and individuals, I can respect not wanting to
provide a name and email address for all sorts of reasons.

However, on the flip side, LiveCode Open Source (which I backed) may
have been a mistake. I backed the Open Source kickstarter for 2 reasons:
(1) in hopes more people would develop for LiveCode; and (2) so the
source would be there in the worst case scenario that LiveCode, Ltd went
kaput. The cost to switch our products to another language would be the
end of our business.

With 75% of downloads being Community, only 25% of the user base is
paying for 100% of the development. The idea being that those that get
LiveCode for free would, in some part, contribute back to the Open
Source effort that, in turn, expands the commercial offerings. The
statistics show that is only minimally happening and not in any way to
support the cost of giving LiveCode to 75% of the user base free. I hope
this changes.

In this context, asking for a email address in an attempt to market to
the people free access to LiveCode is a small thing to ask for.  If the
open source side of the house doesn't add more capabilities to LiveCode
or self-support itself through voluntary contributions to a greater
degree over time, then the practical reality is that it will ultimately
fail.

I hope that it does not fail.



___
use-livecode mailing list
use-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: Download LC Community: trapped.

[Paul Dupuis via use-livecode]

On 3/9/2017 1:02 PM, Richmond Mathewson via use-livecode wrote:
> If you decide you don't wish to donate right now you still have to
> specify a name and an e-mail
> address.
>
> So: NO anonymous download unless you happen to have previously
> bookmarked:
>
> downloads.livecode.com/livecode/
>
> Not good. 


In this age of massive invasion of privacy by governments, corporations,
and unpleasant groups and individuals, I can respect not wanting to
provide a name and email address for all sorts of reasons.

However, on the flip side, LiveCode Open Source (which I backed) may
have been a mistake. I backed the Open Source kickstarter for 2 reasons:
(1) in hopes more people would develop for LiveCode; and (2) so the
source would be there in the worst case scenario that LiveCode, Ltd went
kaput. The cost to switch our products to another language would be the
end of our business.

With 75% of downloads being Community, only 25% of the user base is
paying for 100% of the development. The idea being that those that get
LiveCode for free would, in some part, contribute back to the Open
Source effort that, in turn, expands the commercial offerings. The
statistics show that is only minimally happening and not in any way to
support the cost of giving LiveCode to 75% of the user base free. I hope
this changes.

In this context, asking for a email address in an attempt to market to
the people free access to LiveCode is a small thing to ask for.  If the
open source side of the house doesn't add more capabilities to LiveCode
or self-support itself through voluntary contributions to a greater
degree over time, then the practical reality is that it will ultimately
fail.

I hope that it does not fail.



___
use-livecode mailing list
use-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: Working browser widget/linux-flavour combinations?

[Mark Wieder via use-livecode]

On 03/09/2017 11:55 AM, hh via use-livecode wrote:

I would like to test some browser interaction on linux.

Please, could someone who works with a LC version that has NO
problems with the browser widget tell me this working 32/64 bit
LC version - linux flavour combination?

Thanks in advance.


Just tried it, and surprisingly enough, the browser widget works for me 
in 9.0-dp6.


Nobody is more surprised than I am.
Just a simple smoke test, but even so...
64-bit Linux Mint 17.3 cinnamon.

--
 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: byteLen()?

[Richard Gaskin via use-livecode]

Thanks for that background, Mark.  I always appreciate your informal 
tech notes.


I'm copying only the most relevant parts here - others looking for a 
good reach will want the full post if you missed it:

http://lists.runrev.com/pipermail/use-livecode/2017-March/235278.html


Mark Waddingham wrote:

> This approach means that any multi-codepoint character in Unicode
> still maps to a single byte - and any non-updated code which
> manipulates strings as if they are data will still work (albeit with
> some data loss in regards the original Unicode string - which it
> wasn't written to understand anyway).

I'm not sure I follow that, but it almost sounds like no matter what the 
encoding each char is mapped to one byte, so a 5-chart string like 
"hello" will take up 5 bytes - is that right?


Doesn't feel right, but there's so much to both Unicode and how LC 
handles it that I've lost my confidence with things like this.


Your guidance is appreciated, and perhaps it may help if I describe the 
use-case at hand:


I have some large files I want to open and read as binary (for speed 
mostly; if there's a reason I should be doing that as text let me know), 
then I'll work my way through it looking for substrings, keeping track 
of the byte offsets within the data where those can be found.


Once I have my list of byte offsets, I can save that as a sort of index 
file, and use "seek" or "read at" to go directly to that portion of the 
larger files whenever I need to access that data.


The data files may use a variety of encodings, mostly UTF-8 but I can 
expect Latin-ISO or perhaps even UTF-16.  In short, encoding will may be 
known in advance.


But since I'm working with binary data the whole time, the encoding 
shouldn't matter, should it?


Earlier you wrote:

  the number of bytes in textEncode(tText, kEncoding)

...which implies that I would need to know the encoding (kEncoding), but 
do I really need textEncode for the use-case described here?


--
 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: Working browser widget/linux-flavour combinations?

[panagiotis merakos via use-livecode]

Hi all,

The Browser widget does work as expected in the *64-bit* Linux versions we
officially support. I have an Ubuntu 16.04 VM and I can confirm this.

**However**, several users have reported some strange problems on
particular Linux distros (including Ubuntu 16.04), which although they seem
unrelated to each other, they are actually related.

One of those problems is the "something" dialog. Another problem is the
non-functional Dictionary (note that the Dictionary uses the Browser
widget).

The common factor of all those problems seems to be locale-related. If you
see those problems, the workaround is to launch LC from the terminal using
this command:

LC_ALL= LC_NUMERIC=C "path/to/livecode_executable"

For anyone interested, see bug
http://quality.livecode.com/show_bug.cgi?id=16848 and all the bugs that are
mentioned there.

Best regards,
Panos
--

On Thu, Mar 9, 2017 at 8:54 PM, Richmond Mathewson via use-livecode <
use-livecode@lists.runrev.com> wrote:

> However "showcase" the browser widget may be you should remember that, as
> far as I can see,
> Linux versions come a long way down the food chain.
>
> Richmond.
>
>
> On 3/9/17 10:42 pm, hh via use-livecode wrote:
>
>> Thanks Richmond.
>>
>> There are bug reports from Sept 2016 reporting this 'something'-answer you
>> describe above.
>>
>> I tested with Mint 173 to latest, 32bit. Always had to kill LC 8/9 after
>> the
>> the something-dialog, exactly as reported to LQCC (#17715 and links
>> there).
>>
>> I can not believe that nothing changed since then: The browser widget is a
>> 'showcase'-member of all LC advertising. Should at least basically work.
>>
>> Richmond wrote:
>>> Xubuntu 16.04 64-bit, 8.1.3: "something". Had to KILL Livecode.
>>> As above, 9.0.0 DP-6: no obvious difference. Tut, tut, tut.
>>>
>>
>> ___
>> use-livecode mailing list
>> use-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: Working browser widget/linux-flavour combinations?

[Richmond Mathewson via use-livecode]

However "showcase" the browser widget may be you should remember that, 
as far as I can see,

Linux versions come a long way down the food chain.

Richmond.

On 3/9/17 10:42 pm, hh via use-livecode wrote:

Thanks Richmond.

There are bug reports from Sept 2016 reporting this 'something'-answer you
describe above.

I tested with Mint 173 to latest, 32bit. Always had to kill LC 8/9 after the
the something-dialog, exactly as reported to LQCC (#17715 and links there).

I can not believe that nothing changed since then: The browser widget is a
'showcase'-member of all LC advertising. Should at least basically work.


Richmond wrote:
Xubuntu 16.04 64-bit, 8.1.3: "something". Had to KILL Livecode.
As above, 9.0.0 DP-6: no obvious difference. Tut, tut, tut.


___
use-livecode mailing list
use-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: Working browser widget/linux-flavour combinations?

[hh via use-livecode]

Thanks Richmond.

There are bug reports from Sept 2016 reporting this 'something'-answer you
describe above.

I tested with Mint 173 to latest, 32bit. Always had to kill LC 8/9 after the
the something-dialog, exactly as reported to LQCC (#17715 and links there).

I can not believe that nothing changed since then: The browser widget is a
'showcase'-member of all LC advertising. Should at least basically work.

> Richmond wrote:
> Xubuntu 16.04 64-bit, 8.1.3: "something". Had to KILL Livecode.
> As above, 9.0.0 DP-6: no obvious difference. Tut, tut, tut.


___
use-livecode mailing list
use-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: Working browser widget/linux-flavour combinations?

[Richmond Mathewson via use-livecode]

Never tried it; so have just done:

Xubuntu 16.04 64-bit, 8.1.3: "something"  Had to KILL Livecode.

As above, 9.0.0 DP-6: no obvious difference.

Tut, tut, tut.

sincerely, Richmond.

On 3/9/17 9:55 pm, hh via use-livecode wrote:

I would like to test some browser interaction on linux.

Please, could someone who works with a LC version that has NO
problems with the browser widget tell me this working 32/64 bit
LC version - linux flavour combination?

Thanks in advance.

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

Working browser widget/linux-flavour combinations?

[hh via use-livecode]

I would like to test some browser interaction on linux.

Please, could someone who works with a LC version that has NO
problems with the browser widget tell me this working 32/64 bit
LC version - linux flavour combination?

Thanks in advance.

___
use-livecode mailing list
use-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: Download LC Community: trapped.

[Richard Gaskin via use-livecode]

Richmond Mathewson wrote:

> Until a few days ago, if you went via the OBSCURE green button right
> at the bottom-left of the LiveCode landing page [ www.livecode.com ]
> to the Open Source page [ www.livecode.org ] you could, by clicking
> on the "Download" text at the top of that page go to the download page
> [ www.downloads.livecode.com/livecode/ ].
>
> But now you end up here: http://livecode.org/download-member-offer/
>
> If you don't want a membership you end up here:
> https://livecode,org/download-with-donation/
>
> If you decide you don't wish to donate right now you still have to
> specify a name and an e-mail
> address.
>
> So: NO anonymous download unless you happen to have previously
> bookmarked:
>
> downloads.livecode.com/livecode/
>
> Not good.


Agreed.  We all recognize the value of building a mailing list, but the 
only emails worth sending are to those who want to receive them.


Optional sign-up is excellent.  Requiring personal information just to 
download a binary, not so much.


People are increasingly concerned about privacy, and for good reason. 
The open source community in particular is keenly sensitive to this 
issue; they consider protecting privacy a critical priority.


If we are to expand LC's audience, we want it to be as easy as possible 
for everyone to install it and start building great apps with it.


Anything that impedes that goal should be reviewed.

I've had discussions with the web team on related issues, and will 
encourage them to return to offering unfettered access.


All of us want everyone to enjoy LiveCode, and if we're going to build a 
growing ecosystem we have to remain mindful of details like this along 
the way.


--
 Richard Gaskin
 LiveCode Community Manager
 rich...@livecode.org



___
use-livecode mailing list
use-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: byteLen()?

[Mark Waddingham via use-livecode]

On 2017-03-09 19:06, Richard Gaskin via use-livecode wrote:

Thanks. I don't mind the verbosity, but I could use some clarity:

There's been talk of LC using UTF-16 internally, but when I do this:

on mouseUp
   put "Hello" into s
   put the number of bytes of s
end mouseUp

...I get "5".

When does LC use UTF-16, and when it's not UTF-16 is it still
ISO-8959-1 or UTF-8?


Internally strings are stored as either UTF-16 or in the native encoding 
(MacRoman, Latin-1) depending on the content of the string and such (the 
engine transparently switches internal encoding as necessary). However, 
this is an internal implementation detail - it might do something 
completely different in the future...


Before 7, the idea of 'byte' and 'char' were synonymous - if you used a 
string in the context of something expecting text it interpreted as 
being a string encoded in the native encoding, if you used a string in 
the context of something expecting binary data it interpreted as being 
just plain bytes.


With the advent of 7 it is necessary to treat text and binary separately 
- they aren't the same thing at all for the simple reason that text only 
becomes binary when you choose a specific text encoding and apply it to 
the unicode string.


In order to ensure that code written prior to 7 worked identically in 7 
it was necessary to add an automatic conversion between text and binary 
which preserved the previous behavior which (essentially) viewed text 
and binary strings as being the same thing.


Indeed, in the above code what is actually happening is this:

on mouseUp
  put "Hello" into a
  put the number of bytes of (s)
end mouseUp

One important property which existed before 7 was that:

   the number of bytes in s == the number of chars in s

However, the definition of 'char' changed in 7 to mean a Unicode 
grapheme - something which will often require many bytes to encode in 
any encoding (e.g. [e, combining-acute] is a perfectly valid way to 
express e-acute in Unicode - taking two codepoints, and not one). In 
order to keep the above equivalence (which would break many things if it 
were not kept) the implicit-text-to-data conversion is defined as 
follows:


  repeat for each char tChar in tString
get textEncode(tChar, "native")
if textDecode(it, "native") is tChar then
   put it after tData
else
   put "?" after tData
end if
  end repeat

(Note: The engine does work quite hard to keep things as equivalent as 
possible - it normalizes tString to NFC first so that it doesn't matter 
if the string has passed through a process which has happened to 
decompose it, or if it has come from a source which favours decomposed 
representations - most notably Mac HFS filenames).


This approach means that any multi-codepoint character in Unicode still 
maps to a single byte - and any non-updated code which manipulates 
strings as if they are data will still work (albeit with some data loss 
in regards the original Unicode string - which it wasn't written to 
understand anyway).


In the future, it is entirely possible that we will make it a runtime 
error to implicitly convert between data and string (don't worry, it 
wouldn't be the default behavior) because if you aren't clear about how 
you are doing the conversion (i.e. which conversion you are using) it is 
a potential source of hard to find errors in code.


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: byteLen()?

[Richard Gaskin via use-livecode]

Mark Waddingham wrote:

> On 9 Mar 2017, at 02:37, Richard Gaskin wrote:
>>
>> the len() function returns a character count, but with Unicode this
>> may be very different than the byte size.
>>
>> Do we have a size() or byteLen() function?
>
>
> No, there is no such function as the byte length is a property of
> text which has been encoded with a specific encoding, not text in
> general.
>
> the number of bytes in textEncode(tText, kEncoding)
>
> Should give you what you need.

Thanks. I don't mind the verbosity, but I could use some clarity:

There's been talk of LC using UTF-16 internally, but when I do this:

on mouseUp
   put "Hello" into s
   put the number of bytes of s
end mouseUp

...I get "5".

When does LC use UTF-16, and when it's not UTF-16 is it still ISO-8959-1 
or UTF-8?


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

Download LC Community: trapped.

[Richmond Mathewson via use-livecode]

Until a few days ago, if you went via the OBSCURE green button right at 
the bottom-left of the LiveCode
landing page [ www.livecode.com ] to the Open Source page [ 
www.livecode.org ] you could, by clicking

on the "Download" text at the top of that page go to the download page
[ www.downloads.livecode.com/livecode/ ].

But now you end up here: http://livecode.org/download-member-offer/

If you don't want a membership you end up here: 
https://livecode,org/download-with-donation/


If you decide you don't wish to donate right now you still have to 
specify a name and an e-mail

address.

So: NO anonymous download unless you happen to have previously bookmarked:

downloads.livecode.com/livecode/

Not good.

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

Re: [Long] Moving a REST request from Desktop to Server

[Phil Davis via use-livecode]

+1 Andre -

curl is definitely your friend for simple LC-server to other server 
communication. I maintain a server app that uses it to interact with the 
Vimeo server.


https://curl.haxx.se/docs/

Phil Davis


On 3/9/17 9:11 AM, Andre Garzia via use-livecode wrote:

Hi,

I would shell() to curl or a shell script and parse the result.

om om

On Tue, Mar 7, 2017 at 8:56 PM, Malte Brill via use-livecode <
use-livecode@lists.runrev.com> wrote:


Hi all,

I am trying to move a request I do from a desktop app to a liveCode server
script and am facing the problem that some of the stuff I use (most of it
libURL stuff) is not available on the server. Now I wonder how I could
translate it…

Scenario is the following:
Problem is libURLLastRHHeaders() is unavailable on server and can not
easiely be copied from libURL
Anyone got an idea?

local sCookieHeader

on mouseUp
 local tURL,tUser,tPassWord,tCookie,tSubmitId,tsubmit,tJson,
tJsonArray
 local test
 try
 set the httpHeaders to empty
 put „aUser" into tUser
 put „aPassword" into tPassWord
 put "264812" into tSubmitID
 put "Log+in" into tSubmit
 get libURLFormData("userName", tUser,"password",
tPassword,"submit",tSubmit,"submitID",tSubmitId) — not available on
Server, but can be copied from libURL
 post it to url "http://test.com/login.php;
 _storeCookies libURLLastRHHeaders() — needed to
authenticate. libURLLastRHHeaders unavailable
 set the httpHeaders to sCookieHeader
 put fld "URL" into tURL
 put URL tURL into tJson
 catch theErr
 put theErr
 end try
end mouseUp


## Parse header returned from a server and create a cookie header that
## can be sent back: Cookie: cookie1;cookie2;cookie3;...
private command _StoreCookies pHeader
 local theCharNo,theCookieLine,theLineNo,theOffset
 put empty into sCookieHeader
 put 0 into theOffset
 repeat forever
 put lineoffset("Set-Cookie:", pHeader, theOffset) into
theLineNo
 if theLineNo > 0 then
 add theOffset to theLineNo
 put line theLineNo of pHeader into theCookieLine
 delete word 1 of theCookieLine ## Set-Cookie:
 put offset(";", theCookieLine) into theCharNo
 if theCharNo > 0 then
 delete char theCharNo to -1 of
theCookieLine
 end if
 put theCookieLine & ";" after sCookieHeader
 put theLineNo into theOffset
 else
 exit repeat
 end if
 end repeat
 if the last char of sCookieHeader is ";" then
 delete the last char of sCookieHeader
 end if
 if sCookieHeader is not empty then
 put "Cookie: " before sCookieHeader
 end if
 return empty
end _StoreCookies



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






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

Re: JSON library on LC Server

[Devin Asay via use-livecode]

On Mar 9, 2017, at 10:31 AM, Devin Asay via use-livecode 
> wrote:

Can anyone tell me how/if one can use the JSON library from LC 8 on LC Server? 
I’m running Community Server v. 8.1.2 on a Linux server.

I tried just calling JsonExport() in the .lc script, but it errors. Do I have 
to ‘include’ or ‘start using’ the library somehow?

Answered my own question with another google search. Peter B. answered the 
question in this thread a few months back:

http://lists.runrev.com/pipermail/use-livecode/2015-November/221289.html

So here’s what I did:

Opened the LiveCode.app bundle on my Mac.

Navigated to Contents > Tools > Extensions .

Copied the com.livecode.library.json folder to the same folder on the server 
where my test script is.

Included this statement at the beginning of my .lc test script:

load extension from file "com.livecode.library.json/module.lcm”

Works like a champ!

But I wonder if there’s a less fiddly way to do it. Are these LCB libraries 
included in the LC server installation?

Devin


Devin Asay
Director
Office of Digital Humanities
Brigham Young University

___
use-livecode mailing list
use-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: [Long] Moving a REST request from Desktop to Server

[Andre Garzia via use-livecode]

Hi,

I would shell() to curl or a shell script and parse the result.

om om

On Tue, Mar 7, 2017 at 8:56 PM, Malte Brill via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi all,
>
> I am trying to move a request I do from a desktop app to a liveCode server
> script and am facing the problem that some of the stuff I use (most of it
> libURL stuff) is not available on the server. Now I wonder how I could
> translate it…
>
> Scenario is the following:
> Problem is libURLLastRHHeaders() is unavailable on server and can not
> easiely be copied from libURL
> Anyone got an idea?
>
> local sCookieHeader
>
> on mouseUp
> local tURL,tUser,tPassWord,tCookie,tSubmitId,tsubmit,tJson,
> tJsonArray
> local test
> try
> set the httpHeaders to empty
> put „aUser" into tUser
> put „aPassword" into tPassWord
> put "264812" into tSubmitID
> put "Log+in" into tSubmit
> get libURLFormData("userName", tUser,"password",
> tPassword,"submit",tSubmit,"submitID",tSubmitId) — not available on
> Server, but can be copied from libURL
> post it to url "http://test.com/login.php;
> _storeCookies libURLLastRHHeaders() — needed to
> authenticate. libURLLastRHHeaders unavailable
> set the httpHeaders to sCookieHeader
> put fld "URL" into tURL
> put URL tURL into tJson
> catch theErr
> put theErr
> end try
> end mouseUp
>
>
> ## Parse header returned from a server and create a cookie header that
> ## can be sent back: Cookie: cookie1;cookie2;cookie3;...
> private command _StoreCookies pHeader
> local theCharNo,theCookieLine,theLineNo,theOffset
> put empty into sCookieHeader
> put 0 into theOffset
> repeat forever
> put lineoffset("Set-Cookie:", pHeader, theOffset) into
> theLineNo
> if theLineNo > 0 then
> add theOffset to theLineNo
> put line theLineNo of pHeader into theCookieLine
> delete word 1 of theCookieLine ## Set-Cookie:
> put offset(";", theCookieLine) into theCharNo
> if theCharNo > 0 then
> delete char theCharNo to -1 of
> theCookieLine
> end if
> put theCookieLine & ";" after sCookieHeader
> put theLineNo into theOffset
> else
> exit repeat
> end if
> end repeat
> if the last char of sCookieHeader is ";" then
> delete the last char of sCookieHeader
> end if
> if sCookieHeader is not empty then
> put "Cookie: " before sCookieHeader
> end if
> return empty
> end _StoreCookies
>
>
>
> ___
> use-livecode mailing list
> use-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

JSON library on LC Server

[Devin Asay via use-livecode]

Can anyone tell me how/if one can use the JSON library from LC 8 on LC Server? 
I’m running Community Server v. 8.1.2 on a Linux server.

I tried just calling JsonExport() in the .lc script, but it errors. Do I have 
to ‘include’ or ‘start using’ the library somehow?

Thanks!

Devin Asay
Director
Office of Digital Humanities
Brigham Young University

___
use-livecode mailing list
use-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: breakpoints being ignored

[Dr. Hawkins via use-livecode]

On Thu, Mar 9, 2017 at 7:43 AM, Mike Kerner via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I need to see if I can make it happen, again.  I wonder if going back and
> forth between 9 to do remote debugging and 8 because 9 has issues may be
> causing it.  Will file a bug report if I can repeat it.
>

FWIW . . . when early 7 got too bad, I'd load and save again in 5, reload
in 7, and things usually got a bit better.



-- 
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: breakpoints being ignored

[Mike Kerner via use-livecode]

I need to see if I can make it happen, again.  I wonder if going back and
forth between 9 to do remote debugging and 8 because 9 has issues may be
causing it.  Will file a bug report if I can repeat it.

On Thu, Mar 9, 2017 at 5:58 AM, Ali Lloyd via use-livecode <
use-livecode@lists.runrev.com> wrote:

> These issues sound like they are to do with Script Debug Mode. Please check
> if this is turned on in the Development menu.
>
> Mike, this sounds like it was probably your issue too, especially if
> trashing your prefs fixed it, as Script Debug Mode on is the default.
>
> It *does* sound like there may be a new issue with Script Debug Mode
> getting turned off somehow, which seems worth looking into.
>
> On Thu, Mar 9, 2017 at 6:29 AM Sannyasin Brahmanathaswami via use-livecode
> <
> use-livecode@lists.runrev.com> wrote:
>
> > Interesting… this was happening to me today. on a hunch I set the
> > gRevDevelopment to true… thinking that because I had messed with that
> > yesterday while using the remote debugger on my android phone… I had done
> > something that was blocking script debug --  related to the action of
> > answering "No" to the dialog asking if you want to run a remoteDebug
> > session,  just after installing the standalone on the phone… because I
> > thought (have yet to test/reproduce… very tedious…) possibly that is at
> > least one action that might toggle script debug mode to off (even though
> it
> > appears checked?) and so your break point could possibly be ignored at
> that
> > point and until you reboot LC?
> >
> > Dunno, just was just fishing for possible recipes…
> >
> > but aha, gRevDevelopment, true:  the break point was "honored" Of course
> > it starting stepping through a lot of IDE code, so I had to go back and
> set
> > the gRevDevelopment to "false"  and now the break points work…
> >
> > ….of course if it goes all the way back to 8.1.3 and 6, then it could be
> > anything….
> >
> > BR
> >
> >
> > Mike Kerner wrote:
> >
> > Add a "breakpoint" line as the first line in the script
> > execute again
> > breakpoint still doesn't fire.
> >
> > ___
> > use-livecode mailing list
> > use-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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

[Blog] Infinite LiveCode Progress

[Heather Laine via use-livecode]

Folks, in case any of you missed it, LC9 dp6 has some great new functionality:

https://livecode.com/livecode-9-0-dp-6-infinite-livecode-preview/ 


Enjoy!

Regards,

Heather

Heather Laine
Customer Services Manager
LiveCode Ltd
www.livecode.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: Script Profiler

[Heather Laine via use-livecode]

I made some enquiries from the team on this, and I'm told:

You can only profile a stack, not an individual handler. It profiles the top 
stack when you start the profiler, so you just have to make sure the stack with 
the resizeStack handler is the top stack, then start the profiler.

I hope this helps!

Regards,

Heather

Heather Laine
Customer Services Manager
LiveCode Ltd
www.livecode.com



> On 5 Mar 2017, at 01:07, Ralph DiMola via use-livecode 
>  wrote:
> 
> Both the Remote Debugger and Script Profiler are exciting. There's only one
> of me so I went for the script profiler first. Looked at the LC lesson and
> it seemed simple enough... Enable, do some stuff in your stack and the
> disable. I did that and the Profiler screen pops up but it's empty. Am I
> missing something? How do I set the message/handler level to be profiled?
> Say I want to see how long it takes to resize the stack. I first profile the
> script in the resizestack handler but not any deeper. I then see that one of
> the handlers called in the resizestack hander takes too long so now I want
> to profile just that handler.
> 
> Has anybody got this working?
> 
> Thanks
> 
> Ralph DiMola
> IT Director
> Evergreen Information Services
> rdim...@evergreeninfo.net
> 
> 
> ___
> use-livecode mailing list
> use-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: breakpoints being ignored

[Ali Lloyd via use-livecode]

These issues sound like they are to do with Script Debug Mode. Please check
if this is turned on in the Development menu.

Mike, this sounds like it was probably your issue too, especially if
trashing your prefs fixed it, as Script Debug Mode on is the default.

It *does* sound like there may be a new issue with Script Debug Mode
getting turned off somehow, which seems worth looking into.

On Thu, Mar 9, 2017 at 6:29 AM Sannyasin Brahmanathaswami via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Interesting… this was happening to me today. on a hunch I set the
> gRevDevelopment to true… thinking that because I had messed with that
> yesterday while using the remote debugger on my android phone… I had done
> something that was blocking script debug --  related to the action of
> answering "No" to the dialog asking if you want to run a remoteDebug
> session,  just after installing the standalone on the phone… because I
> thought (have yet to test/reproduce… very tedious…) possibly that is at
> least one action that might toggle script debug mode to off (even though it
> appears checked?) and so your break point could possibly be ignored at that
> point and until you reboot LC?
>
> Dunno, just was just fishing for possible recipes…
>
> but aha, gRevDevelopment, true:  the break point was "honored" Of course
> it starting stepping through a lot of IDE code, so I had to go back and set
> the gRevDevelopment to "false"  and now the break points work…
>
> ….of course if it goes all the way back to 8.1.3 and 6, then it could be
> anything….
>
> BR
>
>
> Mike Kerner wrote:
>
> Add a "breakpoint" line as the first line in the script
> execute again
> breakpoint still doesn't fire.
>
> ___
> use-livecode mailing list
> use-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: should i report it as a bug when a library is not included into a standalone when "search for required inclusions" is selected

[Matthias Rebbe via use-livecode]

Thanks Bob for your comment. I reported it now.

Regards,

Matthias Rebbe




> Am 08.03.2017 um 01:23 schrieb Bob Sneidar via use-livecode 
> >:
> 
> If there is nothing unusual in how you start using the library, like in a do 
> command or something, I think so. 
> 
> Bob S
> 
> 
>> On Mar 7, 2017, at 16:09 , Matthias Rebbe via use-livecode 
>> > wrote:
>> 
>> Hi,
>> 
>> maybe a dumb question, but should i report it as a bug when  a library is 
>> not automatically  included into a standalone when "search for required 
>> inclusions" is selected in the standalone settings?
>> 
>> Regards,
>> Matthias
> 
> 
> ___
> use-livecode mailing list
> use-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: "ouch: the beginning of the end"

[David V Glasgow via use-livecode]

Mark,

This post is hereby awarded the ‘exposition clarity badge’.  You should sew it 
onto your sleeve (with all the others), and wear with pride.

I never felt I understood the problem, let alone possible solutions, and now I 
think I do both.  

A really interesting read, thank you.

Cheers,

David Glasgow


> On 8 Mar 2017, at 11:59 am, Mark Waddingham via use-livecode 
>  wrote:
> 
> Hi Dr Hawkins,
> 
> I've been away on holiday for just over a week, and this thread has got
> quite long, so I thought it easier to answer the original post rather
> than some off shoot on it.
> 
> On 2017-03-03 00:13, Dr. Hawkins via use-livecode wrote:
>> I just got off the phone with the court clerk in Reno, and received the
>> beginning of the end . . .I figured it would come from some state or anther
>> in a year or two, but they are requiring me to use the *exact* pdf as
>> propagated by the court.
> 
> Having read the entire thread, my understanding of your problem is as follows
> (please correct if I am wrong):
> 
> 
> 
> You have PDF forms which are downloadable from a government department. They
> are intended for filling printing and then filling in - i.e. they do not use
> editable PDF forms (FPDF?).
> 
> The government department for whatever reason requires that the forms are used
> exactly as is with the user filling in the relevant spaces within them and 
> then
> submitting.
> 
> There is some claim by said department that 'at some point' they will get
> scanners which will be able to tell whether the original forms were used or 
> not
> thus you are not allowed to recreate the non-user parts of the form.
> 
> 
> 
> Reading between the lines the latter requirements of the department are not
> unreasonable - I suspect they would like to automate their processes as much
> as possible and as such would like to be able to have a computer via OCR or
> whatever suck out the appropriate parts of forms at some point to remove a
> human from the equation.
> 
> Given that there is an obvious 'printing' element involved in this at present
> pixel-perfection is not exactly what they are looking for (unless they are
> imagining they live in a world where all printers are capable of absolutely
> perfect registration - some skew / offset is always going to be present) just
> that whatever software they might use in the future to automate can locate
> the user written parts to suck out - therefore it is reasonable for them to
> require that the non-user sections are relatively laid out and look precisely
> the same as if you printed the original PDF.
> 
> I'll run on these above assumptions for now.
> 
> 
> 
> First of all let me just point out that EPS is definitely *not* what you want.
> 
> EPS is just a PostScript program with appropriate comments describing an
> (optional) pre-rendered thumbnail, and other print related metadata so it
> can be embedded in another document. Rendering EPS properly requires a full
> PostScript interpreter - many programs which 'support EPS' actually only 
> support
> rendering the thumbnail and then only printing on a PostScript printer.
> 
> Indeed, there is a good reason why no non-GPL full open-source PostScript
> interpreter exists (as far as I'm aware at least) - they are complex pieces
> of software which have a high degree of commercial value.
> 
> Whilst Linux and Mac users might be used to transparent PostScript support 
> this
> is only because GhostScript is installed as an innate part of the printing 
> tool
> chain on those platforms - thus this is an innate part of the 'system' and as
> such you can write non-GPL applications which use it as you don't need to 
> distribute
> it with your app. On all other platforms, however, you are looking at having 
> to
> distribute a PS interpreter with your app - and at that point you are hit by 
> the
> GPL (in particular, in your case, it would classify as an 'innate' requirement
> of your application and non-optional and thus virality would kick in).
> 
> So, if you want a PostScript interpreter in your app you are going to have to
> pay $ to license such a thing. (Including such a thing in LiveCode would
> require license fees or development costs way above what most people would 
> want
> to pay for a feature they would probably rarely if ever use and as such it is
> unreasonable to expect LiveCode to support such things cross-platform as part 
> of
> the standard license fee - event at the Business license level).
> 
> One of the main reasons that Adobe created PDF was to avoid needing a 
> PostScript
> interpreter to accurately create 'archival' type quality representations of 
> printable
> documents and to provide a much easier way to edit / amend and modify such 
> documents.
> As PDF is just a data structure the latter can be done with processing a 
> generated
> PDF. As EPS/PS are actually a program all bets are off for editing - the 
> program
> does what it is written to, 

Re: "ouch: the beginning of the end"

[Mark Waddingham via use-livecode]

On 2017-03-08 14:51, Roger Eller via use-livecode wrote:
So... Why not convert the forms to high-res (300+ dpi) PNG or JPEG as 
Mark
suggests as one of the many options, and overlay LiveCode fields to 
create
an app for filling the form?  Once filled in, merge the high-res image 
with
the collected field data into a fresh new PDF generated via the Quartum 
PDF

Library (using 100% LiveCode scripting).

http://users.telenet.be/quartam/pdf4rev/benefits.html



This sounds like a good balance. I should perhaps point out (after my 
previous
slightly 'gloomy' post) that generating PDF files by hand for specific 
cases

is not that hard as they are mostly text files (in their simplest form).

In Dr Hawkins case, it sounds like images + overlaid text is sufficient 
and as
long as the text is ASCII then Quartam PDF's abilities should be more 
than up

to the task.

[ The reason I mention ASCII text here is that one of the hardest parts 
of
generating PDF (and PostScript, to be fair) is actually text rendering. 
As
they are both display/print oriented output formats they require text to 
be
fully processed into positioned glyphs taken from subsets of embedded 
fonts.
If however you stick to ASCII, or the slightly larger standard Adobe 
encodings
with the default PostScript fonts then most of the complexity falls 
away. ]


The hard part about PDF support (at both sides) is generality - which is 
what
you need if you have no control over what PDFs are coming in, or what 
might

need to be printed to PDF.

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