At Tue, 24 Feb 2015 23:01:59 +0100, Jens Axel Søgaard wrote:
> While reading "Embedding into a Program"
>
> http://docs.racket-lang.org/inside/embedding.html
>
> I see that the standard way of embedding Racket is via a dynamic library.
>
> Reading up on iOS and dynamic libraries I notice tha
Jens Axel Søgaard wrote on 02/24/2015 05:01 PM:
I see that the standard way of embedding Racket is via a dynamic library.
Unfortunately, I wouldn't risk an important app to this Racket embedding
approach without a *lot* of prior validation by someone else. (Seems
like it might be begging for
While reading "Embedding into a Program"
http://docs.racket-lang.org/inside/embedding.html
I see that the standard way of embedding Racket is via a dynamic library.
Reading up on iOS and dynamic libraries I notice that dynamic libraries
were not supported before iOS8 (on actual devices - I b
At Tue, 24 Feb 2015 13:54:46 -0500, Eric Dong wrote:
> I would actually think that a good first step would be to port the Racket
> VM
The Racket VM runs on Android. See "racket/src/README" for hints on
building (but it's just cross-compilation as usual), and let us know if
you run into trouble.
I would actually think that a good first step would be to port the Racket
VM, so that business logic can be run in Racket. GUI would be hard of
course, but I think that for the moment being able to run a background
process written in Racket would be "enough" for me, communicating with an
Android GU
lambdanative (http://lambdanative.org) seems to have solved the
cross-platform GUI problem for Gambit, via OpenGL. Perhaps something can
be learned from this for Racket. See the ln_glcore folder inside of
modules at https://github.com/part-cw/lambdanative. (Thanks to vraid on
irc #racket for the
I'm very glad to see a resurrection of the possibility of Racket running on
Android. Although a DrRacket development environment would be nice (with
"appropriate" modifications for touchscreen interaction), I would be happy
to have a runtime environment that supports the Racket GUI, starting with
t
On Mon, Feb 23, 2015 at 8:10 PM, Eric Dong wrote:
> Of course. But it's similar to having C++ programmers write in C. Having C
> support for a device is not having "partial C++ support", and similarly I
> think that having a R5RS-like system supported on Android/iOS is not having
> "partial Racket
Of course. But it's similar to having C++ programmers write in C. Having C
support for a device is not having "partial C++ support", and similarly I
think that having a R5RS-like system supported on Android/iOS is not having
"partial Racket support".
That being said, I'm actually quite curious why
Installing 6.1 on Raspbian is very easy. This is what I've done to install it
in /opt:
cd /opt
wget http://mirror.racket-lang.org/installers/6.1/racket-6.1-src-builtpkgs.tgz
tar -xzvf racket-6.1-src-builtpkgs.tgz
cd racket-6.1/src
mkdir build
cd build
../configure
make; make install
cd /opt
sudo
I'm sure that defining "idiomatic" Racket would be a lively discussion,
but, for purposes of the original discussion, I'll just weaken my
original assertion:
* A good Racket programmer can, acting selflessly, without regard to
his/her personal comfort, draw upon some of his/her Racket experien
I think this is really wrong. Of course, you can program in Racket in a
R5RS style, but it would hardly be idiomatic Racket. Most of my Racket code
is very hard to port to R5RS, due to using features like generics, the
match macro, and for/... loops. As another example, almost all of my
non-trivial
@Stephen I've honestly installed it on several devices now and can't
remember for sure exactly how I installed it on the Pi (it's been a
while). I *think* (and I'm running Raspbian btw) that I'd inititally
simply done "sudo apt-get install racket" and not had any trouble. Though
I think you're ri
[Jens and I have traded a few more messages...]
My guess is that "/usr/bin/gcc" isn't compatible with the SDK in
"/Applications/XCode.app". Jens will adjust his path to use a more
recent gcc already installed on his machine, which I think matches the
current XCode release and probably his "/Applic
>> I'd be interested in helping with iOS apps (writing bindings etc)
>> provided someone
>> solves the initial hurdle: getting Racket to cross compile to iOS and get it
>> running on an emulator (and later an actual phone/tablet).
>
> I've pushed changes to make the Racket runtime system at least c
At Fri, 20 Feb 2015 20:21:45 +0100, Jens Axel Søgaard wrote:
> 2015-02-13 23:08 GMT+01:00 Neil Van Dyke :
> > Anyone have any current/planned projects on compiling Android and iOS apps
> > from Racket?
>
> > So, as an alternative for smartphone/tablet apps, to keep handy as a backup
> > to HTML5,
As much as racket compiling to Java bytecodes (Android/Dalvik or JVM) is
tempting - look how many people are excited by Clojure- it is beyond my
skill and available time.
I was referring to building Racket on ARM/RPi. That you have built Racket
for the Pi is encouraging. Any tips/pitfalls I should
> >A solid Racket VM and GUI for Android and
> >iOS apps would be awesome.
> Agreed, but I'm going to try the Raspberry Pi. If I can succeed targeting
> ARM on a familiar OS then hopefully cross compiling to a mobile OS won't be
> so bad. And 'Minimal Dr Racket' on RPi would be awesome
I got conf
>A solid Racket VM and GUI for Android and
>iOS apps would be awesome.
Agreed, but I'm going to try the Raspberry Pi. If I can succeed targeting
ARM on a familiar OS then hopefully cross compiling to a mobile OS won't be
so bad. And 'Minimal Dr Racket' on RPi would be awesom
S.
On Sun, 22 Feb 2015
A solid Racket VM and GUI for Android and iOS apps would be awesome.
In the interim, two reasons why a solution using an R5RS Scheme might
work well for a lot of Racket people:
* Lots of code written in Racket can actually be written in R5RS almost
as well. (Example: say that the secret sauc
I've always felt that comparing with other systems like Chicken and Gambit
Scheme is counterproductive. Racket's compiler design is rather different
(although I'm not complimenting it: way too many things are written in C).
The ultimate goal of course would be to port the Racket VM to Android and
Sounds like LambdaNative (which looks like it's based on Marc Feeley's
nice Gambit implementation of Scheme) is worth looking into. (Helping a
LambdaNative approach for us is that there are viable ways to share a
lot of app-specific source code between Racket and another Scheme
descendant.)
There is also Clojure on Android, which might be a promising alternative.
http://clojure-android.info/
Justin
On Feb 21, 2015 1:24 PM, "Darren Cruse" wrote:
> I could chime in I've also been interesting in Racket for mobile apps.
> Though I've just been learning Racket (and scheme) the last few
On Sat, Feb 21, 2015 at 12:19:03PM -0600, Darren Cruse wrote:
>
> But in the end I didn't find any perfect answer either.
>
> I came away wishing that somehow Gambit/Lambdanative could be enhanced to
> be Racket compatible... if only I had a magic wand. :)
A viable common subset would be nice.
I could chime in I've also been interesting in Racket for mobile apps.
Though I've just been learning Racket (and scheme) the last few months take
what I say with a grain of salt...
Re-reading the OP's post it sounds like you've actually done Racket based
Phonegap/Cordova apps... I was going to m
FWIW this project targets both android and IOS:
https://github.com/part-cw/lambdanative
On Fri, 20 Feb 2015 at 19:32, Jens Axel Søgaard
wrote:
> 2015-02-13 23:08 GMT+01:00 Neil Van Dyke :
> > Anyone have any current/planned projects on compiling Android and iOS
> apps
> > from Racket?
>
> > So,
2015-02-13 23:08 GMT+01:00 Neil Van Dyke :
> Anyone have any current/planned projects on compiling Android and iOS apps
> from Racket?
> So, as an alternative for smartphone/tablet apps, to keep handy as a backup
> to HTML5, I'm interested again in the idea of compiling Racket to native iOS
> and
Anyone have any current/planned projects on compiling Android and iOS
apps from Racket?
Details...
I'm interested for two reasons right now.
The practical way for most purposes today *should* be to do HTML5
offline apps, which (as standard HTML5 apps) should run on all
smartphones, tablets,
28 matches
Mail list logo
