Release: LiveCode for RPi 6.5.1

[LCfraser]

Version 6.5.1 of LiveCode for the RaspberryPi has now been released. Get it at http://downloads.livecode.com/livecode/ ... ux-arm.arm

New features in this release:

• Based on the official 6.5.1 release
• Includes all the externals included in the x86 Linux Community edition
• Includes the standalone engines for Android-ARM, OSX (PPC+x86 Universal), Win32, Linux-x86 and Linux-RPi

One caveat is that the standalone builder has not been modified to produce Linux-RPi standalones yet. I shall fix this ASAP and release a patcher that modifies the builder to be able to do this. Ideally, this patcher will be able to add RPi standalone support to the IDE running on any platform.

Enjoy!

[ramav]

Hi: I have posted to various other sub-forums. Am not sure which ones you have the time to read, so sorry if this duplicates, but...is the Linux-ArM (RPI) standalone builder working? It seems to build fine with no error messages on a RPi using LC v6.5.1 that you had posted in December, but the "executable" does not work even with execute bit enabled. Thanks for any suggestions...
Best regards
Rama

[[-hh]]

..........

[ramav]

Fully understand, and without hyperbole and in all sincerely, I would say that if there were a Nobel Prize in CS, Mr. Fraser would be my top nomination. I cannot overemphasize the future of ARM in 21st century computing over the next decade. In particular, look for ultralow power ARMs and then the sky is the limit with programming for the masses using Livecode, especially in impoverished regions of the world where even a few dollars and scaling down of energy needs makes a big difference. With standalones, you can distribute lessons, online reviews linked to the cloud, whatever, without having to have the IDE in place. Again, could probably get by with a 1 or 2 GB SD on RPI . [I took the RPI noob distribution, deleted all the options except Raspbian, and then installed, and it is one of the slimmest Linuxes I have seen!] It seems like MR. Fraser has brought us tantalizingly close to this goal with a beautiful port of the IDE that works _flawlessly_ (I tested against the complex Google Wallputer app that i presented at the San Jose LC conference in 2011). I am not asking for standalones for every platform, but only requesting to "activate" the builder for ARM LINUx, since Mr. Fraser says
"Includes the standalone engines for Android-ARM, OSX (PPC+x86 Universal), Win32, Linux-x86 and Linux-RPi". [I understand the Andorid builder is a more labor intensive problem because of the lack of ARM SDK for Android, which in itself is a commentary on the "standards" that are in place to support so called open source Android...]

best regards
Rama

[LCfraser]

Hi Rama,

Hermann is right - I've been very busy with other things unfortunately. Real-life gets in the way sometimes! I'm not too far off getting the standalone builder working for RPi; I just need to tidy things up and do some testing to make sure everything still works properly. I'll post a message to this forum when it's ready for release.

Thanks,
Fraser

[ramav]

Hi:
Any updates on the standalone builder for Raspberry Pi ARM Linux? Looking forward to hearing about this. Thanks.
Rama
May 2014

[LCfraser]

None so far, unfortunately. The problem with todo lists is that new things tend to get inserted at the top so older things get further and further down the list... Thanks for the reminder, though.

Hopefully I'll be able to make some more time for RPi stuff once we get 7.0 to the RC or release stage.

[jwkuehne]

6.5.1 runs on the RPi 4! This is great for my work, because the 7 and 8 series were broken for sockets (sockets were fixed partway through 8 after I submitted the bug report.) I know there are a few bugs left in 6.5.1, but it is a great desktop release for machines that support 32-bit programs.

I'm surprised that 6.5.1 is not in the Raspbian programming languages repertoire. It should be.

I'm using 6.5.1 to control a 2.1m telescope, along with Matlab and back-end control written in Ada. You can see my Livecode application in action near the end of this video: https://www.youtube.com/watch?v=vB2luJRjMtM

Building standalone stacks is easy: just rename the x86 engine directory, and substitute a symbolic link with the same name to the ARM directory. The builder will then use the ARM engine instead of x86. I'm very grateful to the builder, and I wish I had the skill to build the latest version.

The RPi 4 is pretty fast, has models with 8Gb memory, and importantly has the full latest gcc, including Ada and gfortran, which are absolute requirements for me. Last time I visited the RPi, it was a toy. It still is a toy, but maybe good enough as a replacement for some of my control computers. The SD card reliability is much better with dynamic wear-leveling and huge capacity for the wear-leveling algorithm. Mounting /tmp and /var/log as tmpfs, along with linking home directory .cache and other possible offenders to /tmp eliminates the worst SD Card killers. People thrashing databases will still need a suitable external USB3 drive.

[jwkuehne]

Unfortunately, 6.5.1 has a memory leak on my RPi4. Just repeatedly put the long time into a a field or button label, i.e. a clock field, at full bore, and you'll see memory creep up in top, and eventually end with a crash. Building Pi standalone programs isn't going to be easy, whether built natively on the Pi or with a cross-compiler in x86 Linux. Heck, I can't even build 9.6.2 from source on Ubuntu 14LTS, although I can build 8.1.10.

