using 'wait with your own port handler?
[1/4] from: d95-mjo::nada::kth::se at: 24-Jun-2001 21:24
Hi! I read the following article earlier today:
> Writing your own Protocol Handler by Jeff Kreis. > http://www.rebolforces.com/articles/protocols.html
and I thought it was very interesting. I tried to use this approach on a little project I'm doing, but I'm no longer sure if I can get it to do what I want it to do. This is what I'm trying to do: Using View/Pro and a DLL, I've been able to play MP3 files by calling functions in the DLL from REBOL. What I'd like to do is to create a port interface for my MP3 routines that works like the sound:// port. It would look something like this: ;-- Open mp3 port (load DLL etc) mp3-port: open mp3:// ;-- Play mp3 file (by calling DLL function) insert mp3-port %nameofsong.mp3 ;-- Wait for mp3 to finish (somehow) wait mp3-port ;-- Close mp3 port (free DLL etc) close mp3-port This all seems to work, EXCEPT for 'wait. So, my question is this: Is it at all possible to write your own port handler that you can wait for using 'wait? If so, how would I do that? I've used the make root-protocol approach and I can't really figure it out. I tried using 'wait on my port, just to see what would happen, and it crashed REBOL. :-) The reason I want to use 'wait is that I would like to be able to wait for other ports at the same time. I have a feeling that 'wait is a bit too tied to low level port internals to work with my higher level port handler. Anyway, if anyone has any suggestions or ideas about how to make this work (or why it won't work), I'd be very grateful if you'd like to share this information on the mailing list. :-) (I forgot to mention that I haven't really thought about exactly HOW to do the actual wait-for-mp3 function, because first I'd need to understand how to use 'wait on my own port, in general. At the moment, it seems like I'd have to use some kind of poll loop.) TIA, Martin Johannesson [d95-mjo--nada--kth--se]
[2/4] from: holger:rebol at: 25-Jun-2001 15:31
On Sun, Jun 24, 2001 at 09:24:51PM +0200, Martin Johannesson wrote:
> This all seems to work, EXCEPT for 'wait. So, my question is this: Is it > at all possible to write your own port handler that you can wait for using > 'wait?
The short answer is no. There are two issues: - How do you get REBOL to "wake up" when your library is done playing ? This is the difficult part and always OS-dependent. For Windows there would, e.g., have to be a way for a script to allocate a WinMsg, register it with REBOL's internal wait handler, and tie it to a port. For other operating systems the procedure would be different. Not supported at this time. - How do you get 'wait to realize that your port is done ? This will be possible in the next major Core release. At the moment only two types of ports can have 'wait functionality: ports with port handlers written in C, and ports which are directly based on ports that have 'wait functionality. For instance you can 'wait for an http port because it uses a tcp port that supports 'wait. Port handlers have a function 'get-sub-port which is supposed to return the next-lower port. The default behavior (used by http) is to return port/sub-port, i.e. for http the tcp port is returned.
> If so, how would I do that? I've used the make root-protocol > approach and I can't really figure it out. I tried using 'wait on my > port, just to see what would happen, and it crashed REBOL. :-)
That should not happen... -- Holger Kruse [holger--rebol--com]
[3/4] from: petr:krenzelok:trz:cz at: 26-Jun-2001 7:01
Holger Kruse wrote:
> On Sun, Jun 24, 2001 at 09:24:51PM +0200, Martin Johannesson wrote: > > This all seems to work, EXCEPT for 'wait. So, my question is this: Is it
<<quoted lines omitted: 4>>> playing ? This is the difficult part and always OS-dependent. For Windows > there would, e.g., have to be a way for a script to allocate a WinMsg,
and? :-) just kidding, see below ...
> register it with REBOL's internal wait handler, and tie it to a port. > For other operating systems the procedure would be different.
So, I thought each platform has ability to somehow generate/send events/messages .... probably difficult to wrap into one consistent solution?All that multiplatform issues are strange things sometimes. Last time I was surprised once Gabriele said my file locking mechanism will not work on Unix, as even if app regularly locks it, another task can delete it ... However, sometimes the value of certain solution is little too high to miss it :-) Sometimes also, so called "multiplatform" usage is little bit blurred. The answer is simple - the script does work for you or not. What is the difference if my script will not work for me, because someone used odbc in it, while I don't own /command? Or sound? I can't use it while I buy /Pro. I noticed that even in current state of Rebol development, there are some slight differences (Be and Elate don't supporting some network blabla I don't remember now, ability to use some special Mac fs capability ...) So, if some much desired functionality (e.g. ability to produce own events) would be possible to be supported on 80 - 90% of platforms, it is worth consideration imo. btw: I noticed that few ppl already expressed desire to have even mechanism available in Core. What for? I don't know :-) But having face/rate enables us to have some kind of pseudo tasking, be more async, etc. Maybe we are looking for some kind of watch: make timer! 0.1 func-here or watch: open [ scheme: 'timer rate: 1 awake: func-here ] ? Or will we get regular threading? I remember you stated that it is not so easy (if even possible) to make the feature work on other platforms? But in general, having threading or not, View is very nice example of what can be achieved by very clever design. I can't wait to see, what you guys at RT are cooking to bring us even more asynchronicity :-) -pekr-
[4/4] from: holger:rebol at: 26-Jun-2001 6:33
On Tue, Jun 26, 2001 at 07:01:32AM +0200, Petr Krenzelok wrote:
> So, I thought each platform has ability to somehow generate/send events/messages
No. Unix does not, for instance.
> (Be and Elate don't supporting some network blabla I don't remember now, ability > to use some special Mac fs capability ...)
Yes, but there is a difference between having a generic mechanism (like sound or multicasting) which simply is not supported by all operating systems, and having a mechanism which is specifically tied to a single OS to start with.
> So, if some much desired functionality (e.g. ability to produce own events) > would be possible to be supported on 80 - 90% of platforms, it is worth > consideration imo.
Yes. It is a trade-off that will have to be looked at in each case.
> watch: make timer! 0.1 func-here
Yes. Real timers are a possibility.
> Or will we get regular threading?
Possibly, not soon though. -- Holger Kruse [holger--rebol--com]
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted