* Signals / Messages / Events / ...?
@ 2018-01-03 5:09 Christopher Howard
2018-01-03 11:53 ` Neil Jerram
2018-01-04 1:16 ` Matt Wette
0 siblings, 2 replies; 5+ messages in thread
From: Christopher Howard @ 2018-01-03 5:09 UTC (permalink / raw)
To: Guile User Mailing List
[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]
Hi list, forgive me if this is a somewhat vague question... but is
there some kind of framework/system/approach for Guile where you could
have different parts of your code register callback functions to react
to a certain signal or message raised by any other part of the code?
I'm thinking like dbus where I guess you can sort of send off a message
but not really care who receives it. In chickadee you can register
callbacks for the various input events, and i think that basic idea
could be extended so long as (1) you could have any kind of
event/signal you wanted; (2) call backs added could be specified as
either persistent or one-time call-backs.
It seems like it wouldn't be too hard to code something like that with
just lists of callback functions tied to names/data in a tree. But
maybe somebody has already thought of that or would suggest a better
approach.
Just running into this challenge in development where a function like
"new-game" has to do 8 different things to 6 different data structures,
but why not instead just have the code dealing with the 6 different
objects register callbacks to receive the 'new-game signal? I think
message passing is the wrong term because in message passing you
specify the message connections between the different objects, right?
Signal bus maybe?
--
http://upgradefromwindows.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Signals / Messages / Events / ...?
2018-01-03 5:09 Signals / Messages / Events / ...? Christopher Howard
@ 2018-01-03 11:53 ` Neil Jerram
2018-01-03 15:11 ` Christopher Howard
2018-01-04 1:16 ` Matt Wette
1 sibling, 1 reply; 5+ messages in thread
From: Neil Jerram @ 2018-01-03 11:53 UTC (permalink / raw)
To: guile-user
On 03/01/18 05:09, Christopher Howard wrote:
> Hi list, forgive me if this is a somewhat vague question... but is
> there some kind of framework/system/approach for Guile where you could
> have different parts of your code register callback functions to react
> to a certain signal or message raised by any other part of the code?
> I'm thinking like dbus where I guess you can sort of send off a message
> but not really care who receives it. In chickadee you can register
> callbacks for the various input events, and i think that basic idea
> could be extended so long as (1) you could have any kind of
> event/signal you wanted; (2) call backs added could be specified as
> either persistent or one-time call-backs.
>
> It seems like it wouldn't be too hard to code something like that with
> just lists of callback functions tied to names/data in a tree. But
> maybe somebody has already thought of that or would suggest a better
> approach.
>
> Just running into this challenge in development where a function like
> "new-game" has to do 8 different things to 6 different data structures,
> but why not instead just have the code dealing with the 6 different
> objects register callbacks to receive the 'new-game signal? I think
> message passing is the wrong term because in message passing you
> specify the message connections between the different objects, right?
> Signal bus maybe?
>
Well, one Lispy mechanism in that area is hooks. For example, from some
of my old code:
;; Changes to modem registration state are indicated by calling this
;; hook with args STATE and PROPERTIES. STATE can be 'none, meaning
;; that there is currently no modem; 'unregistered, meaning that there
;; is a modem but it isn't registered with the network; or
;; 'registered, meaning that the modem is registered with the network.
;; If STATE is 'registered, PROPERTIES is an alist of registration
;; properties; otherwise PROPERTIES is #f.
(define registration-hook (make-hook 2))
(define (add-registration-hook proc)
(add-hook! registration-hook proc))
(define (notify-registration state properties)
(run-hook registration-hook state properties))
Does that serve your purpose at all?
Best wishes - Neil
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Signals / Messages / Events / ...?
2018-01-03 11:53 ` Neil Jerram
@ 2018-01-03 15:11 ` Christopher Howard
2018-01-03 19:53 ` Neil Jerram
0 siblings, 1 reply; 5+ messages in thread
From: Christopher Howard @ 2018-01-03 15:11 UTC (permalink / raw)
To: Neil Jerram, guile-user
[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]
On Wed, 2018-01-03 at 11:53 +0000, Neil Jerram wrote:
>
> Well, one Lispy mechanism in that area is hooks. For example, from
> some
> of my old code:
>
> ;; Changes to modem registration state are indicated by calling this
> ;; hook with args STATE and PROPERTIES. STATE can be 'none, meaning
> ;; that there is currently no modem; 'unregistered, meaning that
> there
> ;; is a modem but it isn't registered with the network; or
> ;; 'registered, meaning that the modem is registered with the
> network.
> ;; If STATE is 'registered, PROPERTIES is an alist of registration
> ;; properties; otherwise PROPERTIES is #f.
> (define registration-hook (make-hook 2))
>
> (define (add-registration-hook proc)
> (add-hook! registration-hook proc))
>
> (define (notify-registration state properties)
> (run-hook registration-hook state properties))
>
> Does that serve your purpose at all?
>
> Best wishes - Neil
>
>
I think that should work. Only part I'm not sure about is if you can
have a "one-off" procedure added to a hook... but you could just have
the procedure call remove-hook! to remove itself...?
--
https://www.debian.org/
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Signals / Messages / Events / ...?
2018-01-03 15:11 ` Christopher Howard
@ 2018-01-03 19:53 ` Neil Jerram
0 siblings, 0 replies; 5+ messages in thread
From: Neil Jerram @ 2018-01-03 19:53 UTC (permalink / raw)
To: Christopher Howard, guile-user
On 03/01/18 15:11, Christopher Howard wrote:
> On Wed, 2018-01-03 at 11:53 +0000, Neil Jerram wrote:
>> Well, one Lispy mechanism in that area is hooks. For example, from
>> some
>> of my old code:
>>
>> ;; Changes to modem registration state are indicated by calling this
>> ;; hook with args STATE and PROPERTIES. STATE can be 'none, meaning
>> ;; that there is currently no modem; 'unregistered, meaning that
>> there
>> ;; is a modem but it isn't registered with the network; or
>> ;; 'registered, meaning that the modem is registered with the
>> network.
>> ;; If STATE is 'registered, PROPERTIES is an alist of registration
>> ;; properties; otherwise PROPERTIES is #f.
>> (define registration-hook (make-hook 2))
>>
>> (define (add-registration-hook proc)
>> (add-hook! registration-hook proc))
>>
>> (define (notify-registration state properties)
>> (run-hook registration-hook state properties))
>>
>> Does that serve your purpose at all?
>>
>> Best wishes - Neil
>>
>>
> I think that should work. Only part I'm not sure about is if you can
> have a "one-off" procedure added to a hook... but you could just have
> the procedure call remove-hook! to remove itself...?
>
Yes, I think so, and you could encapsulate that with something like this:
(define (add-hook-once-only! hook proc)
(letrec ((proc-once-only
(lambda args
(remove-hook! hook proc-once-only)
(apply proc args))))
(add-hook! hook proc-once-only)))
Best wishes - Neil
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Signals / Messages / Events / ...?
2018-01-03 5:09 Signals / Messages / Events / ...? Christopher Howard
2018-01-03 11:53 ` Neil Jerram
@ 2018-01-04 1:16 ` Matt Wette
1 sibling, 0 replies; 5+ messages in thread
From: Matt Wette @ 2018-01-04 1:16 UTC (permalink / raw)
To: Christopher Howard; +Cc: Guile User Mailing List
> On Jan 2, 2018, at 9:09 PM, Christopher Howard <christopher.howard@qlfiles.net> wrote:
>
> Hi list, forgive me if this is a somewhat vague question... but is
> there some kind of framework/system/approach for Guile where you could
> have different parts of your code register callback functions to react
> to a certain signal or message raised by any other part of the code?
> I'm thinking like dbus where I guess you can sort of send off a message
> but not really care who receives it. In chickadee you can register
> callbacks for the various input events, and i think that basic idea
> could be extended so long as (1) you could have any kind of
> event/signal you wanted; (2) call backs added could be specified as
> either persistent or one-time call-backs.
>
> It seems like it wouldn't be too hard to code something like that with
> just lists of callback functions tied to names/data in a tree. But
> maybe somebody has already thought of that or would suggest a better
> approach.
>
> Just running into this challenge in development where a function like
> "new-game" has to do 8 different things to 6 different data structures,
> but why not instead just have the code dealing with the 6 different
> objects register callbacks to receive the 'new-game signal? I think
> message passing is the wrong term because in message passing you
> specify the message connections between the different objects, right?
> Signal bus maybe?
>
> --
> http://upgradefromwindows.com
If you are on Linux you can look at fibers:
https://github.com/wingo/fibers <https://github.com/wingo/fibers>
it is lightweight processes with message passing.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-01-04 1:16 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-01-03 5:09 Signals / Messages / Events / ...? Christopher Howard
2018-01-03 11:53 ` Neil Jerram
2018-01-03 15:11 ` Christopher Howard
2018-01-03 19:53 ` Neil Jerram
2018-01-04 1:16 ` Matt Wette
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).