[racket] compiling Racket to android and ios apps

[Neil Van Dyke]

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, and desktops. I have done this in conjunction
with Racket on the server, and Racket also generating much of the HTML
and JS. This is either in a standard HTML5 offline app way that is
sandboxed and also bypasses the official app store, or packaged as a
platform-specific app with PhoneGap. However, the biggest complication
with real HTML5 apps is that Apple seems to be doing its best to drag
its feet and/or break HTML5 apps whenever it can. (It's almost as if
Apple actually wants to keep developers captive to their infamously
heavy-handed app store policies and competition-killing maneuvers. I
know, I know, I find that as difficult to believe as you do. It's a
head-scratcher, for sure.)

When iOS is the most lucrative app platform, and it looks like you're
vulnerable to a competitor coming in *after* your first-mover advantage,
and taking away your app's iOS market share by virtue of their app not
being crippled by Apple like yours is, this is a problem.

Separately -- and this is more an issue because of the above handicap --
there's also the nagging issue of sometimes wanting to hide
closed-source "secret sauce" code to some extent from lazy
app-counterfeiters, without moving it to the server and requiring the
device to be online and phone-home with user's private data. A high
degree of obfuscation would help.

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 Android apps. Typical polished commercial-grade apps, so
pedagogic graphics worlds alone usually aren't enough.

Neil V.

____________________
Racket Users list:
http://lists.racket-lang.org/users

[Jens Axel Søgaard]

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 Android apps. Typical polished commercial-grade apps, so pedagogic
graphics worlds alone usually aren't enough.

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

There might be some hints (wrt compiler switches) here:

https://github.com/feeley/gambit/blob/master/misc/build-gambit-iOS

/Jens Axel
____________________
Racket Users list:
http://lists.racket-lang.org/users

[Stephen De Gabrielle]

FWIW this project targets both android and IOS:
https://github.com/part-cw/lambdanative

Post by Neil Van Dyke

Post by Neil Van Dyke
Anyone have any current/planned projects on compiling Android and iOS

apps

Post by Neil Van Dyke
from Racket?
So, as an alternative for smartphone/tablet apps, to keep handy as a

backup

Post by Neil Van Dyke
to HTML5, I'm interested again in the idea of compiling Racket to native

iOS

Post by Neil Van Dyke
and Android apps. Typical polished commercial-grade apps, so pedagogic
graphics worlds alone usually aren't enough.

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).
https://github.com/feeley/gambit/blob/master/misc/build-gambit-iOS
/Jens Axel
____________________
http://lists.racket-lang.org/users

[Darren Cruse]

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 mention Moby and/or Whalesong but
it sounds like been there/done that?

Otherwise I too had briefly looked at Lamdbanative as mentioned above.

That was interesting to me as a newbie to Racket and scheme both in seeing
how much of my Racket learning helped me to follow their code, as well as
how much does not. :) i.e. I'm new enough I'm not always appreciating what
in Racket is standardized and what is not...

Glancing at this example game Lamdbanative includes:
https://github.com/part-cw/lambdanative/blob/master/apps/uSquish/main.scm

My first reaction was "great I can read this code!" then my second reaction
was "oh yeah that's right big-bang ain't gonna be here... hmmm I don't see
require anywhere I guess modules work differently too ok..."

Which is not to be negative it was just to recognize that gambit scheme and
lambdanative isn't racket so seemingly wouldn't be able to benefit from a
lot of Racket modules or it's community etc...

Otherwise did you notice Lambdanative has it's own widget set built atop
OpenGL - that's how it achieved portability across iOS and Android with the
same code. But of course those widgets are a tradeoff - depending on what
you're doing (e.g. a game) they may be fine, but if you really want the
look and feel of native widgets that's not what you're getting.

Lastly (maybe you know this) Gambit by design is a scheme to C translator
apparently that's why it was chosen for doing these mobile apps i.e. the
resulting code is comparable size wise and performance wise to something
you might have written in C, and obviously C is portable across iOS and
Android.

I don't really know but I'm guessing porting the Racket VM to operate well
on iOS and Android is a bigger job than this (i.e. than getting Gambit's C
code to compile on IOS and Android). i.e. Maybe that's why there's not a
better Racket on iOS/Android story already. :)

Chicken scheme uses a similar compile-to-C approach (they call it "Cheney
on the MTA" you can google it if you're interested). They seem to have a
good community too with lots of these packages (they call "eggs"). And I
know there's at least this one effort to do android native apps with
Chicken: https://github.com/chicken-mobile/android-chicken

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. :)







On Sat, Feb 21, 2015 at 4:06 AM, Stephen De Gabrielle <

Post by Stephen De Gabrielle
https://github.com/part-cw/lambdanative

Post by Neil Van Dyke

Post by Neil Van Dyke
Anyone have any current/planned projects on compiling Android and iOS

apps

Post by Neil Van Dyke
from Racket?
So, as an alternative for smartphone/tablet apps, to keep handy as a

backup

Post by Neil Van Dyke
to HTML5, I'm interested again in the idea of compiling Racket to

native iOS

Post by Neil Van Dyke
and Android apps. Typical polished commercial-grade apps, so pedagogic
graphics worlds alone usually aren't enough.

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).
https://github.com/feeley/gambit/blob/master/misc/build-gambit-iOS
/Jens Axel
____________________
http://lists.racket-lang.org/users

____________________
http://lists.racket-lang.org/users

[Hendrik Boom]

Post by Darren Cruse
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. How different are the standards
these implementations are approximations to?

-- hendrik
____________________
Racket Users list:
http://lists.racket-lang.org/users

[Justin Zamora]

There is also Clojure on Android, which might be a promising alternative.
http://clojure-android.info/

Justin

Post by Darren Cruse
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 mention Moby and/or Whalesong but
it sounds like been there/done that?
Otherwise I too had briefly looked at Lamdbanative as mentioned above.
That was interesting to me as a newbie to Racket and scheme both in seeing
how much of my Racket learning helped me to follow their code, as well as
how much does not. :) i.e. I'm new enough I'm not always appreciating what
in Racket is standardized and what is not...
https://github.com/part-cw/lambdanative/blob/master/apps/uSquish/main.scm
My first reaction was "great I can read this code!" then my second
reaction was "oh yeah that's right big-bang ain't gonna be here... hmmm I
don't see require anywhere I guess modules work differently too ok..."
Which is not to be negative it was just to recognize that gambit scheme
and lambdanative isn't racket so seemingly wouldn't be able to benefit from
a lot of Racket modules or it's community etc...
Otherwise did you notice Lambdanative has it's own widget set built atop
OpenGL - that's how it achieved portability across iOS and Android with the
same code. But of course those widgets are a tradeoff - depending on what
you're doing (e.g. a game) they may be fine, but if you really want the
look and feel of native widgets that's not what you're getting.
Lastly (maybe you know this) Gambit by design is a scheme to C translator
apparently that's why it was chosen for doing these mobile apps i.e. the
resulting code is comparable size wise and performance wise to something
you might have written in C, and obviously C is portable across iOS and
Android.
I don't really know but I'm guessing porting the Racket VM to operate well
on iOS and Android is a bigger job than this (i.e. than getting Gambit's C
code to compile on IOS and Android). i.e. Maybe that's why there's not a
better Racket on iOS/Android story already. :)
Chicken scheme uses a similar compile-to-C approach (they call it "Cheney
on the MTA" you can google it if you're interested). They seem to have a
good community too with lots of these packages (they call "eggs"). And I
know there's at least this one effort to do android native apps with
Chicken: https://github.com/chicken-mobile/android-chicken
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. :)
On Sat, Feb 21, 2015 at 4:06 AM, Stephen De Gabrielle <

