Re: LC and Raspberry PI

2019-03-27 Thread hh via use-livecode
RaspberryPi has an own subforum
http://forums.livecode.com/viewforum.php?f=76

For Raspi special interfaces use (the fastest) LC 6.5.1 and
the python libraries via shell.


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


Re: LC and Raspberry PI

2019-03-27 Thread JJS via use-livecode

Hi Bill,


i just did some tests with a steppermotor and a Raspberry in Raspbian. 
It works but did not have time to explore further.


The highest LC version now to use is 7.04

Maybe a new version will come but i don't think there is a hurry with 
it. Probably a small market for it.


But it works and you can make an executable also with 7.04, check the 
downloads page.



Cheers,

Jerry

Op 27-3-2019 om 21:41 schreef prothero--- via use-livecode:

Folks:
I’m buying a birthday present for my 14 yr old grandson who likes to play 
computer games, does Lego Robotics, and is somewhat ADD. I’m thinking of buying 
him a Raspberry PI starter kit and an interface kit. These things run on 
javascript in processing and python, and other languages, but I’m wondering if 
anybody has used Livecode to interact with the Raspberry PI.

Any hints, experience, or other thoughts would  be most welcome.
Best,
Bill

William A. Prothero
Santa Barbara, CA. 93105
http://earthlearningsolutions.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


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

LC and Raspberry PI

2019-03-27 Thread prothero--- via use-livecode
Folks:
I’m buying a birthday present for my 14 yr old grandson who likes to play 
computer games, does Lego Robotics, and is somewhat ADD. I’m thinking of buying 
him a Raspberry PI starter kit and an interface kit. These things run on 
javascript in processing and python, and other languages, but I’m wondering if 
anybody has used Livecode to interact with the Raspberry PI.

Any hints, experience, or other thoughts would  be most welcome.
Best,
Bill

William A. Prothero
Santa Barbara, CA. 93105
http://earthlearningsolutions.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: LC for Raspberry Pi

2017-03-13 Thread Richard Gaskin via use-livecode

Mike Kerner wrote:

> Pi is interesting to me because of what I can, in theory, build with
> it, but for the same reason so are many other things.  Pi isn't going
> to bring revenue to LC, IMHO, the way that some of those other tools
> can...

Not directly, at least not short-term.  But as hh pointed out, in any 
given pool of users inevitably some will want a proprietary license.


And in the meantime, 100% of everyone using LiveCode participates in 
lowering the biggest impediment to sales, the "I've never heard of it" 
factor.



> but being able to brag about being the easy-to-use IDE for PI would
> be cool.

A lightweight IDE can be useful on other systems as well, such as older 
low-powered PCs.


For example, I've been putting off upgrading my laptop, and aside from a 
few of the more complex web pages for the most part it's quite fine.


Until I use LC, that is.  Script editing on that 1.6 GHz CPU is merely 
annoying, but debugging is prohibitively slow, taking at least 20 
seconds for each "Step Into".


Some years ago I started working in a lightweight debugger with Ken Ray, 
initially for the MC IDE but later it occurred to me that as a 
self-contained thing it would be useful in a standalone as well.



I turned that on and went back to debugging - smooth as silk, even on my 
old laptop.


Now I'm considering going back to making my own script editor, so I can 
get lean clean typing without all the CPU-hogging real-time formatting 
that slows down LC's Script Editor.


I can understand why the LC IDE so often errs on the side of 
completeness, and has such, shall we say, "thorough" code, to provide 
the many conveniences it does.


But on the flipside, I've discovered I'm not the only one who prefers 
raw typing, with formatting happening only when I explicitly invoke it. 
Removing auto-formatting and other "thoroughness" can make editing a 
breeze - the field object is, after all, quite nice.


And with debugging, I haven't traced out LC's code but it seems to be 
doing a LOT of work for its UI on top of the parts necessary for 
stepping through code.  Indeed, that was one of the reasons Ken and I 
separated the Script Editor from the Debugger, to allow for two 
different UIs, each dedicated to the task it supports.


