Re: [Vala] Documenting 'async' / WAS: Further speculations on couroutines, generators and threads : Emulating Go's goroutines and channels in Vala
Just a small suggestion for the async examples. It would be worth while for absolute beginners to add a line on how to compile the examples (with the --pkg gio-2.0 --pkg threads options etc,,, ) so that the examples can be compiled right away. Serge. On Sat, Jul 16, 2011 at 8:28 AM, Luca Bruno wrote: > On Fri, Jul 15, 2011 at 04:43:20PM -0500, Jim Peters wrote: > > Thanks. > > > > I've created a new page on the wiki trying to make the 'async' stuff > > easier to understand: > > > > http://live.gnome.org/Vala/AsyncMethods > > > > I've added the old GIO example (updated to shutdown nicely), a > > Generator example, and an example that starts a background thread. > > Forgot to say that those long examples should go in different pages and > referenced under the examples. > > -- > http://www.debian.org - The Universal Operating System > ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Documenting 'async' / WAS: Further speculations on couroutines, generators and threads : Emulating Go's goroutines and channels in Vala
On Fri, Jul 15, 2011 at 04:43:20PM -0500, Jim Peters wrote: > Thanks. > > I've created a new page on the wiki trying to make the 'async' stuff > easier to understand: > > http://live.gnome.org/Vala/AsyncMethods > > I've added the old GIO example (updated to shutdown nicely), a > Generator example, and an example that starts a background thread. Forgot to say that those long examples should go in different pages and referenced under the examples. -- http://www.debian.org - The Universal Operating System ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Documenting 'async' / WAS: Further speculations on couroutines, generators and threads : Emulating Go's goroutines and channels in Vala
On Fri, Jul 15, 2011 at 04:43:20PM -0500, Jim Peters wrote: > Thanks. > > I've created a new page on the wiki trying to make the 'async' stuff > easier to understand: > > http://live.gnome.org/Vala/AsyncMethods > > I've added the old GIO example (updated to shutdown nicely), a > Generator example, and an example that starts a background thread. > > I'm not sure what the procedure is for documentation, or who owns > what. This page could be merged with the Tutorial if someone thinks > that is a good idea. > > If there is anything incorrect, I'm happy to fix it -- Thanks for the help. Anyway, it's better to either add that to the tutorial, or if it's a detailed/reference doc add it to the manual. Creating new pages will make the documentation more sparse. -- http://www.debian.org - The Universal Operating System ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Documenting 'async' / WAS: Further speculations on couroutines, generators and threads : Emulating Go's goroutines and channels in Vala
Congratulations to Jim Peters on his excellent job about documenting async methods in Vala ! Thank you very much ! Question about combining async and threads in the "generator example": - Would it be possible to combine the last two examples for the following purpose: - In the last example, the generator calls the feed() method, gets the next result (one single result or "item") from feed() then feed() stops, the generator resumes, returns (the value of the last item), then the generator pauses, feed() resumes and so on, in a loop. - Would it not be possible alternatively, for the generator, to call (slightly more indirectly) the feed() function in an independent thread, accumulate the last N results in a queue (N being a parameter to pass to the generator), so that the generator would still appear to return one result at time, in order, but in fact they would be pulled from the queue, while the feed function keeps running in the background feeding the queue (the queue would act as a buffer, storing the last N results of the feed() method). - The expected result is an expected increase of performance, compared to the present scheme where feed() and the generator wait in turn for each other, exchanging only one item at a time. Serge. Would it not be possible to combine the last two examples: On Fri, Jul 15, 2011 at 11:43 PM, Jim Peters wrote: > > I've created a new page on the wiki trying to make the 'async' stuff > easier to understand: > > http://live.gnome.org/Vala/AsyncMethods > > I've added the old GIO example (updated to shutdown nicely), a > Generator example, and an example that starts a background thread. > > I'm not sure what the procedure is for documentation, or who owns > what. This page could be merged with the Tutorial if someone thinks > that is a good idea. > > If there is anything incorrect, I'm happy to fix it -- > > Jim > > -- > Jim Peters (_)/=\~/_(_) j...@uazu.net > (_) /=\ ~/_ (_) > Uazú (_)/=\~/_(_)http:// > in Peru(_) /=\ ~/_ (_)uazu.net > ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] EOF problems
python's case : https://gist.github.com/f0ff2c3c66e6a5842e70 python return '' as EOF. but I don't know how to do well it with vala... Sorry that I can't be of a help. 2011/7/16, Luca Bruno : > On Fri, Jul 15, 2011 at 10:57:21PM +0200, Stefan Risberg wrote: >> I am trying to read a file char by char but I can't find where or >> how I can check if end of line (EOF) was found. I'm writing a simple >> parser for a project but I can't seem to find in the online api doc >> of gio or glib how to check for it. I saw that I can do it using >> posix, but I would rather use gio. > > Doesn't it throw an IOError on end of file? > > -- > http://www.debian.org - The Universal Operating System > ___ > vala-list mailing list > vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list > ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Documenting 'async' / WAS: Further speculations on couroutines, generators and threads : Emulating Go's goroutines and channels in Vala
Luca Bruno wrote: > > In the first two cases, is the .end() handled automatically? Looking > > at the generated code, it doesn't seem so. Could this be a problem? > > For example, could this cause a leak? > > It's not a problem. Thanks. I've created a new page on the wiki trying to make the 'async' stuff easier to understand: http://live.gnome.org/Vala/AsyncMethods I've added the old GIO example (updated to shutdown nicely), a Generator example, and an example that starts a background thread. I'm not sure what the procedure is for documentation, or who owns what. This page could be merged with the Tutorial if someone thinks that is a good idea. If there is anything incorrect, I'm happy to fix it -- Jim -- Jim Peters (_)/=\~/_(_) j...@uazu.net (_) /=\ ~/_ (_) Uazú (_)/=\~/_(_)http:// in Peru(_) /=\ ~/_ (_)uazu.net ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] EOF problems
On Fri, Jul 15, 2011 at 10:57:21PM +0200, Stefan Risberg wrote: > I am trying to read a file char by char but I can't find where or > how I can check if end of line (EOF) was found. I'm writing a simple > parser for a project but I can't seem to find in the online api doc > of gio or glib how to check for it. I saw that I can do it using > posix, but I would rather use gio. Doesn't it throw an IOError on end of file? -- http://www.debian.org - The Universal Operating System ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] EOF problems
I am trying to read a file char by char but I can't find where or how I
can check if end of line (EOF) was found. I'm writing a simple parser
for a project but I can't seem to find in the online api doc of gio or
glib how to check for it. I saw that I can do it using posix, but I
would rather use gio.
The code I'm working with
// CODE ///
namespace FsXml
{
public class Main
{
public static int main(string[] args)
{
stdout.printf("trying to find file %s\n", args[1]);
var f = File.new_for_path(args[1]);
if(!f.query_exists())
{
stderr.printf("File does not exist\n");
return 1;
}
try
{
var dis = new GLib.DataInputStream(f.read());
uchar p;
while(true)
{
p = dis.read_byte();
stdout.printf("%c %d\n", p, p);
}
stdout.printf("End of file\n");
}
catch(IOError e)
{
stderr.printf("IOError: %s\n", e.message);
return 2;
}
catch(Error e)
{
stderr.printf("Error: %s\n", e.message);
return 2;
}
return 0;
}
}
}
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Documenting 'async' / WAS: Further speculations on couroutines, generators and threads : Emulating Go's goroutines and channels in Vala
On Fri, Jul 15, 2011 at 11:34:17AM -0500, Jim Peters wrote:
> > Can you rephrase?
>
> We can call 'method' either like this:
>
>method();
>
> or like this:
>
>method.begin();
>
> or like this:
>
>method.begin((obj, res) => {
>method.end(res);
> });
>
> In the first two cases, is the .end() handled automatically? Looking
> at the generated code, it doesn't seem so. Could this be a problem?
> For example, could this cause a leak?
It's not a problem.
--
http://www.debian.org - The Universal Operating System
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Documenting 'async' / WAS: Further speculations on couroutines, generators and threads : Emulating Go's goroutines and channels in Vala
Luca Bruno wrote:
> All correct.
Thanks.
> > Question: At the C level, I guess this first calls forwards to
> > 'other_method' to start it before returning to the caller due to the
> > 'yield'. If the 'other_method' also yields, then there is no
> > problem, but if 'other_method' finishes without yielding (e.g. if it
> > can return the result right away without doing any asynchronous
> > work), then the 'method' callback would be called again, only a few
> > stack frames lower. In theory if 'method' called 'other_method'
> > repeatedly like this, the stack could overflow. Is this correct?
> > If so maybe that needs documenting.
>
> Variables in async methods are allocated on the heap. By the way I
> think I didn't understand well the problem you're raising.
The generated C code sometimes uses 'g_simple_async_result_complete',
and sometimes 'g_simple_async_result_complete_in_idle'. There are
cases where if it used 'g_simple_async_result_complete', then the C
stack could grow and grow. However, I tried writing some code to
provoke this situation, and it used the *_idle call in this case and
didn't fail. So perhaps Joerg already thought of this case.
Here was the test case:
async void tester() {
// Call read_item for values it returns right away, trying to
// provoke stack overflow from the callbacks
for (int a = 0; a<200; a+=2) {
var val = yield read_item(a);
}
}
async string read_item(int a) {
if (a % 2 == 0) {
// Pretend we have it in cache and can return right away
return @"Value: $a";
} else {
// Pretend that this is a value that we need to fetch over the
// network, so we yield and return the value some time later
Idle.add(read_item.callback);
yield;
return @"Value: $a";
}
}
void main(string[] args) {
var loop = new MainLoop();
tester.begin((obj, res) => {
tester.end(res);
loop.quit();
});
loop.run();
}
> > - Call with .begin(). Question: Is this just like the 'method()' call
> > but adding a callback request for when method() finishes? If so
> > will it also just run until the first 'yield' and then return?
> >
> > method.begin(args, callback);
>
> Yes.
>
> > - Call with .end(). For use within the 'begin' callback, to get
> > method return value and clean up. Question: Is an .end() call
> > required for plain 'method()' style invocation?
> >
> > method.end(out_args);
>
> Can you rephrase?
We can call 'method' either like this:
method();
or like this:
method.begin();
or like this:
method.begin((obj, res) => {
method.end(res);
});
In the first two cases, is the .end() handled automatically? Looking
at the generated code, it doesn't seem so. Could this be a problem?
For example, could this cause a leak?
> > Also, questions:
> >
> > - Are there any other special features associated with async methods?
> > (Any other . features, for example.)
> >
>
> No.
>
> > - When it is necessary to have a main loop running? Some of the
> > generated C code requests an idle callback. I guess this won't work
> > without a main loop running. But the Generator, for example, seems
> > to run through fine without a main loop.
>
> Mainloop is required only for async methods that never use yield.
>
> >
> > - The docs say "The .callback call is used to implicitly register a
> > _finish method for the async method". What does this mean? Also:
> > "end() is a syntax for the *_finish method". I'm confused.
>
> Try looking at the generated C code.
I think the second phrase makes sense. The first phrase doesn't seem
correct: "The .callback call is used to implicitly register a _finish
method for the async method".
Who owns the Vala Tutorial? I could add more info to the Tutorial,
but if that isn't okay I will create a new wiki page.
Jim
--
Jim Peters (_)/=\~/_(_) j...@uazu.net
(_) /=\ ~/_ (_)
Uazú (_)/=\~/_(_)http://
in Peru(_) /=\ ~/_ (_)uazu.net
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
