[racket] compiling Racket to android and ios apps
893 views
Skip to first unread message
Neil Van Dyke
Feb 13, 2015, 5:10:43 PM2/13/15
to Racket Users List
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
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
Feb 20, 2015, 2:32:48 PM2/20/15
to Neil Van Dyke, Racket Users List
2015-02-13 23:08 GMT+01:00 Neil Van Dyke <ne...@neilvandyke.org>:
> Anyone have any current/planned projects on compiling Android and iOS apps
> from Racket?
> 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)
> 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.
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
Stephen De Gabrielle
Feb 21, 2015, 5:12:16 AM2/21/15
to Jens Axel Søgaard, Neil Van Dyke, Racket Users List
Darren Cruse
Feb 21, 2015, 1:24:55 PM2/21/15
to Stephen De Gabrielle, Jens Axel Søgaard, Racket Users List, Neil Van Dyke
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:
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. :)
Hendrik Boom
Feb 21, 2015, 4:16:43 PM2/21/15
to us...@racket-lang.org
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. How different are the standards
>
> 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. :)
these implementations are approximations to?
-- hendrik
Justin Zamora
Feb 21, 2015, 5:16:20 PM2/21/15
to Darren Cruse, Jens Axel Søgaard, Racket Users List, Neil Van Dyke
There is also Clojure on Android, which might be a promising alternative. http://clojure-android.info/
Justin
Neil Van Dyke
Feb 21, 2015, 5:33:31 PM2/21/15
to Justin Zamora, Darren Cruse, Jens Axel Søgaard, Racket Users List
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.
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.
Eric Dong
Feb 21, 2015, 9:38:00 PM2/21/15
to Racket Users List
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.
Neil Van Dyke
Feb 21, 2015, 11:06:03 PM2/21/15
to Eric Dong, Racket Users List
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.
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.
Stephen De Gabrielle
Feb 22, 2015, 5:39:40 AM2/22/15
to Neil Van Dyke, Eric Dong, Racket Users List
>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>iOS apps would be awesome.
S.
Darren Cruse
Feb 22, 2015, 7:48:23 AM2/22/15
to Stephen De Gabrielle, Racket Users List, 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
Feb 22, 2015, 8:26:20 AM2/22/15
to Darren Cruse, Racket Users List, Neil Van Dyke
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
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
Matthew Flatt
Feb 22, 2015, 11:06:26 AM2/22/15
to Jens Axel Søgaard, Racket Users List, Neil Van Dyke
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 <ne...@neilvandyke.org>:
> > 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).
> 2015-02-13 23:08 GMT+01:00 Neil Van Dyke <ne...@neilvandyke.org>:
> > 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.
Jens Axel Søgaard
Feb 22, 2015, 5:51:59 PM2/22/15
to Matthew Flatt, Racket Users List, Neil Van Dyke
>> 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).
>> 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
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
Matthew Flatt
Feb 22, 2015, 6:26:52 PM2/22/15
to Jens Axel Søgaard, Racket Users List, Neil Van Dyke
[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").
Darren Cruse
Feb 22, 2015, 9:52:38 PM2/22/15
to Stephen De Gabrielle, Racket Users List, Neil Van Dyke
@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.
Eric Dong
Feb 22, 2015, 11:36:57 PM2/22/15
to Neil Van Dyke, Racket Users List
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.
Neil Van Dyke
Feb 23, 2015, 12:09:52 AM2/23/15
to Eric Dong, Racket Users List
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.
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.
Franco Raimondi
Feb 23, 2015, 4:23:49 AM2/23/15
to Racket Users List
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
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
Eric Dong
Feb 23, 2015, 9:16:33 PM2/23/15
to Neil Van Dyke, users
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)
Jay McCarthy
Feb 23, 2015, 9:25:11 PM2/23/15
to Eric Dong, users, Neil Van Dyke
On Mon, Feb 23, 2015 at 8:10 PM, Eric Dong <yd2...@uwaterloo.ca> 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 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
> 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)
"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
>
>
> On Mon, Feb 23, 2015 at 12:04 AM, Neil Van Dyke <ne...@neilvandyke.org>
> wrote:
>>
>> 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.
>>
>
>
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
Byron Davies
Feb 24, 2015, 12:03:22 AM2/24/15
to Racket Users
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
Feb 24, 2015, 12:55:30 AM2/24/15
to Racket Users
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
Feb 24, 2015, 2:00:19 PM2/24/15
to Byron Davies, Racket Users
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 :/
Matthew Flatt
Feb 24, 2015, 2:22:04 PM2/24/15
to Eric Dong, Racket Users
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
> I would actually think that a good first step would be to port the Racket
> VM
building (but it's just cross-compilation as usual), and let us know if
you run into trouble.
> Somebody has to fix the overuse of C in the system
Jens Axel Søgaard
Feb 24, 2015, 5:08:31 PM2/24/15
to Matthew Flatt, Racket Users List, Neil Van Dyke
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?
/Jens Axel
--
--
Jens Axel Søgaard
Neil Van Dyke
Feb 24, 2015, 5:38:00 PM2/24/15
to Racket Users List
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.
> 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.
Matthew Flatt
Feb 25, 2015, 8:38:24 PM2/25/15
to Jens Axel Søgaard, Racket Users List
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 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?
> 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.
Reply all
Reply to author
Forward
0 new messages