Post by Stephen De Gabrielle
https://github.com/part-cw/lambdanative

Post by Neil Van Dyke

Post by Neil Van Dyke
Anyone have any current/planned projects on compiling Android and iOS

apps

Post by Neil Van Dyke
from Racket?
So, as an alternative for smartphone/tablet apps, to keep handy as a

backup

Post by Neil Van Dyke
to HTML5, I'm interested again in the idea of compiling Racket to

native iOS

Post by Neil Van Dyke
and Android apps. Typical polished commercial-grade apps, so pedagogic
graphics worlds alone usually aren't enough.

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).
https://github.com/feeley/gambit/blob/master/misc/build-gambit-iOS
/Jens Axel
____________________
http://lists.racket-lang.org/users

____________________
http://lists.racket-lang.org/users

____________________
http://lists.racket-lang.org/users

[Neil Van Dyke]

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

Good to know that Clojure-Android is out there. I don't want to move to
Clojure at this time, but having people advancing a diversity ways to
make apps for popular platforms helps to keep the ecosystem healthy and
open for everyone.

Neil V.

____________________
Racket Users list:
http://lists.racket-lang.org/users

[Eric Dong]

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
iOS. Whalesong etc don't seem to be very useful; I've found Whalesong
personally quite not useful, since it's essentially another language that
looks vaguely like Racket, and cannot require Racket modules etc.

Racket is sufficiently different from Scheme that it would be difficult to
find a common subset that is useful.

Post by Neil Van Dyke
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.)
Good to know that Clojure-Android is out there. I don't want to move to
Clojure at this time, but having people advancing a diversity ways to make
apps for popular platforms helps to keep the ecosystem healthy and open for
everyone.
Neil V.
____________________
http://lists.racket-lang.org/users

[Neil Van Dyke]

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 sauce of your app was a symbolic
planner or inference engine. That library might well have been written
entirely in R5RS in the first place, even if you only intended to use it
with Racket. So that key library source code could be shared between
your Racket programs and your LambdaNative program. And you'd probably
do most of the other parts of the app using LambdaNative directly, since
they're probably irrelevant to your Racket programs anyway.) And there
are a few different viable ways to close the gap even more.

* Much of a Racket programmer's skill transfers over easily to R5RS.
(Idiomatic Racket programming is mostly idiomatic Scheme programming, IMHO.)

Incidentally, a decade ago, I switched from portable R5RS to Racket
(then called PLT Scheme) exclusively, while keeping Gambit and Kawa
especially as backup alternatives for special situations. I think I
actually suspected that I'd need one of my backups before now. Racket
continues to perform very well for most all purposes.

Neil V.

____________________
Racket Users list:
http://lists.racket-lang.org/users

[Stephen De Gabrielle]

Post by Neil Van Dyke
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.

