From icfp.publicity at googlemail.com Fri Aug 1 17:50:23 2014 From: icfp.publicity at googlemail.com (David Van Horn) Date: Fri, 1 Aug 2014 17:50:23 -0400 Subject: [gambit-list] ICFP 2014 Final Call for Participation Message-ID: [ Early registration ends 3 Aug; Invited speakers and conference program have been announced. ] ===================================================================== Final Call for Participation ICFP 2014 19th ACM SIGPLAN International Conference on Functional Programming and affiliated events August 31 - September 6, 2014 Gothenburg, Swedenhttp://icfpconference.org/icfp2014/ ===================================================================== ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. A full week dedicated to functional programming: 1 conference, 1 symposium, 10 workshops, tutorials, programming contest results, student research competition * Program: http://icfpconference.org/icfp2014/program.html * Accepted Papers: http://icfpconference.org/icfp2014/accepted.html * Local arrangements (including travel and accommodation): http://icfpconference.org/icfp2014/local.html * Registration is available via: https://regmaster4.com/2014conf/ICFP14/register.php Early registration is due 3 August, 2014. * Programming contest, 25-28 July, 2014: http://icfpcontest.org/ * Follow @icfp_conference on twitter for the latest news: http://twitter.com/#!/icfp_conference Keynote speakers: * Kathleen Fisher (Tufts University): Using Formal Methods to Enable More Secure Vehicles: DARPA's HACMS Program * Robert Bruce Findler (Northwestern University): Behavioral Software Contracts * Stephanie Weirich (University of Pennsylvania): Depending on Types There are several events affiliated with ICFP: Sunday, August 31 ACM SIGPLAN Workshop on Generic Programming ACM SIGPLAN Workshop on Higher-order Programming with Effects Monday, September 1 ? Wednesday, September 3 ICFP Thursday, September 4 ACM SIGPLAN Commercial Users of Functional Programming: Day 1, Tutorials ACM SIGPLAN Haskell Symposium: Day 1 ACM SIGPLAN Workshop on Functional High-Performance Computing ACM SIGPLAN ML Family Workshop Friday, September 5 ACM SIGPLAN Commercial Users of Functional Programming: Day 2, Tutorials ACM SIGPLAN Haskell Symposium: Day 2 ACM SIGPLAN OCaml Workshop ACM SIGPLAN Erlang Workshop Saturday, September 6 ACM SIGPLAN Commercial Users of Functional Programming: Day 3, Talks ACM SIGPLAN Haskell Implementors Workshop ACM SIGPLAN Workshop on Functional Art, Music, Modeling and Design Conference Organizers General Chair: Johan Jeuring, Utrecht University Program Chair: Manuel Chakravarty, University of New South Wales Local Arrangements Chair: Bj?rn von Sydow, Chalmers University Industrial Relations Chair: Anil Madhavapeddy, University of Cambridge Workshop Co-Chairs: Tom Schrijvers, Ghent University Sam Tobin-Hochstadt, Indiana University Programming Contest Co-Chairs: Duncan Coutts, Well Typed LLP Nicolas Wu, University of Oxford Student Research Competition Chair: Meng Wang, Chalmers University Publicity Chair: David Van Horn, University of Maryland Video Chair: Iavor Diatchki, Galois Malcolm Wallace, Standard Chartered Bank Industrial partners: Platinum partners Jane Street Capital Gold partners Google Microsoft Research Mozilla Oracle Labs Standard Chartered Bank Silver partners Bloomberg Credit Suisse CyberPoint Erlang Solutions Facebook Galois Klarna Lexifi Twitter Bronze partners Alephcloud IntelliFactory Opera Software QuviQ Systeor Vest AS ===================================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://webmail.iro.umontreal.ca/pipermail/gambit-list/attachments/20140801/986fae68/attachment.html From alvaro.castro.castilla at gmail.com Thu Aug 7 07:46:42 2014 From: alvaro.castro.castilla at gmail.com (=?UTF-8?Q?=C3=81lvaro_Castro=2DCastilla?=) Date: Thu, 7 Aug 2014 13:46:42 +0200 Subject: [gambit-list] Gambit and event-based systems Message-ID: Hi, Specially in the mobile world, there are many platforms that force the developer to think and code its applications around events. Sometimes this is done with virtual functions or interface implementation, overriding methods, or plain C-style callbacks. The problem is, in any of these cases, generally the main loop is controlled by the application. Since Gambit runs within the ___setup(params) function, and then quits (expecting ___cleanup() to be called), there is no way to easily adapt to this architecture except for running in a separate thread and communicating through messages or shared data. Is there a better way to do this? Best regards, ?lvaro Castro-Castilla Digital Experiences. -- visit The Blog -------------- next part -------------- An HTML attachment was scrubbed... URL: http://webmail.iro.umontreal.ca/pipermail/gambit-list/attachments/20140807/622714a6/attachment.html From asandroq at gmail.com Thu Aug 7 07:56:55 2014 From: asandroq at gmail.com (Alex Queiroz) Date: Thu, 7 Aug 2014 13:56:55 +0200 Subject: [gambit-list] Gambit and event-based systems In-Reply-To: References: Message-ID: Hallo, On Thu, Aug 7, 2014 at 1:46 PM, ?lvaro Castro-Castilla wrote: > > Hi, > > Specially in the mobile world, there are many platforms that force the developer to think and code its applications around events. Sometimes this is done with virtual functions or interface implementation, overriding methods, or plain C-style callbacks. > > The problem is, in any of these cases, generally the main loop is controlled by the application. Since Gambit runs within the ___setup(params) function, and then quits (expecting ___cleanup() to be called), there is no way to easily adapt to this architecture except for running in a separate thread and communicating through messages or shared data. > > Is there a better way to do this? > Why can't you package your program as a C library that has an API for the events? Cheers, -- -alex http://unendli.ch/ From alvaro.castro.castilla at gmail.com Thu Aug 7 08:13:20 2014 From: alvaro.castro.castilla at gmail.com (=?UTF-8?Q?=C3=81lvaro_Castro=2DCastilla?=) Date: Thu, 7 Aug 2014 14:13:20 +0200 Subject: [gambit-list] Gambit and event-based systems In-Reply-To: References: Message-ID: On Thu, Aug 7, 2014 at 1:56 PM, Alex Queiroz wrote: > Hallo, > > On Thu, Aug 7, 2014 at 1:46 PM, ?lvaro Castro-Castilla > wrote: > > > > Hi, > > > > Specially in the mobile world, there are many platforms that force the > developer to think and code its applications around events. Sometimes this > is done with virtual functions or interface implementation, overriding > methods, or plain C-style callbacks. > > > > The problem is, in any of these cases, generally the main loop is > controlled by the application. Since Gambit runs within the > ___setup(params) function, and then quits (expecting ___cleanup() to be > called), there is no way to easily adapt to this architecture except for > running in a separate thread and communicating through messages or shared > data. > > > > Is there a better way to do this? > > > > Why can't you package your program as a C library that has an API for > the events? > > That works for implementing the events, but where is the Gambit ___setup function running? You can't return from this function without breaking Gambit's system. If there is just one thread, how can you run Gambit, then leave the ___setup function and let the system call whatever event it requires? For instance, in SDL2, you are required to define a draw/update callback in iOS and then leave the main. If you don't return from Gambit's ___setup() in main, the draw/update callback is never run. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://webmail.iro.umontreal.ca/pipermail/gambit-list/attachments/20140807/86b51dfd/attachment.html From asandroq at gmail.com Thu Aug 7 08:19:16 2014 From: asandroq at gmail.com (Alex Queiroz) Date: Thu, 7 Aug 2014 14:19:16 +0200 Subject: [gambit-list] Gambit and event-based systems In-Reply-To: References: Message-ID: Hallo, On Thu, Aug 7, 2014 at 2:13 PM, ?lvaro Castro-Castilla wrote: > > That works for implementing the events, but where is the Gambit ___setup > function running? You can't return from this function without breaking > Gambit's system. > `___setup` doesn't need to be "running". You call it and after it is finished, you can call your functions. If your code needs to do work in the background, you can install a timer in the host system and keep calling into Gambit. Cheers, -- -alex http://unendli.ch/ From alvaro.castro.castilla at gmail.com Thu Aug 7 08:31:57 2014 From: alvaro.castro.castilla at gmail.com (=?UTF-8?Q?=C3=81lvaro_Castro=2DCastilla?=) Date: Thu, 7 Aug 2014 14:31:57 +0200 Subject: [gambit-list] Gambit and event-based systems In-Reply-To: References: Message-ID: On Thu, Aug 7, 2014 at 2:19 PM, Alex Queiroz wrote: > Hallo, > > On Thu, Aug 7, 2014 at 2:13 PM, ?lvaro Castro-Castilla > wrote: > > > > That works for implementing the events, but where is the Gambit ___setup > > function running? You can't return from this function without breaking > > Gambit's system. > > > > `___setup` doesn't need to be "running". You call it and after it is > finished, you can call your functions. If your code needs to do work > in the background, you can install a timer in the host system and keep > calling into Gambit. > > Yes, you are right. I've actually done it long time ago, now that I recall. Let me try the idea, and see if I can cleanly satisfy the library requirement. But yes, apparently I wasn't thinking, since if you don't have to keep running ___setup() then it's easy to implement callbacks. Actually, the name ___setup and the fact that ___cleanup is an independent function makes it pretty clear. Otherwise it would have been ___run or something similar. The confusion stemmed from the fact that I was running Scheme code directly without calling any (c-define)'d function after ___setup(). But as I said, I've done that before, so I wasn't thinking. Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://webmail.iro.umontreal.ca/pipermail/gambit-list/attachments/20140807/cecec8af/attachment.html From alvaro.castro.castilla at gmail.com Thu Aug 7 09:06:26 2014 From: alvaro.castro.castilla at gmail.com (=?UTF-8?Q?=C3=81lvaro_Castro=2DCastilla?=) Date: Thu, 7 Aug 2014 15:06:26 +0200 Subject: [gambit-list] Gambit and event-based systems In-Reply-To: References: Message-ID: On Thu, Aug 7, 2014 at 2:31 PM, ?lvaro Castro-Castilla < alvaro.castro.castilla at gmail.com> wrote: > > On Thu, Aug 7, 2014 at 2:19 PM, Alex Queiroz wrote: > >> Hallo, >> >> On Thu, Aug 7, 2014 at 2:13 PM, ?lvaro Castro-Castilla >> wrote: >> > >> > That works for implementing the events, but where is the Gambit ___setup >> > function running? You can't return from this function without breaking >> > Gambit's system. >> > >> >> `___setup` doesn't need to be "running". You call it and after it is >> finished, you can call your functions. If your code needs to do work >> in the background, you can install a timer in the host system and keep >> calling into Gambit. >> >> > Yes, you are right. I've actually done it long time ago, now that I > recall. Let me try the idea, and see if I can cleanly satisfy the library > requirement. > > But yes, apparently I wasn't thinking, since if you don't have to keep > running ___setup() then it's easy to implement callbacks. Actually, the > name ___setup and the fact that ___cleanup is an independent function makes > it pretty clear. Otherwise it would have been ___run or something similar. > The confusion stemmed from the fact that I was running Scheme code directly > without calling any (c-define)'d function after ___setup(). But as I said, > I've done that before, so I wasn't thinking. > > Thank you! > Okay, it wasn't that easy. I *do* need to have a Gambit thread running a loop in the background as well. How can I keep that loop running? When you said "install a timer in the host system and keep calling" you mean that I need to break up that loop into a callback which is called with a repeating timer? (I think this is not a good solution). And then, where would you create and start that thread? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://webmail.iro.umontreal.ca/pipermail/gambit-list/attachments/20140807/b3c5ef47/attachment-0001.html From hendrik at topoi.pooq.com Thu Aug 7 09:26:42 2014 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 7 Aug 2014 09:26:42 -0400 Subject: [gambit-list] Gambit and event-based systems In-Reply-To: References: Message-ID: <20140807132642.GA19394@topoi.pooq.com> On Thu, Aug 07, 2014 at 01:46:42PM +0200, ?lvaro Castro-Castilla wrote: > Hi, > > Specially in the mobile world, there are many platforms that force the > developer to think and code its applications around events. Sometimes this > is done with virtual functions or interface implementation, overriding > methods, or plain C-style callbacks. > > The problem is, in any of these cases, generally the main loop is > controlled by the application. Since Gambit runs within the > ___setup(params) function, and then quits (expecting ___cleanup() to be > called), there is no way to easily adapt to this architecture except for > running in a separate thread and communicating through messages or shared > data. > > Is there a better way to do this? This is a fundamental flaw in event-loop systems -- that they have to take over control. And they are usually not designed with the understanding that the whole application might need two such subsystems. Proper design would design an event-loop so that (a) the user can provide it with additional things to be done during each loop and/or (b) There's a function that can be called that performs one iteration of the event-loop, so that the user can have a loop that calls it frequently. Even so, there are probably things that are difficult, such as avoiding busy-waiting. Sometimes separate threads are the best answer, if the synchronisation mecchanisms are fast enough. -- hendrik From euccastro at gmail.com Thu Aug 7 12:37:43 2014 From: euccastro at gmail.com (Estevo) Date: Thu, 7 Aug 2014 18:37:43 +0200 Subject: [gambit-list] Gambit and event-based systems In-Reply-To: References: Message-ID: > Okay, it wasn't that easy. I *do* need to have a Gambit thread running a > loop in the background as well. How can I keep that loop running? > What do you need to do in this thread exactly? I imagine that loop will keep running as long as you are in the Scheme world, that is, handling any type of event. Unfortunately, in an event-based system your app will by default spend much of the time in the C world, waiting for things to happen. A way to work around that is suggested below. > When you said "install a timer in the host system and keep calling" you > mean that I need to break up that loop into a callback which is called with > a repeating timer? (I think this is not a good solution). > If you really prefer to implement your background task as a loop in a gambit thread, you can communicate between the 'main' (event-system controlled) and 'worker' gambit threads via gambit thread mailboxes. So your timer handler just sends a message to the worker thread and waits for a message in response. So the worker loop blocks waiting for a message at the beginning of each iteration and sends a message back at the end. The content of these messages can be bogus and ignored both ways. What this achieves is setting apart some time to give your logic a chance to run. Also, many event-based systems have an 'on idle' event type such that if you register to listen for it, your handler will get triggered whenever the application is doing nothing. So if you don't really need your background logic to happen in regularly timed ticks, using the idle handler instead might make better use of processing time left over from event handling and rendering. As a step further in this direction, you can have *all* your event handlers works like this, just delegating the real work to the "worker" gambit thread through mailboxes, and then you can make your code feel pretty much as though you controlled the main event loop. In this case, the messages sent to mailboxes would contain information about the events. So the worker thread can switch over event type, just as in plain SDL. Note you still need a timer or idle handler to have stuff happen outside of user input and redraw events. In this case your "worker" thread looks and feels pretty much like a "main" thread. The event handlers themselves only contain stubs. > And then, where would you create and start that thread? > I don't know the specifics of your platform. In some, starting the event loop is done explicitly, so you can create the thread before you do that. In others, there is an 'init' event type. Where would you, for example, initialize OpenGL state that will not change throughout your application? I bet somewhere around there you might be able to launch that thread too. As a last resort, you can just do it the first time that any event handler gets called. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://webmail.iro.umontreal.ca/pipermail/gambit-list/attachments/20140807/31117ec8/attachment.html From euccastro at gmail.com Thu Aug 7 12:57:08 2014 From: euccastro at gmail.com (Estevo) Date: Thu, 7 Aug 2014 18:57:08 +0200 Subject: [gambit-list] Gambit and event-based systems In-Reply-To: <20140807132642.GA19394@topoi.pooq.com> References: <20140807132642.GA19394@topoi.pooq.com> Message-ID: Yes, I'll add that my response was meant for *one* main-loop-hoarding framework. If you need to use more than one of these, things get hairy quickly and it's hard to make general suggestions without knowing the exact APIs you're given. On Thu, Aug 7, 2014 at 3:26 PM, Hendrik Boom wrote: > On Thu, Aug 07, 2014 at 01:46:42PM +0200, ?lvaro Castro-Castilla wrote: > > Hi, > > > > Specially in the mobile world, there are many platforms that force the > > developer to think and code its applications around events. Sometimes > this > > is done with virtual functions or interface implementation, overriding > > methods, or plain C-style callbacks. > > > > The problem is, in any of these cases, generally the main loop is > > controlled by the application. Since Gambit runs within the > > ___setup(params) function, and then quits (expecting ___cleanup() to be > > called), there is no way to easily adapt to this architecture except for > > running in a separate thread and communicating through messages or shared > > data. > > > > Is there a better way to do this? > > This is a fundamental flaw in event-loop systems -- that they have to > take over control. And they are usually not designed with the > understanding that the whole application might need two such > subsystems. > > Proper design would design an event-loop so that > (a) the user can provide it with additional things to be done during > each loop > and/or > (b) There's a function that can be called that performs one iteration > of the event-loop, so that the user can have a loop that calls it > frequently. > > Even so, there are probably things that are difficult, such as avoiding > busy-waiting. Sometimes separate threads are the best answer, if the > synchronisation mecchanisms are fast enough. > > -- hendrik > _______________________________________________ > Gambit-list mailing list > Gambit-list at iro.umontreal.ca > https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://webmail.iro.umontreal.ca/pipermail/gambit-list/attachments/20140807/12a9cac5/attachment.html From alvaro.castro.castilla at gmail.com Thu Aug 7 13:06:00 2014 From: alvaro.castro.castilla at gmail.com (=?UTF-8?Q?=C3=81lvaro_Castro=2DCastilla?=) Date: Thu, 7 Aug 2014 19:06:00 +0200 Subject: [gambit-list] Gambit and event-based systems In-Reply-To: References: Message-ID: On Thu, Aug 7, 2014 at 6:37 PM, Estevo wrote: > > Okay, it wasn't that easy. I *do* need to have a Gambit thread running a >> loop in the background as well. How can I keep that loop running? >> > > What do you need to do in this thread exactly? > > I imagine that loop will keep running as long as you are in the Scheme > world, that is, handling any type of event. Unfortunately, in an > event-based system your app will by default spend much of the time in the C > world, waiting for things to happen. A way to work around that is > suggested below. > > >> When you said "install a timer in the host system and keep calling" you >> mean that I need to break up that loop into a callback which is called with >> a repeating timer? (I think this is not a good solution). >> > > If you really prefer to implement your background task as a loop in a > gambit thread, you can communicate between the 'main' (event-system > controlled) and 'worker' gambit threads via gambit thread mailboxes. So > your timer handler just sends a message to the worker thread and waits for > a message in response. So the worker loop blocks waiting for a message at > the beginning of each iteration and sends a message back at the end. The > content of these messages can be bogus and ignored both ways. What this > achieves is setting apart some time to give your logic a chance to run. > > Also, many event-based systems have an 'on idle' event type such that if > you register to listen for it, your handler will get triggered whenever the > application is doing nothing. So if you don't really need your background > logic to happen in regularly timed ticks, using the idle handler instead > might make better use of processing time left over from event handling and > rendering. > > As a step further in this direction, you can have *all* your event > handlers works like this, just delegating the real work to the "worker" > gambit thread through mailboxes, and then you can make your code feel > pretty much as though you controlled the main event loop. In this case, > the messages sent to mailboxes would contain information about the events. > So the worker thread can switch over event type, just as in plain SDL. > Note you still need a timer or idle handler to have stuff happen outside of > user input and redraw events. > > In this case your "worker" thread looks and feels pretty much like a > "main" thread. The event handlers themselves only contain stubs. > > >> And then, where would you create and start that thread? >> > > I don't know the specifics of your platform. In some, starting the event > loop is done explicitly, so you can create the thread before you do that. > In others, there is an 'init' event type. Where would you, for example, > initialize OpenGL state that will not change throughout your application? > I bet somewhere around there you might be able to launch that thread too. > > As a last resort, you can just do it the first time that any event handler > gets called. > > Thank you for your replies. I'm working with SDL2, using SchemeSpheres' bindings. Everything is working smoothly, except for this requirement at the bottom of the README: http://hg.libsdl.org/SDL/file/704a0bfecf75/README-ios.txt It is easy to make it work, unless you want to run some continuous process in the background. Specifically, I'm running a remote REPL, which requires running (##repl-debug-main) after setting it up for the TCP ports. Once you call this function, you don't return from it until you exit the REPL, AFAIK. I see how you could use SDL timers to call at certain intervals some Scheme code "in the background", but this code will be run in a different thread, breaking Gambit. You can avoid running the function in a different thread as explained here http://wiki.libsdl.org/SDL_AddTimer?highlight=%28\bCategoryAPI\b%29|%28SDLFunctionTemplate%29 but that would block Gambit until (##repl-debug-main) exits, since is not running in a different Gambit thread. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://webmail.iro.umontreal.ca/pipermail/gambit-list/attachments/20140807/c0fb732c/attachment-0001.html From euccastro at gmail.com Thu Aug 7 19:19:23 2014 From: euccastro at gmail.com (Estevo) Date: Fri, 8 Aug 2014 01:19:23 +0200 Subject: [gambit-list] Gambit and event-based systems In-Reply-To: References: Message-ID: One thing I'd try would be to launch a gambit thread running ##repl-debug-main and set up a timer or idle handler in the main gambit thread that just 'thread-sleep!'s for a small amount of time. Hopefully experimentation yields a delay that is small enough to be unnoticeable in your application, but large enough to give the REPL enough time to do its work. If you use a timer for this (or, I imagine, if you handle timers in Gambit at all), the trick to run it in the same OS thread would be required. I don't know, from the top of my head, whether and how SDL does idle events. A fancier approach would be to look up the implementation of ##repl-debug-main and try and see if there are any hooks by which the trick I mentioned in the previous message could be enabled. If there are not, you could try running your own modified version of ##repl-debug-main (factoring out the hooks that would enable the just-wait-for-as-long-as-the-REPL-is-doing-actual-work trick would be a nice contribution to gambit IMHO). On Thu, Aug 7, 2014 at 7:06 PM, ?lvaro Castro-Castilla < alvaro.castro.castilla at gmail.com> wrote: > > On Thu, Aug 7, 2014 at 6:37 PM, Estevo wrote: > >> >> Okay, it wasn't that easy. I *do* need to have a Gambit thread running a >>> loop in the background as well. How can I keep that loop running? >>> >> >> What do you need to do in this thread exactly? >> > >> I imagine that loop will keep running as long as you are in the Scheme >> world, that is, handling any type of event. Unfortunately, in an >> event-based system your app will by default spend much of the time in the C >> world, waiting for things to happen. A way to work around that is >> suggested below. >> >> >>> When you said "install a timer in the host system and keep calling" you >>> mean that I need to break up that loop into a callback which is called with >>> a repeating timer? (I think this is not a good solution). >>> >> >> If you really prefer to implement your background task as a loop in a >> gambit thread, you can communicate between the 'main' (event-system >> controlled) and 'worker' gambit threads via gambit thread mailboxes. So >> your timer handler just sends a message to the worker thread and waits for >> a message in response. So the worker loop blocks waiting for a message at >> the beginning of each iteration and sends a message back at the end. The >> content of these messages can be bogus and ignored both ways. What this >> achieves is setting apart some time to give your logic a chance to run. >> >> Also, many event-based systems have an 'on idle' event type such that if >> you register to listen for it, your handler will get triggered whenever the >> application is doing nothing. So if you don't really need your background >> logic to happen in regularly timed ticks, using the idle handler instead >> might make better use of processing time left over from event handling and >> rendering. >> >> As a step further in this direction, you can have *all* your event >> handlers works like this, just delegating the real work to the "worker" >> gambit thread through mailboxes, and then you can make your code feel >> pretty much as though you controlled the main event loop. In this case, >> the messages sent to mailboxes would contain information about the events. >> So the worker thread can switch over event type, just as in plain SDL. >> Note you still need a timer or idle handler to have stuff happen outside of >> user input and redraw events. >> >> In this case your "worker" thread looks and feels pretty much like a >> "main" thread. The event handlers themselves only contain stubs. >> >> >>> And then, where would you create and start that thread? >>> >> >> I don't know the specifics of your platform. In some, starting the event >> loop is done explicitly, so you can create the thread before you do that. >> In others, there is an 'init' event type. Where would you, for example, >> initialize OpenGL state that will not change throughout your application? >> I bet somewhere around there you might be able to launch that thread too. >> >> As a last resort, you can just do it the first time that any event >> handler gets called. >> >> > > > Thank you for your replies. > > > I'm working with SDL2, using SchemeSpheres' bindings. Everything is > working smoothly, except for this requirement at the bottom of the README: > > http://hg.libsdl.org/SDL/file/704a0bfecf75/README-ios.txt > > It is easy to make it work, unless you want to run some continuous process > in the background. Specifically, I'm running a remote REPL, which requires > running (##repl-debug-main) after setting it up for the TCP ports. Once > you call this function, you don't return from it until you exit the REPL, > AFAIK. > > I see how you could use SDL timers to call at certain intervals some > Scheme code "in the background", but this code will be run in a different > thread, breaking Gambit. You can avoid running the function in a different > thread as explained here > http://wiki.libsdl.org/SDL_AddTimer?highlight=%28\bCategoryAPI\b%29|%28SDLFunctionTemplate%29 > > but that would block Gambit until (##repl-debug-main) exits, since is not > running in a different Gambit thread. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://webmail.iro.umontreal.ca/pipermail/gambit-list/attachments/20140808/17bbc67d/attachment.html From alvaro.castro.castilla at gmail.com Fri Aug 8 05:56:03 2014 From: alvaro.castro.castilla at gmail.com (=?UTF-8?Q?=C3=81lvaro_Castro=2DCastilla?=) Date: Fri, 8 Aug 2014 11:56:03 +0200 Subject: [gambit-list] Gambit and event-based systems In-Reply-To: References: Message-ID: On Fri, Aug 8, 2014 at 1:19 AM, Estevo wrote: > One thing I'd try would be to launch a gambit thread running > ##repl-debug-main and set up a timer or idle handler in the main gambit > thread that just 'thread-sleep!'s for a small amount of time. Hopefully > experimentation yields a delay that is small enough to be unnoticeable in > your application, but large enough to give the REPL enough time to do its > work. If you use a timer for this (or, I imagine, if you handle timers in > Gambit at all), the trick to run it in the same OS thread would be > required. I don't know, from the top of my head, whether and how SDL does > idle events. > > A fancier approach would be to look up the implementation of > ##repl-debug-main and try and see if there are any hooks by which the trick > I mentioned in the previous message could be enabled. If there are not, > you could try running your own modified version of ##repl-debug-main > (factoring out the hooks that would enable the > just-wait-for-as-long-as-the-REPL-is-doing-actual-work trick would be a > nice contribution to gambit IMHO). > > Thanks all for your insights and help :) I found a solution, which is very simple: just create the REPL thread, then create the SDL Cocoa draw loop callback, and finally let the main function return. Since the callback is going to be called repeatedly by iOS, the REPL thread will be resumed since it didn't terminate. The key insight is realizing that the current thread in Scheme returns to C, but the other threads will continue their execution as soon as you come back to Scheme. It works now, with both custom application loops and event-loop hooks models. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://webmail.iro.umontreal.ca/pipermail/gambit-list/attachments/20140808/89210b7c/attachment.html From alvaro.castro.castilla at gmail.com Fri Aug 8 07:02:46 2014 From: alvaro.castro.castilla at gmail.com (=?UTF-8?Q?=C3=81lvaro_Castro=2DCastilla?=) Date: Fri, 8 Aug 2014 13:02:46 +0200 Subject: [gambit-list] Gambit and event-based systems In-Reply-To: References: Message-ID: On Fri, Aug 8, 2014 at 11:56 AM, ?lvaro Castro-Castilla < alvaro.castro.castilla at gmail.com> wrote: > > On Fri, Aug 8, 2014 at 1:19 AM, Estevo wrote: > >> One thing I'd try would be to launch a gambit thread running >> ##repl-debug-main and set up a timer or idle handler in the main gambit >> thread that just 'thread-sleep!'s for a small amount of time. Hopefully >> experimentation yields a delay that is small enough to be unnoticeable in >> your application, but large enough to give the REPL enough time to do its >> work. If you use a timer for this (or, I imagine, if you handle timers in >> Gambit at all), the trick to run it in the same OS thread would be >> required. I don't know, from the top of my head, whether and how SDL does >> idle events. >> >> A fancier approach would be to look up the implementation of >> ##repl-debug-main and try and see if there are any hooks by which the trick >> I mentioned in the previous message could be enabled. If there are not, >> you could try running your own modified version of ##repl-debug-main >> (factoring out the hooks that would enable the >> just-wait-for-as-long-as-the-REPL-is-doing-actual-work trick would be a >> nice contribution to gambit IMHO). >> >> > Thanks all for your insights and help :) > > I found a solution, which is very simple: just create the REPL thread, > then create the SDL Cocoa draw loop callback, and finally let the main > function return. Since the callback is going to be called repeatedly by > iOS, the REPL thread will be resumed since it didn't terminate. The key > insight is realizing that the current thread in Scheme returns to C, but > the other threads will continue their execution as soon as you come back to > Scheme. > > It works now, with both custom application loops and event-loop hooks > models. > After all this, folks at SDL list just told me that this is actually a bug in the README, and you don't need the callback method any longer. You can take full control of the loop at the moment. The only reason this was necessary was for interaction with the Game Center, but apparently it isn't as of now. Well, at least I learnt something about Gambit threads - FFI interaction. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://webmail.iro.umontreal.ca/pipermail/gambit-list/attachments/20140808/54e93000/attachment-0001.html From euccastro at gmail.com Fri Aug 8 07:08:08 2014 From: euccastro at gmail.com (Estevo) Date: Fri, 8 Aug 2014 13:08:08 +0200 Subject: [gambit-list] Gambit and event-based systems In-Reply-To: References: Message-ID: Yay! A caveat: I've never touched iOS, but some event-based systems will not call back unless an event for which you have registered is triggered. In games, where you redraw the whole screen many times per second this is not a problem, since the 'draw' callbacks should give plenty of opportunity for Scheme land code to run. But in a more static GUI application this might not be the case. It could be that the REPL freezes until the user interacts with the app window in some way. Hence the suggestion for timer or idle handlers. On Fri, Aug 8, 2014 at 11:56 AM, ?lvaro Castro-Castilla < alvaro.castro.castilla at gmail.com> wrote: > > On Fri, Aug 8, 2014 at 1:19 AM, Estevo wrote: > >> One thing I'd try would be to launch a gambit thread running >> ##repl-debug-main and set up a timer or idle handler in the main gambit >> thread that just 'thread-sleep!'s for a small amount of time. Hopefully >> experimentation yields a delay that is small enough to be unnoticeable in >> your application, but large enough to give the REPL enough time to do its >> work. If you use a timer for this (or, I imagine, if you handle timers in >> Gambit at all), the trick to run it in the same OS thread would be >> required. I don't know, from the top of my head, whether and how SDL does >> idle events. >> >> A fancier approach would be to look up the implementation of >> ##repl-debug-main and try and see if there are any hooks by which the trick >> I mentioned in the previous message could be enabled. If there are not, >> you could try running your own modified version of ##repl-debug-main >> (factoring out the hooks that would enable the >> just-wait-for-as-long-as-the-REPL-is-doing-actual-work trick would be a >> nice contribution to gambit IMHO). >> >> > Thanks all for your insights and help :) > > I found a solution, which is very simple: just create the REPL thread, > then create the SDL Cocoa draw loop callback, and finally let the main > function return. Since the callback is going to be called repeatedly by > iOS, the REPL thread will be resumed since it didn't terminate. The key > insight is realizing that the current thread in Scheme returns to C, but > the other threads will continue their execution as soon as you come back to > Scheme. > > It works now, with both custom application loops and event-loop hooks > models. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://webmail.iro.umontreal.ca/pipermail/gambit-list/attachments/20140808/060832f3/attachment.html From alvaro.castro.castilla at gmail.com Fri Aug 8 07:21:35 2014 From: alvaro.castro.castilla at gmail.com (=?UTF-8?Q?=C3=81lvaro_Castro=2DCastilla?=) Date: Fri, 8 Aug 2014 13:21:35 +0200 Subject: [gambit-list] Gambit and event-based systems In-Reply-To: References: Message-ID: On Fri, Aug 8, 2014 at 1:08 PM, Estevo wrote: > Yay! > > A caveat: I've never touched iOS, but some event-based systems will not > call back unless an event for which you have registered is triggered. In > games, where you redraw the whole screen many times per second this is not > a problem, since the 'draw' callbacks should give plenty of opportunity for > Scheme land code to run. But in a more static GUI application this might > not be the case. It could be that the REPL freezes until the user > interacts with the app window in some way. Hence the suggestion for timer > or idle handlers. > > Yes, that's a good observation :) In SDL, specially for the drawing callback, it will always be the case that you are constantly re-entering the Scheme code. But you are right, for static GUIs you'll need a callback. Anyway, all this was for nothing, since SDL seems to work now as normally, giving you full control of the loop. This is how it should be, as it makes the code way more portable between all supported platforms. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://webmail.iro.umontreal.ca/pipermail/gambit-list/attachments/20140808/3fdab1e3/attachment.html