Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > avcall, callback, trampoline, vacall, etc

Reply
Thread Tools

avcall, callback, trampoline, vacall, etc

 
 
Jorgen Grahn
Guest
Posts: n/a
 
      10-27-2012
[Trimmed the newsgroups a bit ... probably not enough]

On Fri, 2012-10-26, Joe Pfeiffer wrote:
> http://www.velocityreviews.com/forums/(E-Mail Removed) writes:
>
>> Dear Programming Gurus,
>>
>> These concepts are rather well talked about .. over the internet and
>> usenet, however, I cant find any clear explanation.
>>
>> avcall, callback, trampoline, vacall, etc

>
> Speaking only for myself, I found the idea of a 'callback' one that was
> really easy to describe, but really hard to understand for a long time.
> I see some other posters have already pointed you at google on this one,
> but I'll give it a shot anyway.


[snip]

> For callback-based programming, forget all that. Flush it.


I think you're exaggerating a bit here. But sure, callbacks are a bit
funny, and worth thinking about before trying to use them.

> There are areas where a completely different paradigm is used. A good example
> of one of these areas is writing a GUI interface. The big thing about a
> GUI interface is that you don't have control of the order in which input
> arrives, and you need to do something about whatever the crazy user
> does. In this world, somebody else writes something called an "event
> loop".


It seems to be very popular to design GUI frameworks that way, but
there is nothing that /forces/ them to do it. The fact that a GUI
application is (at leasr partly) driven by user input doesn't mean you
have to resort to callbacks.

Of course if a certain GUI framework forces you to use callbacks, you
have to do it.

[snip]

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
 
 
 
Joe Pfeiffer
Guest
Posts: n/a
 
      10-28-2012
Jorgen Grahn <(E-Mail Removed)> writes:

> [Trimmed the newsgroups a bit ... probably not enough]
>
> On Fri, 2012-10-26, Joe Pfeiffer wrote:
>> (E-Mail Removed) writes:
>>
>>> Dear Programming Gurus,
>>>
>>> These concepts are rather well talked about .. over the internet and
>>> usenet, however, I cant find any clear explanation.
>>>
>>> avcall, callback, trampoline, vacall, etc

>>
>> Speaking only for myself, I found the idea of a 'callback' one that was
>> really easy to describe, but really hard to understand for a long time.
>> I see some other posters have already pointed you at google on this one,
>> but I'll give it a shot anyway.

>
> [snip]
>
>> For callback-based programming, forget all that. Flush it.

>
> I think you're exaggerating a bit here. But sure, callbacks are a bit
> funny, and worth thinking about before trying to use them.


I don't think I'm exaggerating at all. This is one of those areas where
your previous intuitions about how a program fits together will do more
harm than good, and a necessary first step is to forget your previous
intuitions.

>> There are areas where a completely different paradigm is used. A good example
>> of one of these areas is writing a GUI interface. The big thing about a
>> GUI interface is that you don't have control of the order in which input
>> arrives, and you need to do something about whatever the crazy user
>> does. In this world, somebody else writes something called an "event
>> loop".

>
> It seems to be very popular to design GUI frameworks that way, but
> there is nothing that /forces/ them to do it. The fact that a GUI
> application is (at leasr partly) driven by user input doesn't mean you
> have to resort to callbacks.
>
> Of course if a certain GUI framework forces you to use callbacks, you
> have to do it.


And since the context of my post was somebody asking for help
understanding callbacks, that is the class of GUI program I described.
 
Reply With Quote
 
 
 
 
troplin@gmail.com
Guest
Posts: n/a
 
      10-28-2012
Joe Pfeiffer <(E-Mail Removed)> wrote:
> Jorgen Grahn <(E-Mail Removed)> writes:
>
>> [Trimmed the newsgroups a bit ... probably not enough]
>>
>> On Fri, 2012-10-26, Joe Pfeiffer wrote:
>>> (E-Mail Removed) writes:
>>>
>>>> Dear Programming Gurus,
>>>>
>>>> These concepts are rather well talked about .. over the internet and
>>>> usenet, however, I cant find any clear explanation.
>>>>
>>>> avcall, callback, trampoline, vacall, etc
>>>
>>> Speaking only for myself, I found the idea of a 'callback' one that was
>>> really easy to describe, but really hard to understand for a long time.
>>> I see some other posters have already pointed you at google on this one,
>>> but I'll give it a shot anyway.

>>
>> [snip]
>>
>>> For callback-based programming, forget all that. Flush it.

>>
>> I think you're exaggerating a bit here. But sure, callbacks are a bit
>> funny, and worth thinking about before trying to use them.

>
> I don't think I'm exaggerating at all. This is one of those areas where
> your previous intuitions about how a program fits together will do more
> harm than good, and a necessary first step is to forget your previous
> intuitions.