The LC engine in v9 is satisfyingly performant in my experience.  A lean 
IDE that can really show it off would not only open up editing on the 
RPi, but also on older systems for which the official IDE is simply too 
cumbersome.


--
 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: LC for Raspberry Pi

2017-03-12 Thread hh via use-livecode
People who are using a Raspi and try or even use LC on it may be inclined to
try or use LC if they 'expand' to a tablet or desktop.

And their own creations will work after no or small adjustments, WOW. This
may cause (delayed) revenue to LC.

> Mike K. wrote:
> Pi is interesting to me because of what I can, in theory, build with it,
> but for the same reason so are many other things.  Pi isn't going to bring
> revenue to LC, IMHO, the way that some of those other tools can, but being
> able to brag about being the easy-to-use IDE for PI would be cool.

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


Re: LC for Raspberry Pi

2017-03-12 Thread Mike Kerner via use-livecode
Pi is interesting to me because of what I can, in theory, build with it,
but for the same reason so are many other things.  Pi isn't going to bring
revenue to LC, IMHO, the way that some of those other tools can, but being
able to brag about being the easy-to-use IDE for PI would be cool.

On Sat, Mar 11, 2017 at 5:14 PM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> hh wrote:
>
> > Richard.
> >
> > Thanks for your engagement. I would like to second this with 98%.
> >
> > Let me correct two of your statements (the missing 2%).
> >
> > 1.
> >> RG wrote:
> >> The last RPi build was v704, which is generally good with one
> >> critical issue:  a bug in the menu handling routine causes a crash
> >> when clicking in a menubar.
> > That's wrong in that generality. I have four Raspi's running
> > (one A with Debian, two B+ with Lubuntu or Debian resp., one 3 with
> > Xubuntu or Debian resp., the Debian needs to be first installed on
> > a 2B+, see forum). So install an appropriate OS and it works. Though
> > 3-5 imes slower than v651.
>
> It's nice to know it can work well with certain distros, but for myself
> (focused on a goal of adoption) an "appropriate OS" is the one most
> commonly used.  I ran my tests on the latest stock Raspian most prominently
> available at raspberrypi.org at the time.
>
> If LC won't run on the most common build (and it seems to except for that
> one bug), it's time for a fresh compile.  Hopefully it won't be much longer.
>
>
> > 2.
> >> RG wrote:
> >> So for me, if I had to deliver a GUI for RPi I'd much rather use a
> >> workflow similar to what we do with mobile:  develop on a fully-
> >> spec'd desktop machine, and deploy to the device.
> >
> > If "I'd" means "I would" then I'd say once again (I told you in the
> > forum):
> > This is the way I did from the beginning of the existence of __LC
> > 704__, which is the only one that has a Raspi-deployment option
> > (Linux ARMv6-HF).
> > Simply copy the standalone created on your desktop box to your Raspi
> > via sftp (what may be even scripted) or via an USB stick.
> >
> > So if developers optimize for speed (as LC 7 is 3-5 times slower than
> > LC 6) they can have this, since years. By ONE click and ONE data
> > transfer.
>
> When we get a fresh build with v9 I think we'll see many speed
> improvements in the RPi engine (see earlier reply to jonathandlynch).
>
> V6 is nice, but old.  It would be ideal to keep formats and features in
> sync with the rest of the LC world.
>
> And the work Fraser and other have done in v7 and v8 for better GTK
> integration has been superb, at least in the Gnome-based DE's I'm using
> (Unity in Ubuntu and LXDE in Lubuntu).
>
> But regardless of version, it seems we're on the same page with a worklow
> that favors building on the desktop and running on the RPi.
>
> In fact, this morning I was curious about Xojo's system requirements for
> their RPi deployments, and it seems Xojo isn't available for RPi - that is,
> not the IDE.  They have a runtime engine only, so the workflow they require
> is the same one you and I recommend with LC, building on desktop to run on
> RPi.
>
> Still, given the many EDU use cases where having an IDE on the RPi would
> be desirable, I'd like to explore options for a lightweight IDE down the
> road (though probably way down the road for me; lots of other priorities
> before that).
>
> --
>  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
>