Post by Neil Van Dyke
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
* Lots of code written in Racket can actually be written in R5RS almost
as well. (Example: say that the secret sauce of your app was a symbolic
planner or inference engine. That library might well have been written
entirely in R5RS in the first place, even if you only intended to use it
with Racket. So that key library source code could be shared between
your Racket programs and your LambdaNative program. And you'd probably
do most of the other parts of the app using LambdaNative directly, since
they're probably irrelevant to your Racket programs anyway.) And there
are a few different viable ways to close the gap even more.
* Much of a Racket programmer's skill transfers over easily to R5RS.
(Idiomatic Racket programming is mostly idiomatic Scheme programming, IMHO.)
Incidentally, a decade ago, I switched from portable R5RS to Racket
(then called PLT Scheme) exclusively, while keeping Gambit and Kawa
especially as backup alternatives for special situations. I think I
actually suspected that I'd need one of my backups before now. Racket
continues to perform very well for most all purposes.
Neil V.
____________________
http://lists.racket-lang.org/users

[Darren Cruse]

Post by Stephen De Gabrielle

Post by Neil Van Dyke
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 confused reading the above - I mean, I already run racket and
drracket on my (original) pi?
It's slow but it does run - what I learned is that's largely the fault of
poor graphics drivers on the pi.
It runs much better on the "odroid" that I bought right before christmas...
Not knowing the pi 2 was coming with very similar specs... (regret buying
the odroid oh well at least it as cheap).

Then I realized: Are you saying above you want to work on an android port
of racket using android running on the pi (which is available) as your
development platform?

That seems very reasonable.

[Stephen De Gabrielle]

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 be aware of?

Kind regard

Stephen

Post by Stephen De Gabrielle

Post by Neil Van Dyke
A solid Racket VM and GUI for Android and

Post by Neil Van Dyke
iOS apps would be awesome.

Agreed, but I'm going to try the Raspberry Pi. If I can succeed targeting

Post by Neil Van Dyke
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 confused reading the above - I mean, I already run racket and
drracket on my (original) pi?
It's slow but it does run - what I learned is that's largely the fault of
poor graphics drivers on the pi.
It runs much better on the "odroid" that I bought right before christmas...
Not knowing the pi 2 was coming with very similar specs... (regret buying
the odroid oh well at least it as cheap).
Then I realized: Are you saying above you want to work on an android port
of racket using android running on the pi (which is available) as your
development platform?
That seems very reasonable.

[Darren Cruse]

@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 right that later I came to realize that had given me a
version that wasn't the latest 6.1 version, but in this pong game I've
written I'd used something that required 6.1, so I went ahead and
downloaded from the racket site and built from source on the pi. In either
case I don't recall having much trouble. If you do try and do have
trouble, maybe post again and I can try a little harder to retrace my
steps.

On Sun, Feb 22, 2015 at 7:20 AM, Stephen De Gabrielle <

Post by Stephen De Gabrielle
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 be aware of?
Kind regard
Stephen

Post by Stephen De Gabrielle

Post by Neil Van Dyke
A solid Racket VM and GUI for Android and

Post by Neil Van Dyke
iOS apps would be awesome.

Agreed, but I'm going to try the Raspberry Pi. If I can succeed targeting

Post by Neil Van Dyke
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 confused reading the above - I mean, I already run racket and
drracket on my (original) pi?
It's slow but it does run - what I learned is that's largely the fault of
poor graphics drivers on the pi.
It runs much better on the "odroid" that I bought right before christmas...
Not knowing the pi 2 was coming with very similar specs... (regret
buying the odroid oh well at least it as cheap).
Then I realized: Are you saying above you want to work on an android
port of racket using android running on the pi (which is available) as your
development platform?
That seems very reasonable.

[Franco Raimondi]

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 ln -sf racket-6.1 racket (in case you want to upgrade in the future you just change this link)
sudo vi /etc/profile and, before export PATH, add:
PATH=$PATH:/opt/racket/bin

Franco

@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 right that later I came to realize that had given me a version that wasn't the latest 6.1 version, but in this pong game I've written I'd used something that required 6.1, so I went ahead and downloaded from the racket site and built from source on the pi. In either case I don't recall having much trouble. If you do try and do have trouble, maybe post again and I can try a little harder to retrace my steps.
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 be aware of?
Kind regard
Stephen

Post by Neil Van Dyke
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 confused reading the above - I mean, I already run racket and drracket on my (original) pi?
It's slow but it does run - what I learned is that's largely the fault of poor graphics drivers on the pi.
It runs much better on the "odroid" that I bought right before christmas...
Not knowing the pi 2 was coming with very similar specs... (regret buying the odroid oh well at least it as cheap).
Then I realized: Are you saying above you want to work on an android port of racket using android running on the pi (which is available) as your development platform?
That seems very reasonable.
____________________
http://lists.racket-lang.org/users

____________________
Racket Users list:
http://lists.racket-lang.org/users

[Eric Dong]

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 programs heavily use immutable sets and dictionaries, which few
if any Schemes provide. Racket's module systems is also very good, and I
use things like prefix-in quite often, while most Schemes have really poor
module systems. The styles are different enough that I very much enjoy
writing complicated systems in Racket, but absolutely abhor the few
occasions I had to make something other than a monolithic script in Chicken
or Gambit.

Unfortunately, a lot of the "Racket" code I see around are little more than
R5RS with #lang racket on top of them. I blame HtDP and similar things
which treat Racket as a Scheme environment for teaching, and essentially
R5RS++, which I can't blame since Scheme is much more minimalist and much
better for education. But it misses the point of Racket IMO. Racket feels
much more like Common Lisp than Scheme in terms of the large number of
forms and heaps of core features.

Post by Neil Van Dyke
* Much of a Racket programmer's skill transfers over easily to R5RS.
(Idiomatic Racket programming is mostly idiomatic Scheme programming, IMHO.)

[Neil Van Dyke]

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 experience to
help get up to speed in R5RS quickly.

Neil V.

____________________
Racket Users list:
http://lists.racket-lang.org/users

[Eric Dong]

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 there is not a publicly
usable index of Racket forms after all the macro expansion is done. I'm
pretty sure this "core Racket" would be relatively easy to translate into
R5RS etc? So we could have a system that supports R5RS or similar, and then
have Racket's fully-expanded form run on the system? Such a system will not
run .rkt files, but some compiled form, but perhaps it can be made fully
compatible with full Racket? How large is the language of core Racket forms
(supposing that trivial things like hashtables are implemented in a Racket
library rather than in C)

Post by Neil Van Dyke
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
* A good Racket programmer can, acting selflessly, without regard to
his/her personal comfort, draw upon some of his/her Racket experience to
help get up to speed in R5RS quickly.
Neil V.

[Jay McCarthy]

Post by Eric Dong
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 there is not a publicly
usable index of Racket forms after all the macro expansion is done.

http://docs.racket-lang.org/reference/syntax-model.html#%28part._fully-expanded%29

Post by Eric Dong
I'm
pretty sure this "core Racket" would be relatively easy to translate into
R5RS etc? So we could have a system that supports R5RS or similar, and then
have Racket's fully-expanded form run on the system? Such a system will not
run .rkt files, but some compiled form, but perhaps it can be made fully
compatible with full Racket? How large is the language of core Racket forms
(supposing that trivial things like hashtables are implemented in a Racket
library rather than in C)

Hash-tables are implemented in C and not in Racket. The set of such
"primitives" is very large (like over 1200).

A big problem with iOS/Android is building useful bindings to the
native interfaces so that you could have natural looking programs and
that still "felt like" Racket on the programming side.

Jay

Post by Eric Dong

Post by Neil Van Dyke
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
* A good Racket programmer can, acting selflessly, without regard to
his/her personal comfort, draw upon some of his/her Racket experience to
help get up to speed in R5RS quickly.
Neil V.

____________________
http://lists.racket-lang.org/users

--
Jay McCarthy
http://jeapostrophe.github.io

"Wherefore, be not weary in well-doing,
for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great."
- D&C 64:33
____________________
Racket Users list:
http://lists.racket-lang.org/users

[Matthew Flatt]

Post by Jens Axel Søgaard

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 Android apps. Typical polished commercial-grade apps, so pedagogic
graphics worlds alone usually aren't enough.

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 compile
as a framework for iOS (as it does already for Android). Build with
something like

../configure --host=armv7-apple-darwin \
--enable-ios=iPhoneOS \
--enable-racket=racket

or

../configure --host=x86_64-apple-darwin \
--enable-ios=iPhoneSimulator \
--enable-racket=racket

See "racket/src/README" for more information.


____________________
Racket Users list:
http://l

[Jens Axel Søgaard]

Post by Matthew Flatt

Post by Jens Axel Søgaard
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 compile
as a framework for iOS (as it does already for Android). Build with
something like
../configure --host=armv7-apple-darwin \
--enable-ios=iPhoneOS \
--enable-racket=racket
or
../configure --host=x86_64-apple-darwin \
--enable-ios=iPhoneSimulator \
--enable-racket=racket

I installed the Command Line Tools for XCode (for Mavericks).
Then I tried using the options above for the simulator build.
The configuration fails - I think it is using the wrong C compiler?

mba-5:src soegaard$ ./configure --host=x86_64-apple-darwin
--enable-ios=iPhoneSimulator
--enable-racket=/Users/soegaard/racket-from-github/racket/racket/bin/racket
checking build system type... x86_64-apple-darwin13.4.0
checking host system type... x86_64-apple-darwin
checking target system type... x86_64-apple-darwin
=== Using ios SDK directory iPhoneSimulator
=== Using Racket executable
/Users/soegaard/racket-from-github/racket/racket/bin/racket
checking for x86_64-apple-darwin-gcc... no
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/Users/soegaard/racket-from-github/racket/racket/src':
configure: error: C compiler cannot create executables
See `config.log' for more details


Here is config.log

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.69. Invocation command line was

$ ./configure --host=x86_64-apple-darwin
--enable-ios=iPhoneSimulator
--enable-racket=/Users/soegaard/racket-from-github/racket/racket/bin/racket

## --------- ##
## Platform. ##
## --------- ##

hostname = mba-5.local
uname -m = x86_64
uname -r = 13.4.0
uname -s = Darwin
uname -v = Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT 2014;
root:xnu-2422.115.4~1/RELEASE_X86_64

/usr/bin/uname -p = i386
/bin/uname -X = unknown

/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo = Mach kernel version:
Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT 2014;
root:xnu-2422.115.4~1/RELEASE_X86_64
Kernel configured for up to 4 processors.
2 processors are physically available.
4 processors are logically available.
Processor type: i486 (Intel 80486)
Processors active: 0 1 2 3
Primary memory available: 4.00 gigabytes
Default processor set: 254 tasks, 901 threads, 4 processors
Load average: 1.77, Mach factor: 2.22
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown

PATH: /Users/soegaard/anaconda/anaconda/bin
PATH: /opt/local/bin
PATH: /opt/local/sbin
PATH: /opt/local/bin
PATH: /opt/local/sbin
PATH: /usr/bin
PATH: /bin
PATH: /usr/sbin
PATH: /sbin
PATH: /usr/local/bin
PATH: /opt/X11/bin
PATH: /Users/soegaard/racket-from-plt-git/plt/racket/bin
PATH: /usr/texbin


## ----------- ##
## Core tests. ##
## ----------- ##

configure:2469: checking build system type
configure:2483: result: x86_64-apple-darwin13.4.0
configure:2503: checking host system type
configure:2516: result: x86_64-apple-darwin
configure:2536: checking target system type
configure:2549: result: x86_64-apple-darwin
configure:3280: checking for x86_64-apple-darwin-gcc
configure:3310: result: no
configure:3320: checking for gcc
configure:3336: found /usr/bin/gcc
configure:3347: result: gcc
configure:3576: checking for C compiler version
configure:3585: gcc --version >&5
i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc.
build 5658) (LLVM build 2335.6)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:3596: $? = 0
configure:3585: gcc -v >&5
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/llvmgcc42/llvmgcc42-2335.6~17/src/configure
--disable-checking --enable-werror
--prefix=/Developer/usr/llvm-gcc-4.2 --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm-
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
--with-slibdir=/usr/lib --build=i686-apple-darwin10
--enable-llvm=/var/tmp/llvmgcc42/llvmgcc42-2335.6~17/dst-llvmCore/Developer/usr/local
--program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10
--target=i686-apple-darwin10
--with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.6)
configure:3596: $? = 0
configure:3585: gcc -V >&5
llvm-gcc-4.2: argument to `-V' is missing
configure:3596: $? = 1
configure:3585: gcc -qversion >&5
i686-apple-darwin10-llvm-gcc-4.2: no input files
configure:3596: $? = 1
configure:3616: checking whether the C compiler works
configure:3638: gcc -DTARGET_OS_IPHONE -arch x86_64 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk
-miphoneos-version-min=6.0 -arch x86_64 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk
-miphoneos-version-min=6.0 -liconv conftest.c >&5
ld: library not found for -lgcc_s.10.5
collect2: ld returned 1 exit status
configure:3642: $? = 1
configure:3680: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define USE_SINGLE_FLOATS 1
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3685: error: in
`/Users/soegaard/racket-from-github/racket/racket/src':
configure:3687: error: C compiler cannot create executables
See `config.log' for more details

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_build=x86_64-apple-darwin13.4.0
ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_LIBS_set=
ac_cv_env_LIBS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=set
ac_cv_env_host_alias_value=x86_64-apple-darwin
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_host=x86_64-apple-darwin
ac_cv_prog_ac_ct_CC=gcc
ac_cv_target=x86_64-apple-darwin

## ----------------- ##
## Output variables. ##
## ----------------- ##

AR=''
ARFLAGS=''
AS=''
CC='gcc'
CC_FOR_BUILD=''
CFLAGS=''
CGC='cgc'
CGCOPTIONS=''
CGC_CAP_INSTALLED='CGC'
CGC_IF_NEEDED_FOR_MMM=''
CGC_INSTALLED='cgc'
COLLECTS_PATH='../collects'
COMPFLAGS=''
CONFIG_PATH='../etc'
CPP=''
CPPFLAGS=' -DTARGET_OS_IPHONE -arch x86_64 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk
-miphoneos-version-min=6.0'
DEFS=''
DIRCVTPOST=''
DIRCVTPRE=''
DLLTOOL='dlltool'
DYN_CFLAGS=''
ECHO_C='\c'
ECHO_N=''
ECHO_T=''
EGREP=''
EXEEXT=''
EXE_SUFFIX=''
EXTRA_GMP_DEP=''
EXTRA_GMP_OBJ=''
EXTRA_OSK_LIBS=''
FOREIGNTARGET=''
FOREIGN_CONVENIENCE=''
FOREIGN_IF_USED=''
FOREIGN_OBJSLIB=''
FRAMEWORK_INSTALL_DIR=''
FRAMEWORK_PREFIX=''
FRAMEWORK_REL_INSTALL=''
GC2OPTIONS=''
GCDIR='gc'
GREP=''
ICP=''
INCLUDEDEP='#'
INSTALL_LIBS_ENABLE='no-install'
INSTALL_ORIG_TREE='yes'
INSTALL_PKGSCOPE='user'
INSTALL_SETUP_FLAGS=''
LDFLAGS=' -arch x86_64 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk
-miphoneos-version-min=6.0 -liconv'
LIBFINISH=''
LIBOBJS=''
LIBRACKET_DEP=''
LIBS=''
LIBSFX=''
LTA=''
LTLIBOBJS=''
LTO=''
MAIN_VARIANT='3m'
MAKE_COPYTREE='no'
MAKE_FINISH=''
MAKE_GRACKET=''
MAKE_INSTALL_PKGSCOPE='preserve'
MINGW=''
MMM='3m'
MMM_CAP_INSTALLED=''
MMM_INSTALLED=''
MRLIBINSTALL=''
MROPTIONS=''
MZBINTARGET='normal-bin'
MZINSTALLBINDIR='$(bindir)'
MZINSTALLTARGET='unix-install'
MZLINKER=''
MZOPTIONS=''
NOT_MINGW=''
NOT_OSX=''
OBJEXT=''
OPTIONS=''
OSKHOME=''
OSX=''
OWN_LIBFFI='ON'
PACKAGE_BUGREPORT=''
PACKAGE_NAME=''
PACKAGE_STRING=''
PACKAGE_TARNAME=''
PACKAGE_URL=''
PACKAGE_VERSION=''
PATH_SEPARATOR=':'
PLAIN_CC=''
PREFLAGS=' -DTARGET_OS_IPHONE -arch x86_64 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk
-miphoneos-version-min=6.0'
PROFFLAGS=''
PWD='pwd'
RANLIB=''
REZ=''
RUN_RACKET_CGC=''
RUN_RACKET_MAIN_VARIANT=''
RUN_RACKET_MMM=''
SED=''
SHELL='/bin/sh'
SO_SUFFIX='.so'
STATIC_AR=''
STRIP=''
STRIP_DEBUG=':'
USE_WXPRECOMP=''
WINDRES='windres'
WXLIBS=''
WXPRECOMP=''
WXVARIANT='wx_xt'
WX_MMD_FLAG=''
XFORMFLAGS=''
X_CFLAGS=''
X_EXTRA_LIBS=''
X_LIBS=''
X_PRE_LIBS=''
ac_ct_CC='gcc'
appsdir='${prefix}/share/applications'
appsdir='${prefix}/share/applications'
bindir='${prefix}/bin'
build='x86_64-apple-darwin13.4.0'
build_alias=''
build_cpu='x86_64'
build_os='darwin13.4.0'
build_vendor='apple'
collectsdir='${prefix}/collects'
collectsdir='${prefix}/collects'
datadir='${datarootdir}'
datarootdir='${prefix}/share'
docdir='${prefix}/doc'
etcpltdir='${prefix}/etc'
exec_prefix='NONE'
host='x86_64-apple-darwin'
host_alias='x86_64-apple-darwin'
host_cpu='x86_64'
host_os='darwin'
host_vendor='apple'
htmldir='${docdir}'
includedir='${prefix}/include'
includepltdir='${prefix}/include'
infodir='${datarootdir}/info'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
libpltdir='${prefix}/lib'
localedir='${datarootdir}/locale'
localstatedir='${prefix}/var'
mandir='${prefix}/man'
oldincludedir='/usr/include'
platform_ar_found=''
prefix='/Users/soegaard/racket-from-github/racket/racket'
program_transform_name='s,x,x,'
psdir='${docdir}'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sharepltdir='${prefix}/share'
subdirs=''
sysconfdir='${prefix}/etc'
target='x86_64-apple-darwin'
target_alias=''
target_cpu='x86_64'
target_os='darwin'
target_vendor='apple'
x_includes='NONE'
x_libraries='NONE'

## ----------- ##
## confdefs.h. ##
## ----------- ##

/* confdefs.h */
#define PACKAGE_NAME ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define PACKAGE_STRING ""
#define PACKAGE_BUGREPORT ""
#define PACKAGE_URL ""
#define USE_SINGLE_FLOATS 1

configure: exit 77
____________________
Racket Users list:
http://lists.racket-lang.org/users

[Matthew Flatt]

[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 "/Applications/XCode.app".

Meanwhile, I'm able to build on a machine that has this older version
of the tools, including an older "/Application/XCode.app", but only by
using `--host=i386-...` and by providing a full path for the simulator
SDK (which ends in "iPhoneSimulator6.1.sdk" instead of just
"iPhoneSimulator.sdk").

Post by Jens Axel Søgaard

Post by Matthew Flatt

Post by Jens Axel Søgaard
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 compile
as a framework for iOS (as it does already for Android). Build with
something like
../configure --host=armv7-apple-darwin \
--enable-ios=iPhoneOS \
--enable-racket=racket
or
../configure --host=x86_64-apple-darwin \
--enable-ios=iPhoneSimulator \
--enable-racket=racket

I installed the Command Line Tools for XCode (for Mavericks).
Then I tried using the options above for the simulator build.
The configuration fails - I think it is using the wrong C compiler?
mba-5:src soegaard$ ./configure --host=x86_64-apple-darwin
--enable-ios=iPhoneSimulator
--enable-racket=/Users/soegaard/racket-from-github/racket/racket/bin/racket
checking build system type... x86_64-apple-darwin13.4.0
checking host system type... x86_64-apple-darwin
checking target system type... x86_64-apple-darwin
=== Using ios SDK directory iPhoneSimulator
=== Using Racket executable
/Users/soegaard/racket-from-github/racket/racket/bin/racket
checking for x86_64-apple-darwin-gcc... no
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: C compiler cannot create executables
See `config.log' for more details
Here is config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by configure, which was
generated by GNU Autoconf 2.69. Invocation command line was
$ ./configure --host=x86_64-apple-darwin
--enable-ios=iPhoneSimulator
--enable-racket=/Users/soegaard/racket-from-github/racket/racket/bin/racket
## --------- ##
## Platform. ##
## --------- ##
hostname = mba-5.local
uname -m = x86_64
uname -r = 13.4.0
uname -s = Darwin
uname -v = Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT 2014;
root:xnu-2422.115.4~1/RELEASE_X86_64
/usr/bin/uname -p = i386
/bin/uname -X = unknown
/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT 2014;
root:xnu-2422.115.4~1/RELEASE_X86_64
Kernel configured for up to 4 processors.
2 processors are physically available.
4 processors are logically available.
Processor type: i486 (Intel 80486)
Processors active: 0 1 2 3
Primary memory available: 4.00 gigabytes
Default processor set: 254 tasks, 901 threads, 4 processors
Load average: 1.77, Mach factor: 2.22
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
PATH: /Users/soegaard/anaconda/anaconda/bin
PATH: /opt/local/bin
PATH: /opt/local/sbin
PATH: /opt/local/bin
PATH: /opt/local/sbin
PATH: /usr/bin
PATH: /bin
PATH: /usr/sbin
PATH: /sbin
PATH: /usr/local/bin
PATH: /opt/X11/bin
PATH: /Users/soegaard/racket-from-plt-git/plt/racket/bin
PATH: /usr/texbin
## ----------- ##
## Core tests. ##
## ----------- ##
configure:2469: checking build system type
configure:2483: result: x86_64-apple-darwin13.4.0
configure:2503: checking host system type
configure:2516: result: x86_64-apple-darwin
configure:2536: checking target system type
configure:2549: result: x86_64-apple-darwin
configure:3280: checking for x86_64-apple-darwin-gcc
configure:3310: result: no
configure:3320: checking for gcc
configure:3336: found /usr/bin/gcc
configure:3347: result: gcc
configure:3576: checking for C compiler version
configure:3585: gcc --version >&5
i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc.
build 5658) (LLVM build 2335.6)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
configure:3596: $? = 0
configure:3585: gcc -v >&5
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/llvmgcc42/llvmgcc42-2335.6~17/src/configure
--disable-checking --enable-werror
--prefix=/Developer/usr/llvm-gcc-4.2 --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm-
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
--with-slibdir=/usr/lib --build=i686-apple-darwin10
--enable-llvm=/var/tmp/llvmgcc42/llvmgcc42-2335.6~17/dst-llvmCore/Developer/usr
/local
--program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10
--target=i686-apple-darwin10
--with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.6)
configure:3596: $? = 0
configure:3585: gcc -V >&5
llvm-gcc-4.2: argument to `-V' is missing
configure:3596: $? = 1
configure:3585: gcc -qversion >&5
i686-apple-darwin10-llvm-gcc-4.2: no input files
configure:3596: $? = 1
configure:3616: checking whether the C compiler works
configure:3638: gcc -DTARGET_OS_IPHONE -arch x86_64 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/D
eveloper/SDKs/iPhoneSimulator.sdk
-miphoneos-version-min=6.0 -arch x86_64 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/D
eveloper/SDKs/iPhoneSimulator.sdk
-miphoneos-version-min=6.0 -liconv conftest.c >&5
ld: library not found for -lgcc_s.10.5
collect2: ld returned 1 exit status
configure:3642: $? = 1
configure:3680: result: no
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define USE_SINGLE_FLOATS 1
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3685: error: in
configure:3687: error: C compiler cannot create executables
See `config.log' for more details
## ---------------- ##
## Cache variables. ##
## ---------------- ##
ac_cv_build=x86_64-apple-darwin13.4.0
ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_LIBS_set=
ac_cv_env_LIBS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=set
ac_cv_env_host_alias_value=x86_64-apple-darwin
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_host=x86_64-apple-darwin
ac_cv_prog_ac_ct_CC=gcc
ac_cv_target=x86_64-apple-darwin
## ----------------- ##
## Output variables. ##
## ----------------- ##
AR=''
ARFLAGS=''
AS=''
CC='gcc'
CC_FOR_BUILD=''
CFLAGS=''
CGC='cgc'
CGCOPTIONS=''
CGC_CAP_INSTALLED='CGC'
CGC_IF_NEEDED_FOR_MMM=''
CGC_INSTALLED='cgc'
COLLECTS_PATH='../collects'
COMPFLAGS=''
CONFIG_PATH='../etc'
CPP=''
CPPFLAGS=' -DTARGET_OS_IPHONE -arch x86_64 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/D
eveloper/SDKs/iPhoneSimulator.sdk
-miphoneos-version-min=6.0'
DEFS=''
DIRCVTPOST=''
DIRCVTPRE=''
DLLTOOL='dlltool'
DYN_CFLAGS=''
ECHO_C='\c'
ECHO_N=''
ECHO_T=''
EGREP=''
EXEEXT=''
EXE_SUFFIX=''
EXTRA_GMP_DEP=''
EXTRA_GMP_OBJ=''
EXTRA_OSK_LIBS=''
FOREIGNTARGET=''
FOREIGN_CONVENIENCE=''
FOREIGN_IF_USED=''
FOREIGN_OBJSLIB=''
FRAMEWORK_INSTALL_DIR=''
FRAMEWORK_PREFIX=''
FRAMEWORK_REL_INSTALL=''
GC2OPTIONS=''
GCDIR='gc'
GREP=''
ICP=''
INCLUDEDEP='#'
INSTALL_LIBS_ENABLE='no-install'
INSTALL_ORIG_TREE='yes'
INSTALL_PKGSCOPE='user'
INSTALL_SETUP_FLAGS=''
LDFLAGS=' -arch x86_64 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/D
eveloper/SDKs/iPhoneSimulator.sdk
-miphoneos-version-min=6.0 -liconv'
LIBFINISH=''
LIBOBJS=''
LIBRACKET_DEP=''
LIBS=''
LIBSFX=''
LTA=''
LTLIBOBJS=''
LTO=''
MAIN_VARIANT='3m'
MAKE_COPYTREE='no'
MAKE_FINISH=''
MAKE_GRACKET=''
MAKE_INSTALL_PKGSCOPE='preserve'
MINGW=''
MMM='3m'
MMM_CAP_INSTALLED=''
MMM_INSTALLED=''
MRLIBINSTALL=''
MROPTIONS=''
MZBINTARGET='normal-bin'
MZINSTALLBINDIR='$(bindir)'
MZINSTALLTARGET='unix-install'
MZLINKER=''
MZOPTIONS=''
NOT_MINGW=''
NOT_OSX=''
OBJEXT=''
OPTIONS=''
OSKHOME=''
OSX=''
OWN_LIBFFI='ON'
PACKAGE_BUGREPORT=''
PACKAGE_NAME=''
PACKAGE_STRING=''
PACKAGE_TARNAME=''
PACKAGE_URL=''
PACKAGE_VERSION=''
PATH_SEPARATOR=':'
PLAIN_CC=''
PREFLAGS=' -DTARGET_OS_IPHONE -arch x86_64 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/D
eveloper/SDKs/iPhoneSimulator.sdk
-miphoneos-version-min=6.0'
PROFFLAGS=''
PWD='pwd'
RANLIB=''
REZ=''
RUN_RACKET_CGC=''
RUN_RACKET_MAIN_VARIANT=''
RUN_RACKET_MMM=''
SED=''
SHELL='/bin/sh'
SO_SUFFIX='.so'
STATIC_AR=''
STRIP=''
STRIP_DEBUG=':'
USE_WXPRECOMP=''
WINDRES='windres'
WXLIBS=''
WXPRECOMP=''
WXVARIANT='wx_xt'
WX_MMD_FLAG=''
XFORMFLAGS=''
X_CFLAGS=''
X_EXTRA_LIBS=''
X_LIBS=''
X_PRE_LIBS=''
ac_ct_CC='gcc'
appsdir='${prefix}/share/applications'
appsdir='${prefix}/share/applications'
bindir='${prefix}/bin'
build='x86_64-apple-darwin13.4.0'
build_alias=''
build_cpu='x86_64'
build_os='darwin13.4.0'
build_vendor='apple'
collectsdir='${prefix}/collects'
collectsdir='${prefix}/collects'
datadir='${datarootdir}'
datarootdir='${prefix}/share'
docdir='${prefix}/doc'
etcpltdir='${prefix}/etc'
exec_prefix='NONE'
host='x86_64-apple-darwin'
host_alias='x86_64-apple-darwin'
host_cpu='x86_64'
host_os='darwin'
host_vendor='apple'
htmldir='${docdir}'
includedir='${prefix}/include'
includepltdir='${prefix}/include'
infodir='${datarootdir}/info'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
libpltdir='${prefix}/lib'
localedir='${datarootdir}/locale'
localstatedir='${prefix}/var'
mandir='${prefix}/man'
oldincludedir='/usr/include'
platform_ar_found=''
prefix='/Users/soegaard/racket-from-github/racket/racket'
program_transform_name='s,x,x,'
psdir='${docdir}'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sharepltdir='${prefix}/share'
subdirs=''
sysconfdir='${prefix}/etc'
target='x86_64-apple-darwin'
target_alias=''
target_cpu='x86_64'
target_os='darwin'
target_vendor='apple'
x_includes='NONE'
x_libraries='NONE'
## ----------- ##
## confdefs.h. ##
## ----------- ##
/* confdefs.h */
#define PACKAGE_NAME ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define PACKAGE_STRING ""
#define PACKAGE_BUGREPORT ""
#define PACKAGE_URL ""
#define USE_SINGLE_FLOATS 1
configure: exit 77
____________________
http://lists.racket-lang.org/users

____________________
Racket Users list:
http://lists.racket-lang.or

[Jens Axel Søgaard]

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 believe they work
in the simulator). Is it possible to embed Racket as a static library?

http://stackoverflow.com/questions/4733847/can-you-build-dynamic-libraries-for-ios-and-load-them-at-runtime

/Jens Axel

Post by Matthew Flatt
[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 "/Applications/XCode.app".
Meanwhile, I'm able to build on a machine that has this older version
of the tools, including an older "/Application/XCode.app", but only by
using `--host=i386-...` and by providing a full path for the simulator
SDK (which ends in "iPhoneSimulator6.1.sdk" instead of just
"iPhoneSimulator.sdk").

Post by Jens Axel Søgaard

Post by Matthew Flatt

Post by Jens Axel Søgaard
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 compile
as a framework for iOS (as it does already for Android). Build with
something like
../configure --host=armv7-apple-darwin \
--enable-ios=iPhoneOS \
--enable-racket=racket
or
../configure --host=x86_64-apple-darwin \
--enable-ios=iPhoneSimulator \
--enable-racket=racket

I installed the Command Line Tools for XCode (for Mavericks).
Then I tried using the options above for the simulator build.
The configuration fails - I think it is using the wrong C compiler?
mba-5:src soegaard$ ./configure --host=x86_64-apple-darwin
--enable-ios=iPhoneSimulator
--enable-racket=/Users/soegaard/racket-from-github/racket/racket/bin/racket
checking build system type... x86_64-apple-darwin13.4.0
checking host system type... x86_64-apple-darwin
checking target system type... x86_64-apple-darwin
=== Using ios SDK directory iPhoneSimulator
=== Using Racket executable
/Users/soegaard/racket-from-github/racket/racket/bin/racket
checking for x86_64-apple-darwin-gcc... no
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: C compiler cannot create executables
See `config.log' for more details
Here is config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by configure, which was
generated by GNU Autoconf 2.69. Invocation command line was
$ ./configure --host=x86_64-apple-darwin
--enable-ios=iPhoneSimulator
--enable-racket=/Users/soegaard/racket-from-github/racket/racket/bin/racket
## --------- ##
## Platform. ##
## --------- ##
hostname = mba-5.local
uname -m = x86_64
uname -r = 13.4.0
uname -s = Darwin
uname -v = Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT 2014;
root:xnu-2422.115.4~1/RELEASE_X86_64
/usr/bin/uname -p = i386
/bin/uname -X = unknown
/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT 2014;
root:xnu-2422.115.4~1/RELEASE_X86_64
Kernel configured for up to 4 processors.
2 processors are physically available.
4 processors are logically available.
Processor type: i486 (Intel 80486)
Processors active: 0 1 2 3
Primary memory available: 4.00 gigabytes
Default processor set: 254 tasks, 901 threads, 4 processors
Load average: 1.77, Mach factor: 2.22
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
PATH: /Users/soegaard/anaconda/anaconda/bin
PATH: /opt/local/bin
PATH: /opt/local/sbin
PATH: /opt/local/bin
PATH: /opt/local/sbin
PATH: /usr/bin
PATH: /bin
PATH: /usr/sbin
PATH: /sbin
PATH: /usr/local/bin
PATH: /opt/X11/bin
PATH: /Users/soegaard/racket-from-plt-git/plt/racket/bin
PATH: /usr/texbin
## ----------- ##
## Core tests. ##
## ----------- ##
configure:2469: checking build system type
configure:2483: result: x86_64-apple-darwin13.4.0
configure:2503: checking host system type
configure:2516: result: x86_64-apple-darwin
configure:2536: checking target system type
configure:2549: result: x86_64-apple-darwin
configure:3280: checking for x86_64-apple-darwin-gcc
configure:3310: result: no
configure:3320: checking for gcc
configure:3336: found /usr/bin/gcc
configure:3347: result: gcc
configure:3576: checking for C compiler version
configure:3585: gcc --version >&5
i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc.
build 5658) (LLVM build 2335.6)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
configure:3596: $? = 0
configure:3585: gcc -v >&5
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/llvmgcc42/llvmgcc42-2335.6~17/src/configure
--disable-checking --enable-werror
--prefix=/Developer/usr/llvm-gcc-4.2 --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm-
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
--with-slibdir=/usr/lib --build=i686-apple-darwin10
--enable-llvm=/var/tmp/llvmgcc42/llvmgcc42-2335.6~17/dst-llvmCore/Developer/usr
/local
--program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10
--target=i686-apple-darwin10
--with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.6)
configure:3596: $? = 0
configure:3585: gcc -V >&5
llvm-gcc-4.2: argument to `-V' is missing
configure:3596: $? = 1
configure:3585: gcc -qversion >&5
i686-apple-darwin10-llvm-gcc-4.2: no input files
configure:3596: $? = 1
configure:3616: checking whether the C compiler works
configure:3638: gcc -DTARGET_OS_IPHONE -arch x86_64 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/D
eveloper/SDKs/iPhoneSimulator.sdk
-miphoneos-version-min=6.0 -arch x86_64 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/D
eveloper/SDKs/iPhoneSimulator.sdk
-miphoneos-version-min=6.0 -liconv conftest.c >&5
ld: library not found for -lgcc_s.10.5
collect2: ld returned 1 exit status
configure:3642: $? = 1
configure:3680: result: no
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define USE_SINGLE_FLOATS 1
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3685: error: in
configure:3687: error: C compiler cannot create executables
See `config.log' for more details
## ---------------- ##
## Cache variables. ##
## ---------------- ##
ac_cv_build=x86_64-apple-darwin13.4.0
ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_LIBS_set=
ac_cv_env_LIBS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=set
ac_cv_env_host_alias_value=x86_64-apple-darwin
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_host=x86_64-apple-darwin
ac_cv_prog_ac_ct_CC=gcc
ac_cv_target=x86_64-apple-darwin
## ----------------- ##
## Output variables. ##
## ----------------- ##
AR=''
ARFLAGS=''
AS=''
CC='gcc'
CC_FOR_BUILD=''
CFLAGS=''
CGC='cgc'
CGCOPTIONS=''
CGC_CAP_INSTALLED='CGC'
CGC_IF_NEEDED_FOR_MMM=''
CGC_INSTALLED='cgc'
COLLECTS_PATH='../collects'
COMPFLAGS=''
CONFIG_PATH='../etc'
CPP=''
CPPFLAGS=' -DTARGET_OS_IPHONE -arch x86_64 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/D
eveloper/SDKs/iPhoneSimulator.sdk
-miphoneos-version-min=6.0'
DEFS=''
DIRCVTPOST=''
DIRCVTPRE=''
DLLTOOL='dlltool'
DYN_CFLAGS=''
ECHO_C='\c'
ECHO_N=''
ECHO_T=''
EGREP=''
EXEEXT=''
EXE_SUFFIX=''
EXTRA_GMP_DEP=''
EXTRA_GMP_OBJ=''
EXTRA_OSK_LIBS=''
FOREIGNTARGET=''
FOREIGN_CONVENIENCE=''
FOREIGN_IF_USED=''
FOREIGN_OBJSLIB=''
FRAMEWORK_INSTALL_DIR=''
FRAMEWORK_PREFIX=''
FRAMEWORK_REL_INSTALL=''
GC2OPTIONS=''
GCDIR='gc'
GREP=''
ICP=''
INCLUDEDEP='#'
INSTALL_LIBS_ENABLE='no-install'
INSTALL_ORIG_TREE='yes'
INSTALL_PKGSCOPE='user'
INSTALL_SETUP_FLAGS=''
LDFLAGS=' -arch x86_64 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/D
eveloper/SDKs/iPhoneSimulator.sdk
-miphoneos-version-min=6.0 -liconv'
LIBFINISH=''
LIBOBJS=''
LIBRACKET_DEP=''
LIBS=''
LIBSFX=''
LTA=''
LTLIBOBJS=''
LTO=''
MAIN_VARIANT='3m'
MAKE_COPYTREE='no'
MAKE_FINISH=''
MAKE_GRACKET=''
MAKE_INSTALL_PKGSCOPE='preserve'
MINGW=''
MMM='3m'
MMM_CAP_INSTALLED=''
MMM_INSTALLED=''
MRLIBINSTALL=''
MROPTIONS=''
MZBINTARGET='normal-bin'
MZINSTALLBINDIR='$(bindir)'
MZINSTALLTARGET='unix-install'
MZLINKER=''
MZOPTIONS=''
NOT_MINGW=''
NOT_OSX=''
OBJEXT=''
OPTIONS=''
OSKHOME=''
OSX=''
OWN_LIBFFI='ON'
PACKAGE_BUGREPORT=''
PACKAGE_NAME=''
PACKAGE_STRING=''
PACKAGE_TARNAME=''
PACKAGE_URL=''
PACKAGE_VERSION=''
PATH_SEPARATOR=':'
PLAIN_CC=''
PREFLAGS=' -DTARGET_OS_IPHONE -arch x86_64 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/D
eveloper/SDKs/iPhoneSimulator.sdk
-miphoneos-version-min=6.0'
PROFFLAGS=''
PWD='pwd'
RANLIB=''
REZ=''
RUN_RACKET_CGC=''
RUN_RACKET_MAIN_VARIANT=''
RUN_RACKET_MMM=''
SED=''
SHELL='/bin/sh'
SO_SUFFIX='.so'
STATIC_AR=''
STRIP=''
STRIP_DEBUG=':'
USE_WXPRECOMP=''
WINDRES='windres'
WXLIBS=''
WXPRECOMP=''
WXVARIANT='wx_xt'
WX_MMD_FLAG=''
XFORMFLAGS=''
X_CFLAGS=''
X_EXTRA_LIBS=''
X_LIBS=''
X_PRE_LIBS=''
ac_ct_CC='gcc'
appsdir='${prefix}/share/applications'
appsdir='${prefix}/share/applications'
bindir='${prefix}/bin'
build='x86_64-apple-darwin13.4.0'
build_alias=''
build_cpu='x86_64'
build_os='darwin13.4.0'
build_vendor='apple'
collectsdir='${prefix}/collects'
collectsdir='${prefix}/collects'
datadir='${datarootdir}'
datarootdir='${prefix}/share'
docdir='${prefix}/doc'
etcpltdir='${prefix}/etc'
exec_prefix='NONE'
host='x86_64-apple-darwin'
host_alias='x86_64-apple-darwin'
host_cpu='x86_64'
host_os='darwin'
host_vendor='apple'
htmldir='${docdir}'
includedir='${prefix}/include'
includepltdir='${prefix}/include'
infodir='${datarootdir}/info'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
libpltdir='${prefix}/lib'
localedir='${datarootdir}/locale'
localstatedir='${prefix}/var'
mandir='${prefix}/man'
oldincludedir='/usr/include'
platform_ar_found=''
prefix='/Users/soegaard/racket-from-github/racket/racket'
program_transform_name='s,x,x,'
psdir='${docdir}'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sharepltdir='${prefix}/share'
subdirs=''
sysconfdir='${prefix}/etc'
target='x86_64-apple-darwin'
target_alias=''
target_cpu='x86_64'
target_os='darwin'
target_vendor='apple'
x_includes='NONE'
x_libraries='NONE'
## ----------- ##
## confdefs.h. ##
## ----------- ##
/* confdefs.h */
#define PACKAGE_NAME ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define PACKAGE_STRING ""
#define PACKAGE_BUGREPORT ""
#define PACKAGE_URL ""
#define USE_SINGLE_FLOATS 1
configure: exit 77
____________________
http://lists.racket-lang.org/users