I don't think it helps if you think of callback as something magic and entirely different.

Probably it's worth taking a look on the 'other side' of callbacks, namely the point where they are called.

An example:

Suppose you have created your own little file format. You use it in your console application.

Of course you have written a parser for it:

Document* ParseFile(const char* filename)
{
// do some parsing
if (someErrorHappened)
{
// only minor error, continue parsing
printf("Error %x: %s", errorCode, errorMessage);
}
// do some more parsing
if (someErrorHappened)
{
// only minor error, continue parsing
printf("Error %x: %s", errorCode, errorMessage);
}
// finish parsing
return document;
}

Now you write a different application, where printing the error message on the console is not appropriate, instead you want to store all errors in a database.

Of course you don't want to write a new parser for that, but modify the existing one such that it works for both programs.

To achieve that goal you define an error callback, so every application can do its own error handling:

typedef void (errorCallback)(int, const char*);

Document* ParseFile(const char* filename, errorCallback* errorHandler)
{
// do some parsing
if (someErrorHappened)
{
// instead of calling printf directly, use the generic error handler
errorHandler(errorCode, errorMessage);
}
// do some more parsing
if (someErrorHappened)
{
// only minor error, continue parsing
errorHandler(errorCode, errorMessage);
}
// finish parsing
return document;
}

In your first console application you define the error handler like this:

void consoleErrorHandler(int errorCode, const char* message)
{
printf("Error %x: %s", errorCode, errorMessage);
}

and you call the parsing function:

Document* document = ParseFile("testfile.txt", &consoleErrorHandler);

In your second application you define a different error callback:

void writeErrorToDatabase(int errorCode, const char* message)
{
// write error to database
}

Document* document = ParseFile("testfile.txt", &writeErrorToDatabase);

You see, no magic, everything is under your control.

Tobi
 
Reply With Quote
 
Pascal J. Bourguignon
Guest
Posts: n/a
 
      10-28-2012
Joe Pfeiffer <(E-Mail Removed)> writes:

> For callback-based programming, forget all that. Flush it.
>
> There are areas where a completely different paradigm is used. A good example
> of one of these areas is writing a GUI interface. The big thing about a
> GUI interface is that you don't have control of the order in which input
> arrives, and you need to do something about whatever the crazy user
> does. In this world, somebody else writes something called an "event
> loop". The event loop just sits out there waiting for input (maybe a
> button click, maybe information that you need to redraw your window,
> maybe a timeout, maybe something else), and when the input happens the
> event loop code calls a function you wrote to handle that particular
> input. Your function is called a 'callback'.


Yes, but in general, there is still this direct and simple flow of
control: a function calls another function, and so on.

A callback is just a function that is given to some module, to be called
when the module needs to call it. This is a way to parameterize or
customize that module.

(defun my-callback (data)
(format t "Received ~A~%" data))

(defun receive-loop (data-callback)
(loop
:for line = (progn (format *query-io* "> ")
(finish-output *query-io*)
(read-line *query-io* nil nil))
:while (and line (plusp (length line)))
:do (funcall data-callback line)))