-- 
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: LC for Raspberry Pi

2017-03-11 Thread Richard Gaskin via use-livecode

hh wrote:

> Richard.
>
> Thanks for your engagement. I would like to second this with 98%.
>
> Let me correct two of your statements (the missing 2%).
>
> 1.
>> RG wrote:
>> The last RPi build was v704, which is generally good with one
>> critical issue:  a bug in the menu handling routine causes a crash
>> when clicking in a menubar.
> That's wrong in that generality. I have four Raspi's running
> (one A with Debian, two B+ with Lubuntu or Debian resp., one 3 with
> Xubuntu or Debian resp., the Debian needs to be first installed on
> a 2B+, see forum). So install an appropriate OS and it works. Though
> 3-5 imes slower than v651.

It's nice to know it can work well with certain distros, but for myself 
(focused on a goal of adoption) an "appropriate OS" is the one most 
commonly used.  I ran my tests on the latest stock Raspian most 
prominently available at raspberrypi.org at the time.


If LC won't run on the most common build (and it seems to except for 
that one bug), it's time for a fresh compile.  Hopefully it won't be 
much longer.



> 2.
>> RG wrote:
>> So for me, if I had to deliver a GUI for RPi I'd much rather use a
>> workflow similar to what we do with mobile:  develop on a fully-
>> spec'd desktop machine, and deploy to the device.
>
> If "I'd" means "I would" then I'd say once again (I told you in the
> forum):
> This is the way I did from the beginning of the existence of __LC
> 704__, which is the only one that has a Raspi-deployment option
> (Linux ARMv6-HF).
> Simply copy the standalone created on your desktop box to your Raspi
> via sftp (what may be even scripted) or via an USB stick.
>
> So if developers optimize for speed (as LC 7 is 3-5 times slower than
> LC 6) they can have this, since years. By ONE click and ONE data
> transfer.

When we get a fresh build with v9 I think we'll see many speed 
improvements in the RPi engine (see earlier reply to jonathandlynch).


V6 is nice, but old.  It would be ideal to keep formats and features in 
sync with the rest of the LC world.


And the work Fraser and other have done in v7 and v8 for better GTK 
integration has been superb, at least in the Gnome-based DE's I'm using 
(Unity in Ubuntu and LXDE in Lubuntu).


But regardless of version, it seems we're on the same page with a 
worklow that favors building on the desktop and running on the RPi.


In fact, this morning I was curious about Xojo's system requirements for 
their RPi deployments, and it seems Xojo isn't available for RPi - that 
is, not the IDE.  They have a runtime engine only, so the workflow they 
require is the same one you and I recommend with LC, building on desktop 
to run on RPi.


Still, given the many EDU use cases where having an IDE on the RPi would 
be desirable, I'd like to explore options for a lightweight IDE down the 
road (though probably way down the road for me; lots of other priorities 
before that).


--
 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: LC for Raspberry Pi

2017-03-11 Thread Richard Gaskin via use-livecode

jonathandlynch wrote:

> Why is LC 7 slower than 6?

There may be additional factors specific to the RPi build, but in 
general those differences were due to Unicode support and unoptimized 
refactoring related to that and other large-scale scopes of work.


With v9 much of the earlier performance drop has been regained, with key 
work on done common things like lineoffset and some other chunk 
expressions, arrays, and more.


Some rendering operations may still benefit from optimization, esp. on 
Windows, but overall I've not seen much in that area on Linux.


Given the larger data sizes of some Unicode strings you can still expect 
some performance loss in some areas, but in my experience nothing like 
moving from v6 to v7.


If you come across anything prohibitive please submit a bug report.  The 
team has worked through a number of performance-related bug reports, and 
sometimes when they see a new recipe it'll alter them to opportunities 
they hadn't considered.


