I've been trying to figure out why some gambit scheme code has stopped working under iOS 5.0 beta1. It works fine under 4.3 and the 5.0 simulator, but errors out on the actual iPad running 5.0. Here's the code:
(with-input-from-file (list path: (##scm-resource "test.scm")) (lambda () (println "HI"))
Prints "HI" under 4.3 (sim and device) and 5.0 sim - but throws: "Operation not permitted" on a 5.0 device. Any ideas? Also (load) has stopped working, throwing the same error. Yes, 5.0 is under NDA - but I'm not talking about any new api or features. Could it be due to more strict file perms? I tried accessing the file from both the app bundle and under 'Documents' - no difference. Thanks
Afficher les réponses par date
On Jun 14, 2011, at 10:15 PM, Adam King wrote:
Yes, 5.0 is under NDA - but I'm not talking about any new api or features.
I believe you'll find that your NDA is more restrictive than that - any discussion of the software under NDA, even discussion of new bugs in old features from previous versions, is prohibited.
warmest regards,
Ralph
Raffael Cavallaro raffaelcavallaro@me.com
Alright - that might very well be true - and it probably did say that in the 60 or more pages of legalese that I doubt most devs have time to read through. I know... that's not a valid excuse :)
So, let me reframe the question: in what circumstances could 'with-input-from-file' and 'load' generate an 'Operation not permitted' error on a unix type system even when the file is readable? I tried tracing both funcs in the gambit lib, but soon got lost. Maybe the lib is doing more than just fopen/fread? I thought Marc might have an idea.
On Tue, Jun 14, 2011 at 10:31 PM, Raffael Cavallaro < raffaelcavallaro@mac.com> wrote:
On Jun 14, 2011, at 10:15 PM, Adam King wrote:
Yes, 5.0 is under NDA - but I'm not talking about any new api or
features.
I believe you'll find that your NDA is more restrictive than that - any discussion of the software under NDA, even discussion of new bugs in old features from previous versions, is prohibited.
warmest regards,
Ralph
Raffael Cavallaro raffaelcavallaro@me.com
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
On 2011-06-14, at 10:54 PM, Adam King wrote:
Alright - that might very well be true - and it probably did say that in the 60 or more pages of legalese that I doubt most devs have time to read through. I know... that's not a valid excuse :)
So, let me reframe the question: in what circumstances could 'with-input-from-file' and 'load' generate an 'Operation not permitted' error on a unix type system even when the file is readable? I tried tracing both funcs in the gambit lib, but soon got lost. Maybe the lib is doing more than just fopen/fread? I thought Marc might have an idea.
On Mac OS X (and Unix) the path to the file is opened with a call to "open", and then the file descriptor is set to non-blocking mode with a call to set_fd_blocking_mode (defined in os_io.c) which calls fcntl(fd,F_GETFL, 0) and fcntl(fd,F_SETFL, ...). You might want to change the call to set_fd_blocking_mode on line 6072 of os_io.c
if (set_fd_blocking_mode (fd, 0) != 0) /* set nonblocking mode */ return err_code_from_errno ();
to
if (kind != ___FILE_DEVICE_KIND) if (set_fd_blocking_mode (fd, 0) != 0) /* set nonblocking mode */ return err_code_from_errno ();
and see if that eliminates the problem. Of course this makes I/O to files blocking, so the thread multiplexing will not work when doing I/O to files.
Have you tried compiling the Gambit library with the --enable-debug configuration flag? It will output traces for all the system calls which return errors, with the name of the source file and line number where the error was detected.
Marc
You nailed it! I'm most impressed :) As I had updated to the latest gambit git source last night trying to solve things, I went ahead and just recompiled the lib with '--enable-debug' first (which I'll keep enabled till end of beta) and got the following:
[1308145045.216022][USER]: [init] DATA ROOT: /var/mobile/Applications/67AF0861-1AB4-43CD-8821-BFEEF287DEBA/gateway.app/data/ path="/var/mobile/Applications/67AF0861-1AB4-43CD-8821-BFEEF287DEBA/gateway.app/src/app/main.scm" fl=4 fd=6 kind=31 direction=1 *** OS ERROR AT "os_io.c"@6073.1 -- errno=1 (Operation not permitted)
It was, indeed, setting it to non-blocking that was generating it. After adding your suggested mod, it now works again. I was also able to replicate the error in your iOS Gambit REPL App with:
(open-input-file "~~/Info.plist")
*** ERROR IN (console)@1.1 -- Operation not permitted
I'll do up a sample native ObjC version of setting the file to non-blocking and submit it as a bug report to Apple. Note: the same error occurs even for app created files placed in 'Documents'. Thanks!
Adam
On Wed, Jun 15, 2011 at 7:44 AM, Marc Feeley feeley@iro.umontreal.cawrote:
On 2011-06-14, at 10:54 PM, Adam King wrote:
Alright - that might very well be true - and it probably did say that in
the 60 or more pages of legalese that I doubt most devs have time to read through. I know... that's not a valid excuse :)
So, let me reframe the question: in what circumstances could
'with-input-from-file' and 'load' generate an 'Operation not permitted' error on a unix type system even when the file is readable? I tried tracing both funcs in the gambit lib, but soon got lost. Maybe the lib is doing more than just fopen/fread? I thought Marc might have an idea.
On Mac OS X (and Unix) the path to the file is opened with a call to "open", and then the file descriptor is set to non-blocking mode with a call to set_fd_blocking_mode (defined in os_io.c) which calls fcntl(fd,F_GETFL, 0) and fcntl(fd,F_SETFL, ...). You might want to change the call to set_fd_blocking_mode on line 6072 of os_io.c
if (set_fd_blocking_mode (fd, 0) != 0) /* set nonblocking mode */ return err_code_from_errno ();
to
if (kind != ___FILE_DEVICE_KIND) if (set_fd_blocking_mode (fd, 0) != 0) /* set nonblocking mode */ return err_code_from_errno ();
and see if that eliminates the problem. Of course this makes I/O to files blocking, so the thread multiplexing will not work when doing I/O to files.
Have you tried compiling the Gambit library with the --enable-debug configuration flag? It will output traces for all the system calls which return errors, with the name of the source file and line number where the error was detected.
Marc
On Wed, Jun 15, 2011 at 07:44:15AM -0400, Marc Feeley wrote:
and see if that eliminates the problem. Of course this makes I/O to files blocking, so the thread multiplexing will not work when doing I/O to files.
My understanding is that for regular files, nonblocking mode is essentially a no-op, as regular files don't block in the way, say, an interactive prompt or a network socket would.
Can someone confirm or disprove this?
-Alan
Hm, what about if the harddrive is busy with higher-prioritized IO operations. In this case I suppose the a nonblocking file read is supposed to return with 0 bytes immediately - what do you say?
Though, I suppose there's no way to know from the OS when the drive will be ready for making access again since there's no async-ness in the standard file read procedure, I wonder how Gambit works in relation with that currently (though it's really a kind of exotic situation).
Mikael
2011/6/15 Alan Post alanpost@sunflowerriver.org
On Wed, Jun 15, 2011 at 07:44:15AM -0400, Marc Feeley wrote:
and see if that eliminates the problem. Of course this makes I/O to
files blocking, so the thread multiplexing will not work when doing I/O to files.
My understanding is that for regular files, nonblocking mode is essentially a no-op, as regular files don't block in the way, say, an interactive prompt or a network socket would.
Can someone confirm or disprove this?
-Alan
.i ma'a lo bradi ku penmi gi'e du _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list