cl-user> (receive-loop 'my-callback)
> Hello

Received Hello
> World

Received World
>

nil
cl-user>

And then you can use the receive-loop module with a different callback,
making it do something else:


cl-user> (let ((c 0))
(receive-loop (lambda (data) (incf c (parse-integer data))))
c)
> 42
> 33
> 101
>

176
cl-user>


Now, there's another situation where you really don't know WHEN the
callback is called, it's when the module calling it uses threads, and
calls your callback function at "random" times, possibly in another
thread, or perhaps while handling a unix signal. In this situation,
there are a lot of technicalities to fulfill for calbacks.


But the in usual case, there's no complexity involved.

--
__Pascal Bourguignon__
http://www.informatimago.com
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      10-29-2012
On Sun, 2012-10-28, Joe Pfeiffer wrote:
> Jorgen Grahn <(E-Mail Removed)> writes:
>
>> [Trimmed the newsgroups a bit ... probably not enough]
>>
>> On Fri, 2012-10-26, Joe Pfeiffer wrote:
>>> (E-Mail Removed) writes:
>>>
>>>> Dear Programming Gurus,
>>>>
>>>> These concepts are rather well talked about .. over the internet and
>>>> usenet, however, I cant find any clear explanation.
>>>>
>>>> avcall, callback, trampoline, vacall, etc
>>>
>>> Speaking only for myself, I found the idea of a 'callback' one that was
>>> really easy to describe, but really hard to understand for a long time.
>>> I see some other posters have already pointed you at google on this one,
>>> but I'll give it a shot anyway.

>>
>> [snip]
>>
>>> For callback-based programming, forget all that. Flush it.

>>
>> I think you're exaggerating a bit here. But sure, callbacks are a bit
>> funny, and worth thinking about before trying to use them.

>
> I don't think I'm exaggerating at all. This is one of those areas where
> your previous intuitions about how a program fits together will do more
> harm than good, and a necessary first step is to forget your previous
> intuitions.


Then we disagree slightly. And that's fine -- the OP has seen two
opinions, and can make up his own mind.

Perhaps I'm overly sensitive to "forget everything you think you
know!" messages.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Rivka Miller
Guest
Posts: n/a
 
      11-06-2012
On Oct 25, 6:18*pm, Joe Pfeiffer <(E-Mail Removed)> wrote:
> (E-Mail Removed) writes:
> > Dear Programming Gurus,

>
> > These concepts are rather well talked about .. over the internet and
> > usenet, however, I cant find any clear explanation.

>
> > avcall, callback, trampoline, vacall, etc


I am a newbie, but let me hazard a reply from what little I know.

> Speaking only for myself, I found the idea of a 'callback' one that was
> really easy to describe, but really hard to understand for a long time.
> I see some other posters have already pointed you at google on this one,
> but I'll give it a shot anyway.


I think the OP wrote in a rather nice way, going back to the original
book on C programming. Even the book by Kernighan and Pike on the Unix
does not touch any of these concepts.

> The big thing about callbacks is that everything you know about writing
> a program is turned completely on its head. *It sounds like you may have
> learned C when I did (or at any rate before these newfangles concepts
> came about). *If so, you're used to the idea that your main() is
> basically in control, and calls functions you write, more or less one at
> a time in an order you specify. *So first you call a function (or some
> functions) that read your input; then you call a function that gets some
> work done; then you call a function that writes your output. *It's
> likely your code isn't that clean in real life; you probably actually
> read a little bit of input, do a little bit of work, write a little bit
> of output, lather rinse repeat. *Doesn't matter, you're still in control
> of when your functions get called.
>
> For callback-based programming, forget all that. *Flush it.
>
> There are areas where a completely different paradigm is used. *A good example
> of one of these areas is writing a GUI interface. *The big thing about a
> GUI interface is that you don't have control of the order in which input
> arrives, and you need to do something about whatever the crazy user
> does. *In this world, somebody else writes something called an "event
> loop". *The event loop just sits out there waiting for input (maybe a
> button click, maybe information that you need to redraw your window,
> maybe a timeout, maybe something else), and when the input happens the
> event loop code calls a function you wrote to handle that particular
> input. *Your function is called a 'callback'.
>
> So that's the idea. *You write a function to handle the user clicking
> the 'OK' button. *You write a function to handle a window resize event.
> You write a function to... *whatever. *You pass a pointer to your
> function to the event loop code (this is called 'registering' your
> callback), and just sit back and wait for your code to be called.


As Joe Pfeiffer said that this has to do with a very different
paradigm.
I like Joe's reply as he tries to develop a good reply from basics.
Those
who replied did not seem to add much to it - atleast from my point of
view. And a newbie like the OP would probably be confused on this
subject.
I have a little pedestrian knowledge of the event drive programming.

Perhaps, they would have taken Joe's discussion and developed it
further.

For event-driven programming, you have to start with the concept of a
finite state machine FSM. There are a few variations, Mealy and Moore
machines.
You can also factorize out the states according to alternative,
concurrency and inheritance.

Most often, one sees callbacks when there are javascript code snippets
sent
by the server machine to the client machine browser for calling back
if it needs something.

But the callbacks can also be limited to a single machine with
multiple threads or processes running and able to call each other via
callbacks - I dont know how, but somehow.

Perhaps, someone would take a simple pictorial diagram of an
interesting FSM and translate it into a complete code involving
callbacks - and comparing with the other paradigm if that can also be
done. Or atleast, show how a single transition can be converted to it.
An example of GUI might be worth considering.

R

> Another application of callbacks is in FUSE (Filesystem in User SpacE)
> filesystems. *I will somewhat immodestly suggest that a tutorial on FUSE
> that you can find athttp://www.cs.nmsu.edu/~pfeiffer/fuse-tutorial/may
> help you.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: PIL (etc etc etc) on OS X Kevin Walzer Python 4 08-13-2008 08:27 AM
there are too many warnings (you are about to....etc etc forever) after installing Firefox trevor_smithson@yahoo.com Firefox 2 10-13-2005 07:35 PM
user authentication via /etc/passwd|/etc/shadow Marco Herrn Python 7 04-09-2004 12:12 PM
Python Audio (Alpy, Fastaudio, Etc Etc) Daniel Joyce Python 1 09-16-2003 08:39 PM
Is there a standard module library function to access /etc/passwd or /etc/group Robin Cull Python 5 07-31-2003 09:35 PM



Advertisments