These changes tweak acos (special-casing (acos 1) => 0 (all exact)) and complex division (using the naive algorithm in fewer cases).
Brad
Afficher les réponses par date
Question 1:
I'm setting up tooling to build another app using Gambit Scheme. This time around there's more than one programmer involved, and more than one platform.
I'd like to set up Gambit so that I can build libraries (static and shared) and apps for Mac OS X, for iPhones, and for iPads.
What's more, I'd like to set up and configure Gambit for development, along with some local libraries and tools, and package the resulting development platform as a file tree that other programmers can simply check out or untar on their systems to obtain the tools, with no (or minimal) additional configuration.
I've set up Gambit a number of times to build OSX apps (indeed, I have a Gambit-based app on the App Store). I've also set up and built iOS projects.
What I would like to do now is set up for both, and on iOS both for simulators and for devices, preferably with everything in a common containing directory so that the whole set of tools can conveniently be cloned from one machine to another. That way, that all involved programmers can easily set up identical toolsets.
Marc, or anyone who has an idea how to accomplish this, can you offer advice?
Question 2: (I asked this one before, but didn't see an answer.)
Suppose I have a file containing data serialized by calling object->u8vector and then written to a file. Suppose, further, that I happen to know that an object of interest to me starts at a specific byte offset within the file.
What's the right way to read that object from the file?
An additional constraint is that I don't want to have to read the entire contents of the file in order to read the object; I want to be able to read just enough bytes to reconstitute the object whose serialized representation starts at the given offset.
Thanks!
--me
Hallo,
On Fri, Jul 22, 2011 at 10:41 AM, mikel evins mevins@me.com wrote:
What's more, I'd like to set up and configure Gambit for development, along with some local libraries and tools, and package the resulting development platform as a file tree that other programmers can simply check out or untar on their systems to obtain the tools, with no (or minimal) additional configuration.
I've set up Gambit a number of times to build OSX apps (indeed, I have a Gambit-based app on the App Store). I've also set up and built iOS projects.
What I would like to do now is set up for both, and on iOS both for simulators and for devices, preferably with everything in a common containing directory so that the whole set of tools can conveniently be cloned from one machine to another. That way, that all involved programmers can easily set up identical toolsets.
I forked a project from James Long in GitHub[1] which is a "configure script helper", calling configure with appropriated parameters for creating binaries for the iOS simulator and for devices. It puts each one in its own tree, where you can keep adding libraries for each environment. I hope this helps.
[1] - https://github.com/asandroq/configure-iphone
Cheers,
On Jul 25, 2011, at 3:06 AM, Alex Queiroz wrote:
Hallo,
On Fri, Jul 22, 2011 at 10:41 AM, mikel evins mevins@me.com wrote:
What's more, I'd like to set up and configure Gambit for development, along with some local libraries and tools, and package the resulting development platform as a file tree that other programmers can simply check out or untar on their systems to obtain the tools, with no (or minimal) additional configuration.
I've set up Gambit a number of times to build OSX apps (indeed, I have a Gambit-based app on the App Store). I've also set up and built iOS projects.
What I would like to do now is set up for both, and on iOS both for simulators and for devices, preferably with everything in a common containing directory so that the whole set of tools can conveniently be cloned from one machine to another. That way, that all involved programmers can easily set up identical toolsets.
I forked a project from James Long in GitHub[1] which is a "configure script helper", calling configure with appropriated parameters for creating binaries for the iOS simulator and for devices. It puts each one in its own tree, where you can keep adding libraries for each environment. I hope this helps.
THanks much; I'll give it a look. It just might be the right thing.
On 2011-07-25, at 4:44 AM, mikel evins wrote:
On Jul 25, 2011, at 3:06 AM, Alex Queiroz wrote:
Hallo,
On Fri, Jul 22, 2011 at 10:41 AM, mikel evins mevins@me.com wrote:
What's more, I'd like to set up and configure Gambit for development, along with some local libraries and tools, and package the resulting development platform as a file tree that other programmers can simply check out or untar on their systems to obtain the tools, with no (or minimal) additional configuration.
I've set up Gambit a number of times to build OSX apps (indeed, I have a Gambit-based app on the App Store). I've also set up and built iOS projects.
What I would like to do now is set up for both, and on iOS both for simulators and for devices, preferably with everything in a common containing directory so that the whole set of tools can conveniently be cloned from one machine to another. That way, that all involved programmers can easily set up identical toolsets.
I forked a project from James Long in GitHub[1] which is a "configure script helper", calling configure with appropriated parameters for creating binaries for the iOS simulator and for devices. It puts each one in its own tree, where you can keep adding libraries for each environment. I hope this helps.
THanks much; I'll give it a look. It just might be the right thing.
Note that there is a similar script in the Gambit distribution. If you execute the script examples/iOS/build-gambit-iOS it will build Gambit in 2 configurations (for the real iPhone/iPad and for the simulator). If you uncomment the last line of the script, it will also build Gambit for Mac OS X. The script is highly automated (it even downloads a recent Gambit distribution, updates it with the latest patches on the Gambit repository, builds it for the device and simulator, and combines the libraries into one using "lipo"). You should also take a look at examples/iOS/GambitREPL.xcodeproj if you want to see an Xcode project which can run on the device and simulator.
If you can wait until this afternoon, I will be committing my latest GambitREPL patches to the repository.
Marc
On Jul 25, 2011, at 5:55 AM, Marc Feeley wrote:
On 2011-07-25, at 4:44 AM, mikel evins wrote:
On Jul 25, 2011, at 3:06 AM, Alex Queiroz wrote:
Hallo,
On Fri, Jul 22, 2011 at 10:41 AM, mikel evins mevins@me.com wrote:
What's more, I'd like to set up and configure Gambit for development, along with some local libraries and tools, and package the resulting development platform as a file tree that other programmers can simply check out or untar on their systems to obtain the tools, with no (or minimal) additional configuration.
I've set up Gambit a number of times to build OSX apps (indeed, I have a Gambit-based app on the App Store). I've also set up and built iOS projects.
What I would like to do now is set up for both, and on iOS both for simulators and for devices, preferably with everything in a common containing directory so that the whole set of tools can conveniently be cloned from one machine to another. That way, that all involved programmers can easily set up identical toolsets.
I forked a project from James Long in GitHub[1] which is a "configure script helper", calling configure with appropriated parameters for creating binaries for the iOS simulator and for devices. It puts each one in its own tree, where you can keep adding libraries for each environment. I hope this helps.
THanks much; I'll give it a look. It just might be the right thing.
Note that there is a similar script in the Gambit distribution. If you execute the script examples/iOS/build-gambit-iOS it will build Gambit in 2 configurations (for the real iPhone/iPad and for the simulator). If you uncomment the last line of the script, it will also build Gambit for Mac OS X. The script is highly automated (it even downloads a recent Gambit distribution, updates it with the latest patches on the Gambit repository, builds it for the device and simulator, and combines the libraries into one using "lipo"). You should also take a look at examples/iOS/GambitREPL.xcodeproj if you want to see an Xcode project which can run on the device and simulator.
If you can wait until this afternoon, I will be committing my latest GambitREPL patches to the repository.
I can always wait; waiting for your updates invariably yields something good.
Our project is presently using slightly-modified versions of build-gambit-iOS to set up tooling on our dev systems.
As things stand, the obvious way to build an iOS project is to copy the way it's done for Gambit-REPL, but that's not ideal. Don't get me wrong; it's great to have example sources that reliably build a Cocoa app for iOS on both devices and simulators, but we could wish for improvements. It would be nice if we didn't have to download two full sets of the Gambit sources per app. :-)
I don't want to ask for too much; I'm well aware that you're a busy guy, and we can certainly make things work as they stand.
I'll monkey with Makefiles and see what I can accomplish. I'd like to at least arrange things so that we can have just one copy of each flavor of the Gambit sources, and so that our project sources don't need to be in the Gambit source tree to build. I built my own Makefiles for Delectus and made things work, so I'm optimistic.
--me
On 2011-07-25, at 3:11 PM, mikel evins wrote:
On Jul 25, 2011, at 5:55 AM, Marc Feeley wrote:
On 2011-07-25, at 4:44 AM, mikel evins wrote:
On Jul 25, 2011, at 3:06 AM, Alex Queiroz wrote:
Hallo,
On Fri, Jul 22, 2011 at 10:41 AM, mikel evins mevins@me.com wrote:
What's more, I'd like to set up and configure Gambit for development, along with some local libraries and tools, and package the resulting development platform as a file tree that other programmers can simply check out or untar on their systems to obtain the tools, with no (or minimal) additional configuration.
I've set up Gambit a number of times to build OSX apps (indeed, I have a Gambit-based app on the App Store). I've also set up and built iOS projects.
What I would like to do now is set up for both, and on iOS both for simulators and for devices, preferably with everything in a common containing directory so that the whole set of tools can conveniently be cloned from one machine to another. That way, that all involved programmers can easily set up identical toolsets.
I forked a project from James Long in GitHub[1] which is a "configure script helper", calling configure with appropriated parameters for creating binaries for the iOS simulator and for devices. It puts each one in its own tree, where you can keep adding libraries for each environment. I hope this helps.
THanks much; I'll give it a look. It just might be the right thing.
Note that there is a similar script in the Gambit distribution. If you execute the script examples/iOS/build-gambit-iOS it will build Gambit in 2 configurations (for the real iPhone/iPad and for the simulator). If you uncomment the last line of the script, it will also build Gambit for Mac OS X. The script is highly automated (it even downloads a recent Gambit distribution, updates it with the latest patches on the Gambit repository, builds it for the device and simulator, and combines the libraries into one using "lipo"). You should also take a look at examples/iOS/GambitREPL.xcodeproj if you want to see an Xcode project which can run on the device and simulator.
If you can wait until this afternoon, I will be committing my latest GambitREPL patches to the repository.
I can always wait; waiting for your updates invariably yields something good.
Our project is presently using slightly-modified versions of build-gambit-iOS to set up tooling on our dev systems.
As things stand, the obvious way to build an iOS project is to copy the way it's done for Gambit-REPL, but that's not ideal. Don't get me wrong; it's great to have example sources that reliably build a Cocoa app for iOS on both devices and simulators, but we could wish for improvements. It would be nice if we didn't have to download two full sets of the Gambit sources per app. :-)
I don't want to ask for too much; I'm well aware that you're a busy guy, and we can certainly make things work as they stand.
I'll monkey with Makefiles and see what I can accomplish. I'd like to at least arrange things so that we can have just one copy of each flavor of the Gambit sources, and so that our project sources don't need to be in the Gambit source tree to build. I built my own Makefiles for Delectus and made things work, so I'm optimistic.
--me
The Gambit REPL changes have now been committed to the repo.
Note that the new build-gambit-iOS script makes a single copy of the Gambit sources. It compiles it 3 times (i386 for the simulator, and armv6 and armv7 for the real devices), and combines the libraries using "lipo". In the end the gambit-iOS directory that is created takes up 132 MB, of which 32 MB are the libraries themselves. It isn't that much in today's standards, but if you need space you could just keep the libraries that matter to you and delete the rest.
You could also save a lot of space by changing the script so that it doesn't download the distribution "for developers" (which contains the git history). In other words, change:
gambit_dist_if_downloaded="gambc-v4_6_1-devel" update_with_latest_changes_if_downloaded="yes"
to
gambit_dist_if_downloaded="gambc-v4_6_1" update_with_latest_changes_if_downloaded="no"
But in that case you will not be using the very latest sources from the repository.
BTW, if you manage to write a generic makefile to build iOS applications from the command line (no XCode) then I'm interested in having a look.
Marc
On Jul 25, 2011, at 3:15 PM, Marc Feeley wrote:
BTW, if you manage to write a generic makefile to build iOS applications from the command line (no XCode) then I'm interested in having a look.
Can you say more about what you want to accomplish? At this stage, I'm pretty sure this is doable; the question is exactly what you want to do. For example, if you're okay with having an XCode project and nibfiles, and you just don't want to have to actually launch the XCode application, then it should be pretty easy. If, on the other hand, you want to dispense entirely with XCode projects and nibfiles then I think it's probably still doable, but not quite as easy.
--me
Hi Mike, I think there's a general interest on the list for knowing how to do either of these. If you would want to give an introductory idea of how this is done I'm sure it'd be appreciated. Kind regards, Mikael
2011/9/6 mikel evins mevins@me.com
On Jul 25, 2011, at 3:15 PM, Marc Feeley wrote:
BTW, if you manage to write a generic makefile to build iOS applications
from the command line (no XCode) then I'm interested in having a look.
Can you say more about what you want to accomplish? At this stage, I'm pretty sure this is doable; the question is exactly what you want to do. For example,
1)
if you're okay with having an XCode project and nibfiles, and you just don't want to have to actually launch the XCode application, then it should be pretty easy. If, on the other hand,
2)
you want to dispense entirely with XCode projects and nibfiles then I think it's probably still doable, but not quite as easy.
--me
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
On Sep 9, 2011, at 4:19 PM, Mikael wrote:
2011/9/6 mikel evins mevins@me.com On Jul 25, 2011, at 3:15 PM, Marc Feeley wrote:
BTW, if you manage to write a generic makefile to build iOS applications from the command line (no XCode) then I'm interested in having a look.
Can you say more about what you want to accomplish? At this stage, I'm pretty sure this is doable; the question is exactly what you want to do. For example,
- if you're okay with having an XCode project and nibfiles, and you just don't want to have to actually launch the XCode application, then it should be pretty easy. If, on the other hand,
- you want to dispense entirely with XCode projects and nibfiles then I think it's probably still doable, but not quite as easy.
Hi Mike, I think there's a general interest on the list for knowing how to do either of these. If you would want to give an introductory idea of how this is done I'm sure it'd be appreciated. Kind regards, Mikael
Fair enough. Let me see if I can knock together a simple example project.
We don't presently have a project that builds an iOS app from Scheme sources without involving XCode. What we do have is several working projects that, taken together, seem to have all the pieces you would need. We have:
1. An iOS game app written partly in Gambit Scheme, and a working Gambit toolchain for building it for the iOS simulator and devices.
2. Delectus, a simple list-management app for Mac OS X that is written mainly in Gambit Scheme. It includes conventional nibfiles and some Objective-C code, but it builds from a Makefile without involving XCode.
3. A new version of one of my older apps, written entirely in Common Lisp. It presents a normal Cocoa UI, but it builds from a Makefile and uses no nibfiles at all and no XCode project.
I think that by combining approaches from those three projects I should be able to produce a sample project that builds a standard Cocoa UI on iOS without involving XCode. Of course, it's always possible that I'll run into some new snag, but I'll give it a try.
--me
On Sep 9, 2011, at 4:19 PM, Mikael wrote:
Hi Mike, I think there's a general interest on the list for knowing how to do either of these. If you would want to give an introductory idea of how this is done I'm sure it'd be appreciated. Kind regards, Mikael
As a first step, here's a simple example with a Makefile that can build executables for iOS or for the iOS simulator:
https://files.codebasehq.com/upload/84813b88-8192-6721-b1be-ed6c20ee9df7/ori...
This is not a complete solution. I've posted it because it may prove useful for someone wanting to figure out how to make a Makefile to build Gambit programs for iOS or the iOS Simulator.
The current version of Amphora does not do everything you would need to build and install a working iOS app. It simply builds executable programs for iOS and the iOS simulator from Scheme (with a bit of embedded Objective-C).
To do a full build, i.e. to make an app that can be installed and run on an iOS device or simulator, you'd need to add some more bits:
- you need a Make rule to build nibs from xibs; here's an example that works for one of our projects:
ibtool ./Contents/Resources/English.lproj/MainMenu.xib --compile ./${BUNDLE}/Contents/Resources/English.lproj/MainMenu.nib
- you need to add a rule to create the application bundle:
mkdir -p ./${BUNDLE}/Contents/Resources/English.lproj/ mkdir -p ./${BUNDLE}/Contents/MacOS
- you need to add a rule to copy the Info.plist and other resources into the bundle
- if you want to use nibfiles, then you need to add rules to compile them. For example:
ibtool ./Contents/Resources/English.lproj/MainMenu.xib --compile ./${BUNDLE}/Contents/Resources/English.lproj/MainMenu.nib
If you don't want to use nibs, then you need to write code to build the UI programatically. That's doable, but I think a bit too involved to include in a note like this.
- you'll need to codesign the executable. Apple provides the codesign command-line tool for this purpose, and I've successfully used it to help a colleague prepare a game (written in Python) for the App Store.
I may add more to Amphora if there's demand for it.
On Sep 10, 2011, at 4:27 PM, mikel evins wrote:
On Sep 9, 2011, at 4:19 PM, Mikael wrote:
Hi Mike, I think there's a general interest on the list for knowing how to do either of these. If you would want to give an introductory idea of how this is done I'm sure it'd be appreciated. Kind regards, Mikael
As a first step, here's a simple example with a Makefile that can build executables for iOS or for the iOS simulator:
Oh, heck; I omitted some important information: Amphora will not build unless you have a suitably-configured Gambit toolchain. What you need is Gambit built for Mac OS X, for iOS, and for iOS Simulator. The Amphora Makefile assumes that these are at the paths:
/usr/local/gambit/iphone /usr/local/gambit/iphone-simulator /usr/local/gambit/macosx
Basically, build a recent Gambit for Mac OS X and put it at /usr/local/gambit/macosx.
Then, using the iOS example in the Gambit distribution, build Gambit for iOS and iOS simulator, and put them at the appropriate paths.
You will of course need to have Apple's Developer tools installed. The Amphora project as-distributed assumes you are using iOS SDK 5.0, as I am, but it should be possible to tweak that with suitable edits of the Makefile.
On 2011-07-22, at 4:41 AM, mikel evins wrote:
Question 2: (I asked this one before, but didn't see an answer.)
Suppose I have a file containing data serialized by calling object->u8vector and then written to a file. Suppose, further, that I happen to know that an object of interest to me starts at a specific byte offset within the file.
What's the right way to read that object from the file?
An additional constraint is that I don't want to have to read the entire contents of the file in order to read the object; I want to be able to read just enough bytes to reconstitute the object whose serialized representation starts at the given offset.
The object encoding used by object->u8vector (and u8vector->object) does not contain a length. The stream of bytes has to be parsed to know how long the object encoding is. To facilitate I/O, I usually prefix the encoding with a 32 bit integer which indicates the length of the encoding.
A second problem is that the object encoding supports shared structures. This means that the object created with
(let ((shared (cons 1 2))) (cons shared (cons 3 shared)))
will be encoded with something like this:
OBJ0=[pair OBJ1=[pair 1 2] OBJ2=[pair 3 OBJ1] ]
or if you want all the details:
(object->u8vector
(let ((shared (cons 1 2))) (cons shared (cons 3 shared)))) #u8(100 100 81 82 100 83 129 0) ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | 1 2 | 3 reference to shared object 0 | | | | | "pair" (index 2) | | | "pair" (index 1) | "pair" (index 0)
So you can't just start parsing an object from an arbitrary point inside the encoding. Some context will be missing.
The approach I would take is to dump each object independently in the file and keep a separate index of where each object starts, and its length (then use input-port-byte-position to seek to the right place). Even better, store the serialized objects in a database and let it do the indexing for you (it also simplifies deleting objects).
Marc
On Jul 25, 2011, at 6:23 AM, Marc Feeley wrote:
On 2011-07-22, at 4:41 AM, mikel evins wrote:
Question 2: (I asked this one before, but didn't see an answer.)
Suppose I have a file containing data serialized by calling object->u8vector and then written to a file. Suppose, further, that I happen to know that an object of interest to me starts at a specific byte offset within the file.
What's the right way to read that object from the file?
An additional constraint is that I don't want to have to read the entire contents of the file in order to read the object; I want to be able to read just enough bytes to reconstitute the object whose serialized representation starts at the given offset.
The object encoding used by object->u8vector (and u8vector->object) does not contain a length. The stream of bytes has to be parsed to know how long the object encoding is. To facilitate I/O, I usually prefix the encoding with a 32 bit integer which indicates the length of the encoding.
A second problem is that the object encoding supports shared structures. This means that the object created with
(let ((shared (cons 1 2))) (cons shared (cons 3 shared)))
will be encoded with something like this:
OBJ0=[pair OBJ1=[pair 1 2] OBJ2=[pair 3 OBJ1] ]
or if you want all the details:
(object->u8vector
(let ((shared (cons 1 2))) (cons shared (cons 3 shared))))#u8(100 100 81 82 100 83 129 0) ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | 1 2 | 3 reference to shared object 0 | | | | | "pair" (index 2) | | | "pair" (index 1) | "pair" (index 0)
So you can't just start parsing an object from an arbitrary point inside the encoding. Some context will be missing.
The approach I would take is to dump each object independently in the file and keep a separate index of where each object starts, and its length (then use input-port-byte-position to seek to the right place). Even better, store the serialized objects in a database and let it do the indexing for you (it also simplifies deleting objects).
Thanks very much, Marc; this is very helpful.
We're using Gambit serialization to implement an embedded database engine of our own. For this project, we can guarantee that we won't need to store shared references to objects, which simplifies things a bit.
Here's a sketch of the solution we're using: The database file is log structured, with a header that includes an offset field. The offset field points to the location of an object table, and is the only mutable field in the file.
Scheme objects are stored in the file as bytevectors produced by object->u8vector, with a length field prepended. Given an offset and a promise that it's the start of an object record, we can reconstitute the object simply by reading the length, then reading that many bytes and passing the resulting bytevector to u8vector->object.
Data, once written, is never mutated, though new data are appended. New data are not written directly to the database file; instead transaction records are appended to a transaction log as updates in RAM occur. At suitable intervals, the database subsystem consolidates ranges of transaction records and writes new objects to the database file, appending an updated object table and updating the offset field at the top of the file. (In this way, a crash can result in a database file with a range of inaccessible garbage objects near the end, but cannot result in accessible garbage values, because the object table is written only after all new values have been written, and the offset field is updated only after the new object table is written.)
The on-disk object table is simply a serialized Scheme object that maps oids to offsets.
-
Alex Queiroz -
Bradley Lucier -
Marc Feeley -
Mikael -
mikel evins