[bogs]

Heya John,

I actually watched the video, interesting stuff!

I did have a few questions about other things in your posts, though.

Building standalone stacks is easy: just rename the x86 engine directory, and substitute a symbolic link with the same name to the ARM directory. The builder will then use the ARM engine instead of x86. I'm very grateful to the builder, and I wish I had the skill to build the latest version.

If you could go into a bit more depth on this, with possible screen shots, I'd like to hear about it.

Unfortunately, 6.5.1 has a memory leak on my RPi4. Just repeatedly put the long time into a a field or button label, i.e. a clock field, at full bore, and you'll see memory creep up in top...

What does "full bore" refer to? How many repeats are you talking (in general) to see the memory creep in top? Do you have to use a repeat loop, or does the memory leak also happen in a "send to me in time" structure? And lastly, is this only on Pi, or can it be recreated anywhere?

Thanks in advance for taking time to provide any (or all) of the answers

[jwkuehne]

It doesn't matter if you use a repeat forever or send: memory still leaks. The only thing that prevents the leak is to make the field or button invisible. You will notice the leak if your application continually changes half a dozen fields at 10Hz, and it will really eat memory if you let it run full bore, i.e. as fast as it goes without any delay in the loop. I haven't tried 6.5.1 on OS X, Linux, or Windows since it came out and didn't work for me. For my program, 6.1.3 was the last '6' series that was stable across all three platforms, and I use 6.1.1 because I know where its bugs are and how to avoid them. '7' was completely broken because it couldn't read from socket x for y. This was corrected part way through '8' after I reported the bug. With the requirement for 64-bit applications in OS X and some Linux distros, I have to make the leap from 6.1.1 eventually or go some other route. My penchant for Pi4 is that it's GNU/Linux friendly with GNAT/Ada, cheap, low-powered, plenty fast, has GPIO for machine control, and I can work around the SD card fragility problem for my application.

On my Pi4 the problem manifests in 6.5.1 with

on openstack
repeat forever
put the long seconds into field "leak"
end repeat
end openstack

I haven't tried on Pi3 etcetera.

[bogs]

Mkay, so it is the long seconds and not the long time, as originally stated.

Guess it ain't a factor on x86-64 'nix anyway, mem. use went from 2.1 GB to 2.3 GB, then dropped back to 2.1 GB after a while. Processor was up around 87% across 3 cores, but I would expect that in this kind of workout.

I'm a little curious as to why use long seconds, instead of the milliseconds, since the reporting is more likely a little more accurate in the milliseconds than the long seconds ?



After reading your setup, I ran it this way (since you said it makes no difference) -

Code: Select all

on mouseUp
   putSecs
end mouseUp

on putSecs
   wait 0 milliseconds with messages
   put the long seconds into field 1
   put the milliseconds into field 2
   send putSecs to me in 0 milliseconds
end putSecs

This was using 6.5.1.

I can't say I really understood this -

You will notice the leak if your application continually changes half a dozen fields at 10Hz

but then, I'm probably not quite bright either heh.

Just as a "btw", I'm rarely up this far in versions, usually I am hovering around 2.5 (or lower). Good luck on whatever it is your doing.

*Edit - you made me curious about how many bugs and which versions, so I went into the db and took a look by versions.

I must say, I find the results a little hard to believe. v6.1.3 lists 15 confirmed bugs. v6.5.1 lists 11 confirmed bugs. 6.7.9, though, had no confirmed bugs listed, and only by listing bugs from all states was I able to find 8 ... !?



Didn't anyone use 6.7.9 aside from Craig ?

[jwkuehne]

It doesn't matter what you put in the field - I just gave the long time or the long seconds so you could see the field change. On Raspberry Pi 4 running the Raspberry Pi OS, LC 6.5.1 memory will go up until it crashes.

[FourthWorld]

jwkuehne, do you see the same issue if you run Bogs' script?

[bogs]

On Raspberry Pi 4 running the Raspberry Pi OS, LC 6.5.1 memory will go up until it crashes.

I believe him, the one thing I *don't* have (well, more than one thing I don't have, but this I can't even emulate) is a rPi of any vintage.

Only someone else with a Pi could test this combo, and, even if I had a pi of that vintage, I didn't completely understand his directions as I stated here:

I did have a few questions about other things in your posts, though.

jwkuehne wrote: ↑
Fri Jun 04, 2021 10:14 am
Building standalone stacks is easy: just rename the x86 engine directory, and substitute a symbolic link with the same name to the ARM directory. The builder will then use the ARM engine instead of x86. I'm very grateful to the builder, and I wish I had the skill to build the latest version.

If you could go into a bit more depth on this, with possible screen shots, I'd like to hear about it.

but John didn't post a step by step.