[Neil Van Dyke]

Post by Jens Axel Søgaard
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 remote-debugging nightmares, including the
possibility of the Racket embedding tickling previously-undiscovered
bugs in the host platform that stomp on memory.)

Neil V.

____________________
Racket Users list

[Matthew Flatt]

Post by Jens Axel Søgaard
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 believe they work
in the simulator). Is it possible to embed Racket as a static library?

Yes: use "libracket3m.a", which is created along the way to generating
the dynamic library.

If you configure with `--enable-libs`, then `make install` even copies
"libracket3m.a" to the installation's "lib" directory. You can also
just use the static library directly from its build location, or you
can copy it anywhere else.

For example, in <build>/racket after `make` in a default configuration,

gcc -o x gc2/main.o libracket3m.a -framework CoreFoundation -liconv

creates an executable `x` that's like `racket3m`, but with the Racket
VM statically linked.


____________________
Racket Users list:
http

[Byron Davies]

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
the Racket Drawing Toolkit.

I'm part of a team developing an open-source app for teaching young kids
reading, writing, and math. We're competing for the Global Learning XPRIZE
http://learning.xprize.org, which requires that entries be delivered on
Android. Our plan is to build on computer-based Racket, but eventually
we'll need an Android-based Racket for deployment.

We're a volunteer team, with amazing people (educators, techies, and
fundraisers), but zero money as yet, and no Android experts. For now, all
we can offer is encouragement to the Android effort. We would love to be
your users.

Byron Davies
StarShine Academy
Phoenix, AZ

[Byron Davies]

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 lead.)

[Eric Dong]

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 GUI through TCP or something.

Somebody has to fix the overuse of C in the system, although I hear it's
being done. Hashtables in C are pretty ridiculous, especially since pure
Racket libraries like https://github.com/97jaz/hamt are just as fast :/

Post by Byron Davies
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
the Racket Drawing Toolkit.
I'm part of a team developing an open-source app for teaching young kids
reading, writing, and math. We're competing for the Global Learning XPRIZE
http://learning.xprize.org, which requires that entries be delivered on
Android. Our plan is to build on computer-based Racket, but eventually
we'll need an Android-based Racket for deployment.
We're a volunteer team, with amazing people (educators, techies, and
fundraisers), but zero money as yet, and no Android experts. For now, all
we can offer is encouragement to the Android effort. We would love to be
your users.
Byron Davies
StarShine Academy
Phoenix, AZ
____________________
http://lists.racket-lang.org/users

[Matthew Flatt]

Post by Eric Dong
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.

Post by Eric Dong
Somebody has to fix the overuse of C in the system

Volunteers are welcome. :)

____________________
Racket Users list:
http://lists.racket-lang.org/users