[GTALUG] Looking for Someone to Answer some Question
xerofoify
xerofoify at gmail.com
Wed Jan 16 11:57:16 EST 2019
On Tue, Jan 15, 2019 at 10:53 PM William Park via talk <talk at gtalug.org> wrote:
>
> On Tue, Jan 15, 2019 at 07:49:15PM -0500, Kevin Cozens via talk wrote:
> > On 2019-01-14 12:35 a.m., William Park via talk wrote:
> > > It so happens that I'm looking for interpretor suitable for embedded
> > > applications. I read up on "Lua". Maybe there are other options?
> >
> > Without knowing your intended use case(s) it is hard to know what
> > language(s) would be considered suitable. Other options are implementations
> > of interpreted C, Forth, or dare I say, BASIC.
>
> My working environment is 256MB storage, 256MB ram, F2FS filesystem,
> ARM cpu, stripped down Linux kernel, and Busybox. Most things are
> written in C. But, comments and requests from customers, nowdays, are
> more "web" direction. So, if we write web apps, I'm wondering whether
> we shoud write all those CGIs in C or some interpreted language. It
> doesn't have to be that fast, as long as it's not too slow. :-)
>
> Main feature I need is ability to save "state" of some data structure,
> say variables, array, or dictionary, without having to parse/reparse
> when writing/reading from filesystem. Python can do that. I can do
> that in C too. My last choice would be SQLite, though, it has its
> advantages.
> --
> William Park <opengeometry at yahoo.ca>
> ---
> Talk Mailing List
> talk at gtalug.org
> https://gtalug.org/mailman/listinfo/talk
This is my reply to both Tim first.
Tim: My Recommendations would be to see if you can find an embedded
version of SQLite or another
library that meets your requirement. For CGI I am not sure but maybe
Perl has a light weight version
if your willing to look at the Perl CPAN or other ecosystems.
Kevin: I talked to Christ Tyler and seems he has contacts at AMD and
google for GCC/Graphics. As for
embedded systems I will need to think about what parts I am interested in them.
Thanks for all the help for everyone,
Nick
More information about the talk
mailing list