Yu Feng wrote:
On Sun, 2008-10-19 at 18:30 +0100, Sam Liddicott wrote:
[My email server ate half my reply! Here's all of it]
That's pretty much where I'd got up to.
I was also trying to use libffi for it's trampoline for data-less callbacks.
For glib callbacks if the data pointer is not weak (I guess it always is
weak) then the lamba vars can ref counted, otherwise then the lamda
struct could maybe be free'd when "this" is freed at least, meaning the
object will track it's lamba var instances.
Maybe the lambda vars should be fields of an implicit subclass of a
lambda object to help manage this. Maybe different lambda base classes
could be specified depending on the situation.
I don't quite get your point. At least I don't agree 'this' should track
the lambda vars. They are unrelated. the lambda vars(if I correctly
understood you, by lambda vars you are referring to the local variables
of the function that creates the lambda function) has something to do
with the 'runtime context', ie 'scope' of the lambda function(and as
well as any function), and should be part of the 'closure', as the MDC
article implies.
For sure, but the problem is if nothing is tracking lambda vars. If the
lambda is of a method, then we can at least assume it won't be called
any more when the object is free'd, so it makes sense for the object to
track them if nothing else is.
Most callback providers assume an opaque private pointer with no ref
counting, so this is the best way to work with such libraries that I
can think of.
Functions in vala are not objects. They are not ref_counted and they
have no internal data members; just like what their correspondents in C.
Sure.
But if we plan to do something like function-in-function and scoping,
eg, connecting signals with function-in-function, we have to create a
closure, whose 'scope' member is set to the 'local' of the running
parent function.
yep
Later on when the closure is no longer in use, it is unrefed, disposed,
and the 'scope' member is destroyed.
the question was how to know that
It is quite possible to do it within the GLib framework if a GClosure
can be used in place of the callback, eg, signal handlers and g_source.
A GClosure can be created for the lambda, with the 'scope' variable as
the user_data, and a function to unref the 'scope' is provided as a
callback. Then we connect to the signal with the closure.
when the signal is disconnected, (most likely because of the disposal of
the object), the user_data of the closure is destroyed.
yeah, glib signals aren't so common, especially in non-gnome codebases.
BTW, there is an erudite description on closures (about _javascript_) at
MDC:
http://developer.mozilla.org/en/A_re-introduction_to_JavaScript#Closures
I'm slightly puzzled that I gave the impression that I was confused on
the subject, but I appreciate the pointer.
By background is the samba codebase which doesn't use glib, but for
which I want async support, and not just function-in-function, hence my
hope that execution of the callback block will fall-through into the
main function.
Sam
Currently in the samba C code the caller explicitly frees the lambda
struct (of course) at the end of the callback.
Maybe in the vala code we can avoid using the word "return" except for
the final return. This would cover continuation style code, but might
not favour signal handler style events, but perhaps they are actually a
different case anyway...
Sam
-----Original Message-----
From: Yu Feng <rainwoodman gmail com>
Sent: 19 October 2008 15:40
To: Sam Liddicott <sam liddicott com>
Cc: Ali Sabil <ali sabil gmail com>; Christian Hergert
<christian hergert gmail com>; Vala Mailing list <vala-list gnome org>
Subject: Re: [Vala] Proposal for an improved delegate/lambda handling
On Sun, 2008-10-19 at 14:19 +0100, Sam Liddicott wrote:
I like any method that allows the callback block to acess all
variables from the original scope and also allows execution of the
callback to fall-through into the original scope at the end of the
callback block; implying that the whole function must be generated
with labda-style local vars.
It is not easy to do in a (GLib and VALA)-consistent way. There is only
one user_data field in GLib callbacks and it is already used for 'this'.
Although it is possible to reuse this parameter for a 'local' variable,
in which we store every local variable, problems exist.
The lambda-style local vars has to be on the heap rather than the stack
so that it doesn't get immediately destroyed when the parent code block
is no long in execution. But putting local variables in the heap
contradicts with the way C works; therefore the resulted c code has to
be really messy. It is not a big deal anyways since VALA already
generates messy C code in many situations.
More importantly, there seems to be little possibility to free these
lambdas because we don't know when they are no longer in use. Neither
can we disconnect signals because we lost the track of the 'user_data'
parameter if we are out of the function that connects the signal.
The following code shows a possible implementation.
struct has_lambdas_local_type{
int ref_count;
GObject * this;
int local_1;
int local_2;
int par1;
};
void local_unref(gpointer local);
void local_ref(gpoitner local);
void lambda1 (...., struct has_lambdas_local_type * local) {
}
void has_lambdas (GObject * this, int par1) {
struct local_type * local = g_new0(struct local_type, 1); /*inevitably
leaked*/
local_ref(local);
local.this = this;
local.par1 = par1;
..
.
do stuff with local.local_1, local.local_2 and such.
..
local_ref(local);
g_signal_connect(..... , lambda1, local);
local_ref(local);
g_signal_connect(..... , lambda2, local);
...
playing with local.local_1, local.local_2, again.
...
local_unref(local);
return;
}
Yu
Sam
______________________________________________________________________
From: Ali Sabil <ali sabil gmail com>
Sent: 19 October 2008 11:31
To: Christian Hergert <christian hergert gmail com>
Cc: Vala Mailing list <vala-list gnome org>
Subject: Re: [Vala] Proposal for an improved delegate/lambda handling
Here is another set of proposed syntaxes, so that the post_request()
looks like this:
client.post_request("GET ...") {
debug ("Got Response: %s", response);
} {
debug ("Got error: %s", error);
}
Another possible syntax would be:
client.post_request("GET ...") {
(response) => {
debug ("Got response %s", response);
}
}
which in the case of a callback+errback would look like:
client.post_request("GET ...") {
(response) => {
debug ("Got Response %s", response)
}
(error) => {
debug ("Got error %s", error);
}
}
This 2nd syntax is actually inspired from Scala. Scala supports
currying, as well as optional parentheses for parameter passing,and
the ability to substitute parentheses for curly brackets in some
place. This set of feature combined together allow building methods
and functions that look and feel like control structure. (At least
that's what I understood during a short trip to the Scala world).
Thanks for all your feedback.
--
Ali
On Sun, Oct 19, 2008 at 2:00 AM, Christian Hergert
<christian hergert gmail com> wrote:
I like it. Might get confusing if someone wanted to mix direct
delegates and anonymous ones though.
-- Christian
On Sat, Oct 18, 2008 at 4:14 PM, Yu Feng
<rainwoodman gmail com> wrote:
> On Sat, 2008-10-18 at 22:57 +0200, Ali Sabil wrote:
>> Hi all,
>>
>> I would like to start a discussion about a small syntactic
sugar
>> addition to Vala, that would in my opinion slightly improve
the
>> situation with asynchronous code. The following code sample
should be
>> self explanatory about my proposal:
>>
>> delegate bool HttpResponseCallback (string response);
>>
>> public class HttpClient : Object {
>> public void post_request (string request,
HttpResponseCallback cb)
>> {
>> cb ("Hello world");
>> }
>> }
>>
>> // Current State
>> var client = new HttpClient ();
>> client.post_request("GET ....", (response) => {
>> debug ("got response %s", response);
>> return true;
>> }
>> );
>>
[The entire original message is not included]
_
[The entire original message is not included]
|