The lineoffset fix was among those.  In v6 and earlier chunk delimiters 
could only be a single character, but v7 introduced multi-char 
delimiters.  Kinda cool if you need it, but a more costly substring 
compare is needed to support that.  With v8 they were able to fork the 
operation so that when a delimiter is only a single char it uses the 
older routine, saving the cooler-but-costlier substring compare only for 
when needed.


--
 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: LC for Raspberry Pi

2017-03-11 Thread Jonathan Lynch via use-livecode
Why is LC 7 slower than 6?

Sent from my iPhone

> On Mar 11, 2017, at 3:50 PM, hh via use-livecode 
>  wrote:
> 
> Richard.
> 
> Thanks for your engagement. I would like to second this with 98%.
> 
> Let me correct two of your statements (the missing 2%).
> 
> 1.
>> RG wrote:
>> The last RPi build was v704, which is generally good with one critical 
>> issue:  a bug in the menu handling routine causes a crash when clicking 
>> in a menubar.
> That's wrong in that generality. I have four Raspi's running
> (one A with Debian, two B+ with Lubuntu or Debian resp., one 3 with Xubuntu
> or Debian resp., the Debian needs to be first installed on a 2B+, see forum).
> So install an appropriate OS and it works. Though 3-5 imes slower than v651.
> 
> 2.
>> RG wrote:
>> So for me, if I had to deliver a GUI for RPi I'd much rather use a workflow
>> similar to what we do with mobile:  develop on a fully-spec'd desktop 
>> machine, and deploy to the device.
> 
> If "I'd" means "I would" then I'd say once again (I told you in the forum):
> This is the way I did from the beginning of the existence of __LC 704__,
> which is the only one that has a Raspi-deployment option (Linux ARMv6-HF).
> Simply copy the standalone created on your desktop box to your Raspi via sftp
> (what may be even scripted) or via an USB stick.
> 
> So if developers optimize for speed (as LC 7 is 3-5 times slower than LC 6)
> they can have this, since years. By ONE click and ONE data transfer.
> 
> 
> ___
> 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: LC for Raspberry Pi

2017-03-11 Thread hh via use-livecode
Richard.

Thanks for your engagement. I would like to second this with 98%.

Let me correct two of your statements (the missing 2%).

1.
> RG wrote:
> The last RPi build was v704, which is generally good with one critical 
> issue:  a bug in the menu handling routine causes a crash when clicking 
> in a menubar.
That's wrong in that generality. I have four Raspi's running
(one A with Debian, two B+ with Lubuntu or Debian resp., one 3 with Xubuntu
or Debian resp., the Debian needs to be first installed on a 2B+, see forum).
So install an appropriate OS and it works. Though 3-5 imes slower than v651.

2.
> RG wrote:
> So for me, if I had to deliver a GUI for RPi I'd much rather use a workflow
> similar to what we do with mobile:  develop on a fully-spec'd desktop 
> machine, and deploy to the device.

If "I'd" means "I would" then I'd say once again (I told you in the forum):
This is the way I did from the beginning of the existence of __LC 704__,
which is the only one that has a Raspi-deployment option (Linux ARMv6-HF).
Simply copy the standalone created on your desktop box to your Raspi via sftp
(what may be even scripted) or via an USB stick.

So if developers optimize for speed (as LC 7 is 3-5 times slower than LC 6)
they can have this, since years. By ONE click and ONE data transfer.


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


LC for Raspberry Pi

2017-03-11 Thread Richard Gaskin via use-livecode

In another thread  Mark Rauterkus wrote:

> The other HUGE area where I think LiveCode could shine is with the
> Raspberry Pi community. But, sadly, the mothership is not putting
> support there for confidence to take root, IMHO. So, that remains
> only a dream. An annual release for Pi would be most welcomed.

I agree, an RPi update would be great.  But I'm not sure this needs to 
be a company effort, and to be honest we've seen only a few in our 
community actually interested in participating to maintain it.


