make port! [scheme: 'event]
[1/12] from: sqlab:gmx at: 22-Jun-2001 9:11
How should this scheme be used?
Is it just for internal usage?
What usage is recommend?
Thanks
AR
[2/12] from: holger:rebol at: 22-Jun-2001 10:06
On Fri, Jun 22, 2001 at 09:45:02AM -0700, Jeff Kreis wrote:
> One might install their own AWAKE function to affect a hook,
> to do event filtering or what not. You can make little
> music apps that spit out tones based on mouse movement
> scribbling. Are you suggesting people shouldn't play
> directly with view events?
Yes, because in the future event ports probably will be used for
more than just View events.
--
Holger Kruse
[holger--rebol--com]
[3/12] from: cyphre:volny:cz at: 22-Jun-2001 17:16
Hi Jeff,
It is possible to make event-port asynchronous? I tried:
>> set-modes system/view/event-port [nowait: true]
** Script Error: Cannot use set-modes on this type port
** Where: halt-view
** Near: set-modes system/view/event-port [nowait: true]
no success :((
I'm able only make little interupt while event port is running like:
view/new layout [button "test"]
dispatch [.01 [print "hello from console interupt ;)"]]
but this is not true multithreading :)
Will be cool if I can open View window and will be able to use console for
another tasks while View-port is running.
Will be to much invasive to make rebol proces multithraded? What is your
opinion on that(Jeff, Holger, Carl, anyone?)
Regards
Cyphre
[4/12] from: holger:rebol at: 22-Jun-2001 8:51
On Fri, Jun 22, 2001 at 09:11:51AM +0200, [sqlab--gmx--net] wrote:
> How should this scheme be used?
>
> Is it just for internal usage?
> What usage is recommend?
In old beta-versions of View the main event loop had to retrieve events from the
port and call a handler function. In current versions View does this automatically,
in the background, so applications no longer have to interact with event ports.
--
Holger Kruse
[holger--rebol--com]
[5/12] from: jeff:rebol at: 22-Jun-2001 9:01
Howdy, Cyphre:
> Will be cool if I can open View window and will be able to
> use console for another tasks while View-port is running.
> Will be to much invasive to make rebol proces multithraded?
> What is your opinion on that(Jeff, Holger, Carl, anyone?)
>
> Regards
>
> Cyphre
REBOL [
Title: "Quasi-asynchronous view"
]
;-- Simple console emulation
; many console features (history,
; tab completion, etc.) not implemented
buf: copy ""
con: open/binary/direct [
scheme: 'console
awake: func [port /local c r][
prin c: to-char first port
either find "^M^J" c [
if not unset? set/any 'r do buf [
print [newline "==" copy/part mold get/any 'r 20 " ... "]
]
prin ">> "
clear buf
][
;-- basic editing
either c = #"^h" [
remove back tail buf
][append buf c]
]
]
]
view/new layout [
size 300x300
vh3 "Use the console"
button "Click on me"
button "We're all alive"
]
prin ">> "
append system/ports/wait-list con
forever [wait .02]
[6/12] from: holger:rebol at: 22-Jun-2001 9:03
On Fri, Jun 22, 2001 at 05:16:07PM +0200, Richard Smolak wrote:
> It is possible to make event-port asynchronous? I tried:
It already is.
> but this is not true multithreading :)
REBOL does not have true multirhreading :)
> Will be cool if I can open View window and will be able to use console for
> another tasks while View-port is running.
Yes, that will be possible in our next major upgrade, as a side effect
of async ports. In the current View version REBOL already processes all View
events during 'wait, but the console internally does not call wait, so
while waiting at a console prompt View events are not processed. This will
change in the future.
> Will be to much invasive to make rebol proces multithraded? What is your
> opinion on that(Jeff, Holger, Carl, anyone?)
Not easy, in particular cross-platform. On our list though...
--
Holger Kruse
[holger--rebol--com]
[7/12] from: holger:rebol at: 22-Jun-2001 9:00
On Fri, Jun 22, 2001 at 07:31:10AM -0700, Jeff Kreis wrote:
> Howdy, Anton:
>
> You can be the event loop.
This is NOT recommended and may break in future versions. View events
are intended to be handled transparently. Any time you call 'wait
(even with an empty port block) View will handle events for you.
--
Holger Kruse
[holger--rebol--com]
[8/12] from: cyphre:volny:cz at: 22-Jun-2001 18:14
Heya Jeff,
Cool, didn't know about system/ports/wait-list so now it is clear for me:))
Thanks
Cyphre
[9/12] from: cyphre:volny:cz at: 22-Jun-2001 18:22
Hello Holger,
thanks for fast reply
> > Will be cool if I can open View window and will be able to use console
for
> > another tasks while View-port is running.
>
> Yes, that will be possible in our next major upgrade, as a side effect
> of async ports. In the current View version REBOL already processes all
View
> events during 'wait, but the console internally does not call wait, so
> while waiting at a console prompt View events are not processed. This will
> change in the future.
>
I can't wait to see the next /View version :)
When approximately will be released?
> > Will be to much invasive to make rebol proces multithraded? What is your
> > opinion on that(Jeff, Holger, Carl, anyone?)
>
> Not easy, in particular cross-platform. On our list though...
>
It's great to hear nice things about future :)
Regards and keep the /View outrun Flash! ;-)
Cyphre
[10/12] from: jeff:rebol at: 22-Jun-2001 9:45
> > Howdy, Anton:
> >
> > You can be the event loop.
>
> This is NOT recommended and may break in future
> versions.
Sure, I just DID recommend it. :-) Golly, the nerve of you
contradicting my recommendation!! Just kidding around-- I
have been duly overruled.
> View events are intended to be handled
> transparently. Any time you call 'wait (even with an empty
> port block) View will handle events for you.
One might install their own AWAKE function to affect a hook,
to do event filtering or what not. You can make little
music apps that spit out tones based on mouse movement
scribbling. Are you suggesting people shouldn't play
directly with view events?
Controversy ... (-:
-jeff
[11/12] from: jeff:rebol at: 22-Jun-2001 7:31
Howdy, Anton:
You can be the event loop.
For example:
ep: open [
scheme: 'event
awake: func [port /local p x][
p: first port
x: copy []
print ["Event:" repeat i 8 [append x pick p i]]
;-- Actually have that event happen
; if you didn't DO the event the
; GUI would be non operational.
do p
;-- return true from AWAKE function
; to stop event bubbling.
true
]
]
view/new layout [size 300x300 text "Hello" button "!"]
forever [wait [ep]]
You should see all your events spewing out as you move your
mouse around the window and click on stuff. The AWAKE
function is called when data is available on the port. Instead
of just our simple forever above, we might have:
forever [
wait [ep]
do-background-task1
do-background-task2
]
You can also stick your event port in system/ports/wait-list,
then it will be handled with anything else in the list when
ever WAIT gets called.
If you don't open an event port and you just use VIEW/new for
all your windows, you still have the same ability to be the
event loop: just call WAIT with a timeout somewhere in your
loop. If you trudge through the PREZ dialect engine, that's
how it works-- a loop that manages the show and calls WAIT .2
at one point. This short wait is sufficient for all the GUI
events to be handled and prevents busy looping.
The reason you'd make your own event port is because you want
control over aspects of the port, such as the AWAKE function.
-jeff
[12/12] from: sqlab:gmx at: 23-Jun-2001 11:56
Thanks for all the answers.
Will there be something like distinct timer events in future and will I be
able to open event ports in core too, even without any view functionality?
AR
> On Fri, Jun 22, 2001 at 09:11:51AM +0200, [sqlab--gmx--net] wrote:
> > How should this scheme be used?
<<quoted lines omitted: 10>>
> Holger Kruse
> [holger--rebol--com]
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
--
GMX Tipp:
Der zweitgroesste Lotto-Jackpot aller Zeiten: 36 Mio. DM suchen einen
Gewinner!
Jetzt online tippen und nebenbei noch eine Reise nach Las Vegas gewinnen!
http://www.get1.de/gmx-gewinnspiel2
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted