Re: [Vala] C# Developer
On 10/09/2018 11:38 AM, Ulink wrote: > Maybe improving Gnome builder Vala integration is the right way? Builder needs someone familiar with Vala internals to take over the Vala plugin (src/plugins/vala-pack) if you want to get better quality integration. I simply don't have time to work on it given my queue. One thing many of us learned while working on MonoDevelop internals was that to build really good auto-completion and diagnostics, you need to change how you write the compiler. That is in fairly stark contrast to writing an efficient compiler for other uses. (Roslyn was a major effort on that front). You need to keep a lot more data around than you'd need want otherwise. Especially since you'll be mostly working with partial files that don't parse fully and need access to the previous AST while performing completions on the partial. Writing a compiler is hard work, and doing one that doesn't leak/crash is even harder. So we really want to see the Vala plugin follow our work with Clang last cycle and move things out of process (while maintaining good performance despite IPC). That allows us to supervise/kill the language server as necessary. I wrote jsonrpc-glib to make it easier to write language servers. Corentin started on extracting the Vala plugin from Builder, but it needs someone to push through on it. https://gitlab.gnome.org/GNOME/gnome-builder/tree/wip/tintou/vala-subprocess But even with that, it sounds like some features are missing from the Vala compiler to get quality completion results. -- Christian ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Writing objects to files
On 03/28/2018 10:44 AM, Steven Oliver wrote: > > On the other hand, though, if you throw in some kind of data structure > besides your basic types (int, string, etc.) it completely fails. https://developer.gnome.org/json-glib/stable/json-glib-Serializable-Interface.html#JsonSerializableIface If your GObject implements that interface, you can control what gets serialized and in what format. ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Date format
On 03/27/2018 04:46 PM, rastersoft wrote: > > I'm writting a program that shows dates in the screen. The problem I > have is that I want to show them in the local format, but there is only > one way: with full day of week, time and timezone. > > Is it possible to print from a GLib.Date only the date, without the day > of week, neither the time, nor timezone? Nearly a decade ago, I created GDateTime for GLib to give people a modern API for dealing with these types of problems. I very much suggest using that over the ancient GDate. -- Christian ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Writing objects to files
On 03/26/2018 11:44 AM, Steven Oliver wrote: > I want to implement "saving" in my program. The data I want to save is > a custom object. Is it possible in vala to simply write the object to > disk (in binary I assume) without having to implement a to_string > method? > > It seems like such a simple concept yet i can't seem to figure out how > to do it in Vala. A very simple option (assuming you don't have an object graph to serialize) could be to use either: Json.gobject_serialize() Json.gobject_to_data() to serialize and Json.gobject_deserialize() Json.gobject_from_data() to deserialize. If you need custom hooks into what will get serialized, you can implement Json.Serializable. If you really want binary, GVariant is a rather nice serialization format, but you might need to bring your own serializers. Json-GLib has some code for working with GVariant too, but I've not used it. If you need an object graph, the Gom¹ library I made several years back can help, but it is more intrusive on your object design. I've only used it from C, but others have used it from Gjs, so I would expect it to work in some form from Vala. -- Christian ¹ https://git.gnome.org/browse/gom ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Need help to scroll a textview using a scale
On 01/24/2018 10:03 AM, Manish Jain wrote:
My last effort at the event handler is below (it is of no use, really):
void scale_moved (Gtk.Range range)
{
int i;
Gtk.TextIter iter = new Gtk. TextIter();
view.get_iter_at_position(out iter, out i, 0, 0);
iter.set_line(iter.get_line() + 10);
view.scroll_to_iter(iter, 0, false, 0, 0);
}
GtkTextView implements GtkScrollable, which means you can get a
GtkAdjustment for the vertical range.
Something like:
range.adjustment = text_view.vadjustment;
You can also just add the textview to a GtkScrolledWindow.
-- Christian
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala++
On 04/04/2017 01:47 AM, Ulink wrote: > I simply can't understand why the Gnome people seems to hate or at least > ignore Vala and instead promote Javascript or Rust or other weird stuff. Some of us in GNOME have spent many years writing programming languages and runtimes. Therefore our view is somewhat nuanced and opinionated. Your viewpoint may be different, and that's okay. > I recently wrote a 200k LOC Gtk app and Vala did the job perfectly. No > way for Javascript, Python, C++ or even C or Rust. Congrats! Builder is about 200k of C and it's taken me the past 2 years to get there. That amount of work should be applauded no matter what the language. Cheers, -- Christian ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala++
On 04/04/2017 12:22 AM, Daniel Brendle wrote: > There are many languages that are also fun when it comes to programming > against the Glib based library stack. The more interesting part is: will > there ever be a language that makes it also as convenient to write > gobject-introspectable libraries. That is the one true thing that one > can do very conveniently with Vala but with no other ecosystem can do > yet. I hope the rust-gnomies care about that too and not only on using > the bindings. It's an integral part of integrating well into the gnome > library ecosystem imho. > I am stoked to see what the results will be. Yes, it can go both directions. -- Christian signature.asc Description: OpenPGP digital signature ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] ListStore and SQLite
I wrote a GtkTreeModel that fronted SQLite years ago. I think Conduit still uses a python prototype I made which is far more optimized than the original prototype in C (EggSqliteStore). It might serve as a base however to get you started. http://audidude.com/dropbox/egg-sqlite-store/ -- Christian On Tue, Sep 22, 2009 at 12:30 PM, Magentus magen...@gmail.com wrote: On Mon, 21 Sep 2009 14:10:34 +0200, Nicolas c.r@wanadoo.fr wrote: I made a simple program to fill a liststore with a sqlite db (name, age, sex). But, i have a problem, someone knows how to save in the db when user change a cell ? Not an answer to your question... I was just wondering, is there any plan to construct a TreeModel that can represent an SQLite database (or a view thereof)? I'm likely going to have a similar requirement soonish, and feel this would be the right way to do it. Rationale: ListStore and TreeStore are simply alternative implementations of TreeModel, so it sort of surprises me there isn't already an SQLiteStore which I would think, would quite neatly side-step a big part of this issue. Read a row of the store, and a the data is fetched from the backing database. Write new data to the store, and that data is written to the backing database. Additionally: Slip in an overlay (similar to the sorting and filtering presently supported) to act as a commit buffer, and you'd have a basic but quite effective database front-end. Additionally(2): Combine that with a connector that can connect the fields of a TreeModel row with widgets in a UI, and you could very quickly build up a pretty substantial database-driven interface. I have something that rather poorly implements such a connector between widgets and a struct, but none the less works pretty well (it even allows apply/revert by being attached to a memdup()d copy of the real struct). I've been mulling over the idea of building a back/front-connector pair; front connectors map a single field of a back connector to a widget or whatever else, with helper functions to establish the required signals to any suitable widget (widgets could even implement a front-connector interface making them instant candidates). The back connector maps its fields to a TreeModel row, or a struct, key=value format file, or whatever else. But quite frankly, I'm not that good with GValue, to do the idea justice. :( -- Fredderic Debian/unstable (LC#384816) on i686 2.6.30-1-686 2009 (up 3:09) ___ 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] Port Tomboy?
Nonetheless I still think if VALA needs bigger, live projects to increase the level awareness which it deserves. At least among the open-source vala projects tracked by ohloh, I don't see any of them a critical application(by critical I mean a real develop team, active development and large codebase). I don't think this situation is healthy for the language's eco-system. I would like to do a survey/study about the situation. How do you think? You probably wont see bigger projects using vala until the API and language is stable. It's tough to depend on a moving target where code compiles today and not tomorrow. With the rate that changes are coming in and the tenacity of developers who are active on this list, I'm sure it wont be too much longer until it happens organically. -- Christian ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] mod_vala (was Removal of Mono)
It's a cute thought. But then you would try to debug a segfault or memory corruption on a production site. -- Christian On Mon, Jun 29, 2009 at 9:25 PM, Michael B. Trauschm...@zest.trausch.us wrote: On Tue, 30 Jun 2009, Jeremy wrote: Maybe mod_mono (for apache) is an example of the sort of dependency I was thinking of: http://ibbie.xanga.com/686874553/item/ That would be my blog post. I do still think a mod_vala would be a *great* idea. Unfortunately, I feel it best to suggest that focusing on improving the documentation might be a better goal. Both flavors of syntax are great; but anyone coming in, either knowing another language or just new to programming, will be discouraged when they can't find the answers. After all, it's really difficult to RTFM when there's no (finished) FM. I mean, imagine if you did man sbrk, and at RETURN VALUE it just said To be completed... (; Hrm. A mod_vala might be okay, but it would be necessarily non-portable. Why not have a FastCGI library for GObject instead, and then Vala (or C) can be used to create applications that use the FastCGI protocol run run behind a Web server? The FastCGI library could be a bare, low-level thing that just implemented the protocol, and have a layer that sat on top of it to provide more reasonable interface to the proess and make it easy to work with. That would accomplish something along the lines of a mod_vala, but it would not only work with Apache, but a fair lot of other Web servers, as well. --- Mike ___ 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] Zeitgeist porting
First off, I think Vala is a good choice, but for a completely different reason than what has been said here. Mono is quite fast, and just because it has a runtime does not mean it can't be. Remember that mono does JIT your code into native assembly at startup (most tests i've made take between 10-70ms for JIT). Nothing is interpreted like with say python (we will see if that new google project will help by using llvm here). You can also get wins with Regex, and I assume zeitgeist will use those a lot if its trying to analyze files and data. Mono's regex engine can actually JIT your regex's, which happens to be faster than pcre last I read. However, with the exception of Mono 2.4 (i think it made it in the branch), Mono's lock implementation includes timed waits on pthread conditions that wake up every so many milliseconds. So if the target is hardware that may not be running the newest mono (and especially low power) it may not yet be a good choice. Now, the reason I would still say Vala, has to do with interoperability. If we want other applications to take full advantage of zeitgeist, we have 2 common extension possibilities. The first, are extensions from outside of zeitgeist. DBus would work just fine for this, allowing any programming language that supports DBus to provide interaction from outside the process. Mono would work just fine for this obviously. The second, are extensions *within* zeitgeist. This really should be, what I feel, the deciding factor. If you want to allow plugins in a multitude of languages, you need to break down to GObject's most basic parts. This way each binding can interact with the proper data types. For example, I would want to write plugins in python, ruby, js, or c# (and i don't feel ironpython or ironruby are acceptable yet). The only way to do this with mono would be to create those core data types in C, or create a trampoline layer with wrapper methods in C that can be called from language bindings. I doubt anyone would want to maintain this either. Anyway, just my 0.02$ -- Christian On Sat, Apr 4, 2009 at 4:18 AM, Andrea Bolognani e...@kiyuko.org wrote: On Fri, 03 Apr 2009 21:31:13 -0400 Jamie McCracken jamie.mccr...@googlemail.com wrote: Why? Whilst it has some interesting ideas, its a mere prototype and is by and large irrelevant to gnome as it stands (and thats true of gnome-shell as well - they are both purely experimental) Both the new GNOME Shell and GNOME Zeitgeist are going to be core components of GNOME 3.0, according to [1]. If the ideas prove worthy it will be rewritten in a non-vm language and will likely use tracker which is infinitely more powerful given the ability to show all your docs, music, photos as derived from its indexer I very much doubt an important always on component will be acceptable if its coded in a VM - that has been the way with gnome to date and I dont see that changing I sure hope so. Using Vala would give most of the benefits of C# without incurring in the same overhead. [1] http://live.gnome.org/ThreePointZero/Plan -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. ___ 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] Generics: constraints and 'new T ()' on type parameters?
I wrote a datamapper (rather than an ORM) a while back in Vala. I
don't think anyone is really using it, but it might be an example for
various problems or questions you run into.
http://git.dronelabs.com/git?p=users/chris/godm.git;a=summary
It does let you do some neat stuff (and creates objects for you) like
Person.find(Condition.str_equal(firstname, Christian)).slice (0,
10).each(p = {
stdout.printf (%s\n, ((Person)p).lastname);
});
It also has various backends (called contexts) for data sources such
as Json or Sqlite.
HTH,
-- Christian
On Thu, Feb 26, 2009 at 4:52 PM, Sam Danielson samdaniel...@gmail.com wrote:
I'm writing some ORM where a database view is wrapped in a factory
object that produces records. Ideally I would think a Factory T
should be able to return new T's but I can't figure out how to do
this. The work around is to return the Record base class and then
upcast, or put virtual upcasting functions in all of the
derived Factory classes. Yuck.
Is there a fundamental reason why this cant work?
class Foo {}
class Factory T {
public static T make () {
return new T ();
}
}
And is there a plan to implement type parameter constraints? Something like...
class Factory T:Object { ... }
The compiler may then prove that it is okay to 'new T ()'
PS. I can slip the following by the type system without a complaint. Should I
file a bug?
class Foo {}
class Factory T {
public static T make () {
return new Foo ();
}
}
LLAP,
Sam Danielson
___
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
[Vala] time_t properties
How would I go about making a property with time_t. It looks like the
generated code is boxing just fine, it just generates a bad gtype for
time_t. I will create a bug if necessary.
$ valac test.vala
test.c: In function 'test_item_class_init':
test.c:83: error: 'TYPE_TIME_T' undeclared (first use in this function)
test.c:83: error: (Each undeclared identifier is reported only once
test.c:83: error: for each function it appears in.)
error: cc exited with status 256
Compilation failed: 1 error(s), 0 warning(s)
$ cat test.vala
using GLib;
namespace Test {
public class Item: Object {
public time_t created_at {
get;
set;
}
}
}
-- Christian
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Inverse of control in VALA?
I agree, having types loaded at startup would make life a lot easier in most of my situations. Is this already done with types in plugins when the plugin is loaded? -- Christian ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] volatile variables?
Is that even be possible on 32bit? sizeof(gdouble) is 8. -- Christian On Sun, 2009-01-11 at 17:54 -0500, Yu Feng wrote: Hi all, How do I declare a volatile double variable? Yu ___ 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] [ANNOUNCE] Vala 0.5.1 - Compiler for the GObject type system
On Sun, Nov 23, 2008 at 2:22 AM, Jürg Billeter [EMAIL PROTECTED] wrote:
On Sun, 2008-11-23 at 01:31 -0800, Christian Hergert wrote:
I'm excited about the addition of yielding values. I released GTask
0.1.2 last week which is an asynchronous/concurrency library for
GObject with similar feel to twisted deferreds. I would love to be
able to yield tasks and have the method re-enter when the task has
completed.
This should be possible by adding something like the following to GTask:
void
g_task_run_async (GTask *task, GAsyncReadyCallback callback, gpointer
user_data)
{
AsyncData *data = g_slice_new (AsyncData);
data-callback = callback;
data-user_data = user_data;
g_task_add_callback (task, async_callback, data, NULL);
g_task_scheduler_schedule (g_task_scheduler_get_default (), task);
}
static GValue *
async_callback (GTask *task, const GValue *result, gpointer user_data)
{
AsyncData *data = user_data;
GSimpleAsyncResult *res = g_simple_async_result_new (task,
data-callback, data-user_data, result);
g_simple_async_result_complete (res);
g_slice_free (AsyncData, data);
return NULL;
}
GValue *
g_task_run_finish (GTask *task, GAsyncResult *res)
{
return g_async_result_get_user_data (res);
}
In Vala this could be used as follows:
void do_something () yields {
var task = new Task (_ = { return some_sync_operation (); });
var result = task.run ();
stdout.printf (Result was %s\n, result);
}
Other API variations are possible, of course, that's just an example.
Jürg
Thats awesome! It will definitely make it into the next release.
-- Christian
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Object constructors
Anything against the following?
new Person () {
login = Bob,
password = hello,
email = [EMAIL PROTECTED]
};
Cheers,
-- Christian
2008/10/31 Кутейников Дмитрий [EMAIL PROTECTED]
It would be great, if Vala could compile expressions like this:
*var bob = new Person(login=Bob, password=hello, email=[EMAIL PROTECTED]
);*
Compiler may replace it with:
var *bob = new Person();
bob.**login = Bob;
**bob.password = hello;
**bob.email = [EMAIL PROTECTED];*
___
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] GTest
Hello, Here is an example from one of my projects. http://github.com/chergert/gtask/tree/master/tests/test-4.vala -- Christian On Sun, Oct 26, 2008 at 8:08 AM, Frederik [EMAIL PROTECTED] wrote: Maciej Piechotka wrote: Is there any samples how to use GTest? Best regards Hi, I haven't even found any C samples, and some macro bindings seem to be missing in the vapi. But I have discovered VUnit of the People Project: https://code.launchpad.net/~jprieur/people-project/vunithttps://code.launchpad.net/%7Ejprieur/people-project/vunit This seems to be more object oriented than the GLib testing suite. I would like to see this as a standalone library like libgee. I'm highly interested in an official unit testing framework for Vala, which would make testing as easy as possible. Such a library could also provide a graphical GTK+ test runner tool or widget, like the one of GUnit [1] [2], that could get embedded into Vala IDEs like Val(a)IDE. Regards, Frederik [1] http://personal.inet.fi/koti/peter.hagg/gunit/ [2] http://pvanhoof.be/files/tny-test-suite.png ___ 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] Proposal for an improved delegate/lambda handling
What about methods that take 2 callbacks?
-- Christian
2008/10/18 Ali Sabil [EMAIL PROTECTED]:
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;
}
);
// Proposed syntax:
// Vala would basically use the pseudo-lambda expression
// following the method call as a parameter to the method call
client.post_request(GET ) (string response) {
debug (got response %s, response);
return true;
}
I am very open to comments and suggestions.
Cheers,
--
Ali
___
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] Proposal for asynchronous DBus calls.
For tasks, you have two options.
1) Create a GTask with a callback and user_data.
2) Inherit from GTask and implement the execute (and optionally,
cancel) methods.
Keen observers will notice my challenge right away. Yes, I inherit
from GObject for reference counting and general ease of use. It was a
tough choice. That may make scalability an interesting feat without
reusing tasks with a sort of free-list (a la threading building
blocks).
Point being, your shared variables will live in the target of your GTaskFunc.
And the prototype for sake of link jumping.
typedef GTask* (*GTaskFunc) (GTask *task, GError **error, gpointer user_data);
Notice how a task/callback/errback can pause further execution of the
state machine by returning another task immediately. Errback's will
have the option to free and unset error to allow for further
processing of the callback chain. Not quite sure how to handle this
in vala bindings yet. I'm considering dropping error from the
prototype and adding it as tasks methods (task.{get/set}_error).
-- Christian
On Fri, Oct 17, 2008 at 1:05 AM, Sam Liddicott [EMAIL PROTECTED] wrote:
* Christian Hergert wrote, On 17/10/08 08:06:
This isn't totally applicable, but I thought I'd mention it before too
much more async voodo.
I've been working on an asynchronous toolkit library for GObject so
that once we get yield return/yield break support I can implement my
ideas I posted earlier.
The library is called GTask and can be found on github[1]. For a
quick, totally out of context example:
var task = new Task (_ = {
debug (im in worker thread);
});
task.add_callback (_ = {
debug (im in main thread, by default);
});
task.add_errback (_ = {
debug (i can resolve an asynchronous error);
});
You can build complex callback/errback chains just like in Python
Twisted. By default, the task scheduler will dispatch callbacks and
errbacks from the main thread to ease locking hell for GUI
This looks a similar pattern to that used in samba's composite connect;
I think it is useful.
How will shared variables be expressed?
Sam
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Proposal for asynchronous DBus calls.
Totally. Like I said, not really applicable, but figured I'd mention it.
With closures, the framework will stay the same, you just get access
to more locals as your user_data wont get hi-jacked by the instance,
but the closure data.
-- Christian
On Fri, Oct 17, 2008 at 2:25 AM, Sam Liddicott [EMAIL PROTECTED] wrote:
* Christian Hergert wrote, On 17/10/08 09:24:
For tasks, you have two options.
1) Create a GTask with a callback and user_data.
2) Inherit from GTask and implement the execute (and optionally,
cancel) methods.
Keen observers will notice my challenge right away. Yes, I inherit
from GObject for reference counting and general ease of use. It was a
tough choice. That may make scalability an interesting feat without
reusing tasks with a sort of free-list (a la threading building
blocks).
Point being, your shared variables will live in the target of your
GTaskFunc.
And the prototype for sake of link jumping.
typedef GTask* (*GTaskFunc) (GTask *task, GError **error, gpointer
user_data);
Notice how a task/callback/errback can pause further execution of the
state machine by returning another task immediately. Errback's will
have the option to free and unset error to allow for further
processing of the callback chain. Not quite sure how to handle this
in vala bindings yet. I'm considering dropping error from the
prototype and adding it as tasks methods (task.{get/set}_error).
heh.
I want to do async handlers in order to avoid writing the state machine,
and to avoid having to declare a class with all my shared variables.
I want to write a linear function and not mind if it gets broken up.
I suspect this is because I am user of someone elses async framework,
you are trying to devise an async framework.
Sam
-- Christian
On Fri, Oct 17, 2008 at 1:05 AM, Sam Liddicott [EMAIL PROTECTED] wrote:
* Christian Hergert wrote, On 17/10/08 08:06:
This isn't totally applicable, but I thought I'd mention it before too
much more async voodo.
I've been working on an asynchronous toolkit library for GObject so
that once we get yield return/yield break support I can implement my
ideas I posted earlier.
The library is called GTask and can be found on github[1]. For a
quick, totally out of context example:
var task = new Task (_ = {
debug (im in worker thread);
});
task.add_callback (_ = {
debug (im in main thread, by default);
});
task.add_errback (_ = {
debug (i can resolve an asynchronous error);
});
You can build complex callback/errback chains just like in Python
Twisted. By default, the task scheduler will dispatch callbacks and
errbacks from the main thread to ease locking hell for GUI
This looks a similar pattern to that used in samba's composite connect;
I think it is useful.
How will shared variables be expressed?
Sam
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [Bindings] for ThreadPool broken
I believe I filed a bug on this a while ago.
http://bugzilla.gnome.org/show_bug.cgi?id=542725
-- Christian
2008/10/3 Mihail Naydenov [EMAIL PROTECTED]
When used TreadPool, the c compiler reports:
***error: too few arguments to function `g_thread_pool_free'***
ThreadPool is defined in glib-2.0.vapi as:
[Compact]
[CCode (free_function = g_thread_pool_free)]
public class ThreadPool {
...
}
but g_thread_pool_free accepts 2 more args (except the thread pool, which
is passed in) - immediate and wait_
Is it possible way to set (some defaults for) those?
If not, then one must manually manage the pool, but of course, there no
bindings for g_thread_pool_free in the vapi.
MihailNaydenov
___
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] Implicit lamdas/closures
I absolutely love the yield idea, very python-twisted'ish. Lets make sure the yield can return a value as well so we can have the following: var value = yield obj.do_something (); -- Christian On Tue, Sep 16, 2008 at 3:34 PM, Jürg Billeter [EMAIL PROTECTED] wrote: On Tue, 2008-09-16 at 22:48 +0100, Sam Liddicott wrote: Here I am working my self into brain fever, and not a peep! No-one says stop him, the fool or darn fiendish cunning or even he's using goto's, the churlish knave. No-ones saying don't taint the language with your base practicalities or even whatever can it mean? Someone say something before I get dragged back to more fiscally accountable projects. If I write the code is it likely to be accepted? I like the idea of adding language support for asynchronous method calls, I was thinking of implementing this for some months but it wasn't on the top of my todo list. I haven't tried implementing this, but I think that the Vala code could be made even simpler and the labels should not be necessary. My idea is to introduce a modifier/attribute to mark methods as async capable. If you call an async method using the `yield' keyword, it will automatically introduce a continuation point there, i.e., add a callback and return in C. The async method call will not accept any delegate or lambda, it will just implicitly use the rest of the method body. In contrast to your example, it should support the two situations (async or sync call) without the if (request.may_async) in the Vala code, it already has all the information necessary. It should probably generate two public functions in C, an async and a sync version, similar to the GIO API. Does this make sense or do you need an example? Do you see any issues with this approach? Jürg ___ 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] Implicit lamdas/closures
Speaking of ... throwing exceptions via the yield should also be supported.
This would allow for try/catch around async calls.
try {
var result = yield obj.do_something ();
} catch (Error err) {
//
}
On Tue, Sep 16, 2008 at 3:43 PM, Jürg Billeter [EMAIL PROTECTED] wrote:
On Tue, 2008-09-16 at 15:39 -0700, Christian Hergert wrote:
I absolutely love the yield idea, very python-twisted'ish. Lets make
sure the yield can return a value as well so we can have the
following:
var value = yield obj.do_something ();
Sure, return values should certainly be possible.
Jürg
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] RSS/Atom or XML parsing library
I haven't touched rss-glib in a couple months, but if you have feature requests, i'll hack them in promptly. I don't think i announced it on the list here either, but if anyone is interested in a datamapper for gobject, i made one of those as well (which ive used pretty successfully with rss-glib for storing rss items). It can be found at git://git.dronelabs.com/git/users/chris/godm.git and an example of usage here http://audidude.com/blog/?p=37 -- Christian On Wed, Sep 10, 2008 at 6:34 AM, Alexander Bokovoy [EMAIL PROTECTED] wrote: On Wed, Sep 10, 2008 at 5:24 PM, Alessandro Pellizzari [EMAIL PROTECTED] wrote: Hi all, for a software I am writing, I would like to be able to decode RSS/Atom feeds, mapping them to Vala objects, like DOM. Is there a library with vapi files ready? Or else, what library would you suggest? (I would like to see if I can write some vapi files... :) There is rss-glib, git://git.dronelabs.com/git/users/chergert/rss-glib.git which is GObject wrapper around libmrss (http://www.autistici.org/bakunin/libmrss/doc/). The rss-glib library has full Vala support. -- / Alexander Bokovoy ___ 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
[Vala] void ref func
Hi, Does anyone have any tips for how to handle a ref_function that returns void? -- Christian ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] (u)int64 properties
Hi, I noticed that when int64 properties are installed, g_param_spec_pointer is used. I created a bug and attached a patch. http://bugzilla.gnome.org/show_bug.cgi?id=543055 Thanks! -- Christian ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] GValue magic
Hi, Wanted to suggest a feature that would be useful to simply the consumption of GValue based methods. Just a bit of compiler magic to automatically box/unbox values into GValue's? For example, public void do_something (GValue *value); // create a gvalue, and use proper g_value_set method do_something (blah); or do_something (100); If others are interested, I will create a bug. Cheers, -- Christian ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] GValue magic
Ok, created bug #541949. http://bugzilla.gnome.org/show_bug.cgi?id=541949 -- Christian On Mon, Jul 7, 2008 at 12:52 PM, Sam Liddicott [EMAIL PROTECTED] wrote: Christian Hergert wrote: Hi, Wanted to suggest a feature that would be useful to simply the consumption of GValue based methods. Just a bit of compiler magic to automatically box/unbox values into GValue's? For example, public void do_something (GValue *value); // create a gvalue, and use proper g_value_set method do_something (blah); or do_something (100); If others are interested, I will create a bug. Yeah, this looks good. Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] delegates with exceptions
Hi folks, I noticed that there is support for delegates to throw when wrapping libraries (the vapi's do it in a few places). However, I'd like to have a delegate in my vala code that can throw an error. This doesn't seem to happen even though it compiles. For example: public delegate void Callback (Result result, void* data) throws GLib.Error; currently compiles to, typedef void (*Callback) (Result result, void* data, void* user_data); While I'd expect it to compile to typedef void (*Callback) (Result result, void* data, void* user_data, GError **error); Therefore, calling the method in a try/catch results in warning: unreachable catch clause detected. If this really is a bug, and not just me, I'd be glad to submit a bug report and perhaps start patching. Cheers! -- Christian ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