But we do have some, and the team made some updates to the Github repo 
to help that along.


I set up a thread for this project in the forums:
http://forums.livecode.com/viewtopic.php?f=76=27912

At this point we're down to just a few specific questions we need some 
guidance on, and I've seen a note on the LC Gitter feed from someone who 
successfully made an RPi build from the 8.1.3 code base, so we know it's 
possible.


Let me take a moment to outline near-term and long-term goals for the 
Raspberry Pi project, and encourage anyone here interested in helping to 
move this forward to jump into the forums at the link above.


Near-Term
-
The last RPi build was v7.0.4, which is generally good with one critical 
issue:  a bug in the menu handling routine causes a crash when clicking 
in a menubar.


This currently prevents the IDE from being run on the RPi itself, which 
of course we'll want to see for EDU adoption (with some caveats noted 
below in "Long-Term").


But for any GUI that doesn't use menus that doesn't stop RPi from being 
a deployment platform.  Check out the 7-pages-and-growing thread by -hh 
chock full o' stacks designed specifically for the RPi:



It also doesn't prevent what is to me the most interesting use of RPi: 
IoT.  Such devices will not usually need a UI of their own, and LC 
Server v7.0.4 runs great on RPi, as do standalones run facelessely with -ui.


With GUI control of the device handled from a desktop app or a mobile 
app on your Android or iOS device, the range of interesting things that 
can be done with LC on RPi are vast, even with the limitations of the 
v7.0.4 engine.


Once we get the build process set up for 8.x and 9.x, we should be in 
very good shape to handle any remaining issue (though I suspect with all 
the good work done for the Linux engine since v7 we may find the menu 
issue has already been resolved).



Long-Term
-
RPi is great.  And RPi also sucks.  :)

It's great because it's small and cheap.  And it sucks for the same 
reasons:  little RAM, and very slow.


In fact, while I do keep an SD card loaded with a GUI OS just for 
playing around, I find any GUI on RPi (including the bundled browser and 
even the desktop manager) to abysmally slow to be satisfying.


So for me, if I had to deliver a GUI for RPi I'd much rather use a 
workflow similar to what we do with mobile:  develop on a fully-spec'd 
desktop machine, and deploy to the device.


And as long as that's what you're doing, LC is a great experience.

But then we consider classrooms in which the RPi is the only device the 
kids work with.  There, developing on a full-featured desktop machine 
won't be an option.


The LC IDE is a rich system, but requires a lot of RAM and a rather huge 
amount of disk space (> 1 GB in recent versions).


These resource requirements cause LC to strain the RPi, esp. RAM but 
also CPU (instruction sets matter; 1.2 GHz on x86 doesn't necessarily 
equate to the same clockspeed on ARM, though compiler options may be 
able to help with some of that).


So even when we update LC's RPi engine to v9, it'll run robustly but 
slowly.  Painfully slowly.


So at some point, if there's enough interest in using an LC-based IDE 
directly on the RPi, we may want to consider making a lightweight IDE 
for that.


That might seem daunting, and it's certainly not a trivial task.  But 
the MC IDE reminds us that it's doable.


Given that the MC IDE is available under MIT license, it may be a 
tempting starting point.


But it's quite old; it doesn't support many newer features the engine 
provides, and uses a very different means of building standalones 
(indeed I doubt MC's standalone builder even works at all in newer 
versions).


Perhaps the best path would be a fresh start, taking advantage of newer 
language features and a better understanding of workflow needs to create 
a fresh approach designed specifically for low-end systems.


And maybe it doesn't need to include a standalone builder, at least not 
at first.  A runner app that plays stacks would be more than fine for 
EDU settings.


In fact, in some ways it might even be better. One of my back-burner 
projects is an EDU-focused toolkit that, among other things, has network 
stack-sharing built in.


Imagine a world of students using any computer, all sharing stacks 
easily with one another


The runner could be built now.  That part's