Re: [Vala] Vala logo symbol voting
On 27/08/11 15:29, Tobias Bernard wrote: 2) The symbolism of "ancient warfare" is hard to understand. Probably too hard to be understood instantly by most people, so I put that proposal away too. The presentation is very good. I think that symbols of weapons, killing and/or warfare should be avoided, having very current and unpleasant connotations for many people in specific locales. Sam ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] The state of closures
On 28/04/11 17:45, Luca Bruno wrote: On Thu, Apr 28, 2011 at 05:19:22PM +0100, Sam Liddicott wrote: yes.. it's been a few years since I piped up. Part of the problem is (or was) with interruptable functions which tear-down the stack and thus invalidate the closure for interruptable functions. Another is that last time I checked closures still could not access local variables in the enclosing function. Last time was years ago? Try giving it a try again before looking somewhere else, vala closures nowadays have only very few issues. There's no need to reimplement something that's already working in all cases and pretty much portable. Wow! It's great! Thanks vala-devs! Sam ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] The state of closures
On 28/04/11 17:45, Luca Bruno wrote: On Thu, Apr 28, 2011 at 05:19:22PM +0100, Sam Liddicott wrote: yes.. it's been a few years since I piped up. Part of the problem is (or was) with interruptable functions which tear-down the stack and thus invalidate the closure for interruptable functions. Another is that last time I checked closures still could not access local variables in the enclosing function. Last time was years ago? Try giving it a try again before looking somewhere else, vala closures nowadays have only very few issues. There's no need to reimplement something that's already working in all cases and pretty much portable. I'd tried to keep up with the release notes but hadn't noticed that closures could now access the local variables of the enclosing function. Thanks for pointing it out, I'll give it a go. Sam ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] The state of closures
On 28/04/11 16:44, Luca Bruno wrote: On Thu, Apr 28, 2011 at 04:38:43PM +0100, Sam Liddicott wrote: On 28/04/11 16:08, Luca Bruno wrote: On Thu, Apr 28, 2011 at 03:58:32PM +0100, Sam Liddicott wrote: This feature may be less useful for vala if it does stack-tear-down for interruptable functions, but perhaps more suited if it uses co-routines with different stacks so that the stack is switched and not torn-down when an interruptable function is interrupted. Yes that's the problem, with vala you may pass the closure to another function and exit from the current scope, while with gcc nested function the stack is lost once you exit the outer function. And it's hard to control this or know when it is happening by accident. I wonder if it is worth considering libpcl or other co-routine libraries - it would take away the need for a lot of effort to get fuller closure support. I've also been thinking of ways to detect when vala closures go stale - one way is for the data pointer to be indirected via a heap allocated pointer. This could be set to null by the outer function when it exits, and so any use after this point can be detected - as when the wrapper trampoline function is executed it will detect that the data pointer points to NULL instead of pointing to the actual data pointer. I don't get what's the problem with actual vala closures that you need to find an alternative yes.. it's been a few years since I piped up. Part of the problem is (or was) with interruptable functions which tear-down the stack and thus invalidate the closure for interruptable functions. Another is that last time I checked closures still could not access local variables in the enclosing function. I was suggesting that if GCC closure support were used and co-routines for interruptable functions that then closures could access local variables of the enclosing functions quite well. Otherwise This stemmed from a time when I was trying to use vala to write samba 4 modules where the closure support (with access to variables of the enclosing function) would have been very useful if it could survive the tear-down of the stack (which libpcl co-routines provide). Sam ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] The state of closures
On 28/04/11 16:08, Luca Bruno wrote: On Thu, Apr 28, 2011 at 03:58:32PM +0100, Sam Liddicott wrote: This feature may be less useful for vala if it does stack-tear-down for interruptable functions, but perhaps more suited if it uses co-routines with different stacks so that the stack is switched and not torn-down when an interruptable function is interrupted. Yes that's the problem, with vala you may pass the closure to another function and exit from the current scope, while with gcc nested function the stack is lost once you exit the outer function. And it's hard to control this or know when it is happening by accident. I wonder if it is worth considering libpcl or other co-routine libraries - it would take away the need for a lot of effort to get fuller closure support. I've also been thinking of ways to detect when vala closures go stale - one way is for the data pointer to be indirected via a heap allocated pointer. This could be set to null by the outer function when it exits, and so any use after this point can be detected - as when the wrapper trampoline function is executed it will detect that the data pointer points to NULL instead of pointing to the actual data pointer. Sam ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] The state of closures
My last recollection of vala closures accessing variables of the enclosing function is that they would need what are normally stack-local variables to be allocated on the heap and be made accessible to the closure my means of a private pointer to the struct of the local variables. I don't know if this is still the plan, but i draw attention to section 4.4 of http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html entitled "nested functions" I suppose that this might not be new information to Vala developers. It refers to a document Usenix88-lexic.pdf which may be found here http://web.pdx.edu/~hegbloom/download/Usenix88-lexic.pdf What is interesting is the use of trampolines so that the "address" of the local function may be taken and passed about (provided that the containing function has not exited). The trampoline permits the correct local variables to be accessed by the address, even if the function is re-entrant or recursive. I suppose that the "address" is taken as an automatic variable on the stack and so is freed when the containing function exits. This feature may be less useful for vala if it does stack-tear-down for interruptable functions, but perhaps more suited if it uses co-routines with different stacks so that the stack is switched and not torn-down when an interruptable function is interrupted. Sam ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Structure initialisation syntax
On 27/04/11 11:30, David Given wrote:
Fabian Deutsch wrote:
[...]
Copy-n-pasting another way from the the tutorial to initialize a struct
type:
Color c3 = Color() {
red = 0.5,
green = 0.5,
blue = 1.0
};
This is really creating a temporary and then initialising c3 via
assignment, which isn't quite what I was looking for. If you look at the
generated code and compare the above with:
Color c3 = { 0.5, 0.5, 1.0 };
...you can see that the code generated by this syntax avoids the extra
copy. It seems surprising to me that the Type() { initialiser } syntax
supports designated initialisers while the Type t = { initialiser }
syntax doesn't.
File a bug report.
Sam
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] vala code generation too constrained?
<><>___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] for loop and closure (bug or big gotcha?)
I used a language called charamel for controlling 3d figurs. It's closures
supported variables in 2 ways.
Like valàa reference to the instantaneous value of the variable, and fixing
it's value (making a copy) at the time the closure was made.
Perhaps some [ attributes ] to the closure could spcify which variables are to
be frozen static, or perhaps atributes appled at varable use to signify use of
the static value
In any case vala can recognize that a closure is using a loop variable to issue
a warning.
Sam
-Original Message-
From: JürgBilleter
Sent: 20 January 2010 08:28
To: Nor Jaidi Tuah
Cc: vala-list@gnome.org
Subject: Re: [Vala] for loop and closure (bug or big gotcha?)
On Wed, 2010-01-20 at 14:00 +0800, Nor Jaidi Tuah wrote:
> Given this:
>
> for (int i=0; i < 10; i++) {
> button[i].clicked.connect ((s) => {stdout.printf ("%d\n", i);});
> }
>
> all the buttons, when clicked, outputs 10.
> i.e., the variable i is treated as non-local and shared
> by all those closures.
>
> Is this the correct semantic?
Yes.
> If this is up for debate I would say that this is
> a wrong semantic. Different iteration of the for loop
> should use "different" i.
The scope of the variable `i` covers the whole `for` statement, not just
a single loop iteration (otherwise i++ at the end of each iteration
wouldn't make any sense). While it's true that this may cause mistakes,
we can't change this without breaking consistency. foreach loops should
be more convenient in that regard.
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] Support for method overloading.
* Jiří Zárevúcky wrote, On 12/01/10 14:43: Sam Liddicott píše v Út 12. 01. 2010 v 07:25 +: Overloading could easily be supported with mandatory cname or csuffix attributes; that an explicit name needs to be given for C is no reason that it needs to be given for vala which could do regular overloading. I think it ought to be supported. Sam That's a matter of opinion. If Vala supported it, people would start using cnames like "lib_class_some_action", "lib_class_some_action2", "lib_class_some_action3", etc. Overloading exists because people are lazy, ain't that true? :) Even if they wouldn't, it would still make things considerably messier IMO (I, for one, do like the way I can use most C libraries without separate Vala docs or searching VAPI). The point is that although the user needs to come up with alternative names, vala doesn't need to use them, and so the official reason for not supporting overloading is nonsense. You present a new reason, that users who are idiots, will chose idiotic names. Such users may do this anyway... But anyway, if you really want it, you could just implement it and send it to Jürg for approval. I've played that game before, and lost. There's no point in working on any feature if it is not in accordance with Jürg's vision for the language. Just think whether you really need it. From my POV, it's pointless. I have my own reasons for distrusting it, how will overloading work with automatic type promotions, maybe at one instant the int value passed as an argument gets upgraded to a long int, but later someone overloads for int - your code now has a different code path without you expecting it, lets hope the new code path works like the old one. Of course the user should make it like that, but automatic type promotion and overloading worry me. But despite that, I find it useful. Who wants to keep repeating the type of an argument on the end of a function name? It's the last vestige of lpcszName type notation. Such information belongs in the computer and shown with nice markup. BTW, please use a mail client that supports message threads. :) Sorry - stinkin pocket outlook :-( Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Support for method overloading.
I meant that these would be mandatory only for 2nd and subsequent declarations. Sam -Original Message- From: Sam Liddicott Sent: 12 January 2010 07:25 To: Jiří Zárevúcky ; Fabzter Cc: vala-list@gnome.org Subject: Re: [Vala] Support for method overloading. Overloading could easily be supported with mandatory cname or csuffix attributes; that an explicit name needs to be given for C is no reason that it needs to be given for vala which could do regular overloading. I think it ought to be supported. Sam -Original Message- From: Jiří Zárevúcky Sent: 08 January 2010 15:25 To: Fabzter Cc: vala-list@gnome.org Subject: Re: [Vala] Support for method overloading. Fabzter píše v Čt 07. 01. 2010 v 16:01 -0600: > Hi. I have been playing with Vala for some months. I find it to be a really > cool language, thus, I'm thinking in porting an medium sized personal > project from C# to Vala, but it relies heavyly on method and constructor > overloading, and having this features in Vala would make my refactoring work > minimal, so I want to know if vala will ever support this features, you > know, so I can start waiting if they are planned. :) Short story: No. Long story: Vala translates to C, which doesn't support overloading. That means any overloading in Vala would mean mangling names of methods in C, which would go against one of the most significant advantages of Vala - being able to use Vala library the same way as if it was written in C. The same goes for constructors, you just need to come up with some nice names. It is also my honest belief that overloading is evil and makes programmer's work harder. Side note: Be careful with constructors, they work a bit differently in Vala, than they do in C#. Side note 2: Keep in mind that refcounting behaves very differently from C#'s garbage collecting. You have greater control, but also greater responsibility. Side note 3: Those side notes are probably not necessary, but I'm writing them just in case. :) ___ 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] Support for method overloading.
Overloading could easily be supported with mandatory cname or csuffix attributes; that an explicit name needs to be given for C is no reason that it needs to be given for vala which could do regular overloading. I think it ought to be supported. Sam -Original Message- From: Jiří Zárevúcky Sent: 08 January 2010 15:25 To: Fabzter Cc: vala-list@gnome.org Subject: Re: [Vala] Support for method overloading. Fabzter píše v Čt 07. 01. 2010 v 16:01 -0600: > Hi. I have been playing with Vala for some months. I find it to be a really > cool language, thus, I'm thinking in porting an medium sized personal > project from C# to Vala, but it relies heavyly on method and constructor > overloading, and having this features in Vala would make my refactoring work > minimal, so I want to know if vala will ever support this features, you > know, so I can start waiting if they are planned. :) Short story: No. Long story: Vala translates to C, which doesn't support overloading. That means any overloading in Vala would mean mangling names of methods in C, which would go against one of the most significant advantages of Vala - being able to use Vala library the same way as if it was written in C. The same goes for constructors, you just need to come up with some nice names. It is also my honest belief that overloading is evil and makes programmer's work harder. Side note: Be careful with constructors, they work a bit differently in Vala, than they do in C#. Side note 2: Keep in mind that refcounting behaves very differently from C#'s garbage collecting. You have greater control, but also greater responsibility. Side note 3: Those side notes are probably not necessary, but I'm writing them just in case. :) ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Sharing a trick to use some C macros in VALA
* Feng Yu wrote, On 03/11/09 00:55: import themwith Pragmas You mean that a pragma would identify that an argument took a C type? e.g. talloc_zero(void* memctx, [argtype="typesymbol"] typesymbol); Sam On Nov 2, 2009 2:03 PM, "Sam Liddicott" <mailto:s...@liddicott.com>> wrote: To get some of these tricks to work it would be helpful to be able to pass the C type underlying the vala type as a macro parameter. I've a bug with patches that does this using typeof() to emit the C typesymbol but it doesn't meet Juerg's syntax expactations. As interfacing with c macros is topical again, does anyone have ideas on this? Sam -Original Message- From: pancake <mailto:panc...@youterm.com>> Sent: 01 November 2009 10:29 To: Yu ... ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Minor features request (about structs and enums)
Pascal lets you have a bitwise set from an enum using
Set of ENUMTYPE
Sam
-Original Message-
From: pancake
Sent: 02 November 2009 18:42
To: Vala ML
Subject: Re: [Vala] Minor features request (about structs and enums)
Michael 'Mickey' Lauer wrote:
>> Another feature that might be out of context, and I don't know if its
>> implemented but nor Google nor the people at the IRC channel have been
>> able to answer me, is enum iteration.
>>
>> foreach ((what type?) item in MyEnum) { ... }
>>
>
> That's not possible indeed. It might be handy, please open a bug ticket.
>
There's another bug report requesting a to_string () method for the
enums that will be nice to have too
I was also thinking on implementing a enumflags keyword that acts like
enum, but shift bits instead of increasing the value. so you can do:
enumflag Mode {
READ
WRITE
}
MyOpen (Mode.READ | Mode.WRITE);
What do you think about adding this new keyword? The thing will be good
when using bitflags so you dont have to use an enum hardcoding the
values in a manual way:
enum Mode {
READ=1,
WRITE=2
..4, 8, 16, 32...
}
--pancake
___
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] Sharing a trick to use some C macros in VALA
To get some of these tricks to work it would be helpful to be able to pass the C type underlying the vala type as a macro parameter. I've a bug with patches that does this using typeof() to emit the C typesymbol but it doesn't meet Juerg's syntax expactations. As interfacing with c macros is topical again, does anyone have ideas on this? Sam -Original Message- From: pancake Sent: 01 November 2009 10:29 To: Yu Feng ; vala-list@gnome.org Subject: Re: [Vala] Sharing a trick to use some C macros in VALA I was thinking few time ago to add language support to do this from vala using the offsetof() keyword. Will someone else find interesting such a keyword in vala? Like in sizeof() I was needing it to use kernel's list.h On Nov 1, 2009, at 6:00 AM, Yu Feng wrote: > Dear list, > > I found this trick today, in case it is not already dinosaur.. > > [CCode (cname="G_STRUCT_OFFSET(MyBaseClassClass, my_function)")] > extern const int MyFunctionOffset; > > basically you can call in this way any c macros that are otherwise not > directly bindable to vala, given that the return type of the macro is > known. > > > - 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 ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Hi, Is Vala what I am looking for?
* Andrés G. Aragoneses wrote, On 21/09/09 21:52: Levi Bard wrote: Would patches to create this "C#-compat" mode be accepted in Vala? If we must have this discussion yet again[0], can we at least not Thank you, I didn't know about this thread. hijack Kratos's introduction thread? 0. http://markmail.org/message/5ckczur2yox4kjan However, it seems that the thread is a bit polluted with anti-mono discussion and whatnot. Let's say the real "technical" thread starts here, where Sam proposes an "unofficial" Vala mode for C# migration: http://markmail.org/message/ct445atos6d7hv5f For the record, I wasn't actually proposing any such thing, I was noting that considerations of such a proposal would have been relevant to the topic of aiding projects ports from mono. As others have said, C# is different enough from Vala to make porting difficult, particularly as the differences are fundamental to implied runtime expectations and not just syntax. Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Working with GLib.List and memory management
* Yu Feng wrote, On 01/07/09 08:50: > On Wed, 2009-07-01 at 01:24 +0400, Кутейников Дмитрий wrote: > >> It is some sort of a bug (or a feature). Vala inserts g_object_ref in >> generated C-code after myList.prepend(myWidget); but it doesn't >> decrease ref_counter after remove. The only way is to use >> g_object_unref manually. >> > > What you said is right. But that's not the full story. > > If we look at Adi's code more carefully, myList is not a > List it is a List. vala doesn't manage a List's member. > could he have written: List myList = new List(); or var myList = new List(); to make a difference? Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Port Tomboy?
* Yu Feng wrote, On 01/07/09 08:38: > On Sat, 2009-06-27 at 14:24 +0200, Jiří Zárevúcky wrote: > >> 2009/6/27 Yu Feng : >> >>> On Sat, 2009-06-27 at 08:03 +0100, Sam Liddicott wrote: >>> >>>> 4. Port Tomboy as a show-case project port >>>> >>>> >>> 4 seems to be very fun; how large is the codebase of tomboy? >>> >>> BTW: What is the largest show-case project driven by VALA, excluding >>> vala itself? Here I am not limiting within project ported from mono. >>> >>> >> I'm not sure any "show-case port" is a good idea. The differences and >> comparison can be written down in a single document. Hi, Jiří, it's not so much what the differences and comparisons are but what work had to be done, what steps were taken, how hard it was and how long it took. It would not be a show case of converted source, but of the process required to get the port; thus helping potential future porters decide if Vala is a suitable target for porting and help Vala advocates consider if Vala could/should be changed (or tools introduced) to aid porting. >> Regardless >> the potential advantages of two directly comparable >> project, imagine what would it cause in a larger scale. gnote is >> already seen as a "good" counterpart to an "evil" project in the eyes >> of almost religionistic mono-haters and it is a denial of Tomboy's >> actual achievement. Imagine that someone would copy your original cool >> project just because he doesn't like the language. I'm sure it would >> make you angry. >> You are right that this deserves consideration. The issue I tried to raise was one of being technically prepared and I had overlooked to consider any human feelings on the matter. >> If some of the Vala community try to make it some kind of >> "replacement" to Mono platform (which itself is a stupid idea) the >> earlier noted group would immediately make it to be some kind of >> "saviour that shall release us from the hands of all evil (Mono, >> Microsoft, Novell)". That could possibly result in a complete >> alienation of Vala and Mono communities. >> >> Vala must by no means accept any role in the "struggle" (more like a >> series of irrational personal insults in my opinion) that is taking >> place between the Mono community and those who are not willing to >> accept their freedom of choice. It would only hurt the project. >> I think you are right, and that the Vala project must be kept unconnected from the politics this struggle; but when the women get the bandages and basins of water ready, it is not to join in the fight, but to be prepared for the inevitable outcome. >> .. > I agree with you. Porting for the porting's sake is nothing but harmful. > > 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? > Although you were asking Jiří, I think that porting for the sake of finding out how hard porting is would be worthwhile. Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Emitting type symbols, identifiers and type-less parameters. bugzilla 558106
* Jiří Zárevúcky wrote, On 30/06/09 15:59: > Dne 30. červen 2009 16:50 Jiří Zárevúcky napsal(a): > >> 2009/6/30 Sam Liddicott : >> >>> The question is: >>> How shall vapi files specify: >>> >>> that an argument may be any type >>> that an argument may be a non-type type, e.g. a type symbol or identifier >>> >>> Jürg has suggested CCode attributes; so we could try to wrap these examples >>> like this: >>> >>> >> I think it would be much nicer to define them simply as "pseudo-types" >> with proposed CCode arguments instead being keywords. Decorated "void" >> type is quite ugly. >> >> Or is there some reason why this isn't a good idea? >> >> > > Another thought occurred to me. CCode attributes are currently not > propagating into documentation, for the reason that they are low-level > "implementation details" that programmer should not care about. So by > actually specifying the type of information passed via attribute, we > would be breaking that presumption. Not mentioning requiring to > specially handle these special cases in the documentation, which would > in turn be ugly to read. > I would prefer to avoid ccode attributes; and we still have the choice to put the "magic" in the vapi definition, or in the caller. In the hacky patch I had provided, the vapi was typeless and the caller had to use typeof(ValaType) in order to emit the compact class C type. I think I prefer the magic to be in the vapi file, with (what you call) pseudo-types of: "typesymbol", "identifier" and "any" (I know "any" has come up before), after the fashion of python. Maybe psuedo types of number, pointer, string, class would be helpful; but here I see Jürg's point that this is taking Vala away from it's intended direction and even looks like a distraction, but it's also like a young actress suddenly becoming ashamed of her parents after getting her first film part. I also have a feeling what Jürg means when he suggests generics so that these unclean typesymbols and identifiers (although vala might emit them) don't have to appear in the pure vala code - but then how to express them in vala code? In my current typesymbol cases, the type can be inferred from the LHS of the expression, but it is also confusing that the type of a macro expression is not fixed - especially when it does a cast to a type it had as a parameter. But maybe vala could stretch to passing the type of the LHS as a function argument: class Thing new_thing = talloc_new(owner); which becomes in C struct compact_class_thing* new_thing = talloc_new(owner, struct compact_class_thing); perhaps by means of this vapi: [CCode LHS_typesymbol="1"] talloc_new(void* owner) But that would only cover this specific case, where the typesymbol is used somewhere in that vala statement. Which leads me to say that if we can accept that there is no neat way to incorporate such loose typing into vala (worse than gtype boxing!), then maybe we can just go for the quick and dirty way after all, and let projects that integrate with such API's use naked type symbols etc. After all C# also has it's un-managed code for a reason :-*( Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Emitting type symbols, identifiers and type-less parameters. bugzilla 558106
(Relating to bugzilla #558106 http://bugzilla.gnome.org/show_bug.cgi?id=558106) Jürg invited me to re-open the bug if I could find a better solution. I can't find one which I'm confident will be accepted as making sense from a language point of view. I think that the fundamental problem is that the vala doesn't make room for, or recognize, that some C API's are macro based, and therefore are in fact explicitly typeless (though usually implicitly typed). So while this is not part of the direction of vala, it is part of the direction of porting from C to vala, or even vala using some C api, and is of some definite importance in some cases. I run against these pronlems trying to port C to vala. The type-ifying of the biggest culprit printf does not get rid of typeless macros altogether. I'll give some example of the typeless-ness of C macros; however (dear reader) please understand that I'm not looking for advice in re-working these examples to work around their typeless nature, or even for belief in how real they are (although they are based on real usages). They are serving as concrete examples of this type of problem when porting legitimate C to Vala, and the need for Vala to accept vapi function definitions with typeless parameters, and for vala to be able to emit naked typesymbols and identifiers. For instance it is just not worth trying to write vapi files for samba4 until we can emit type symbols, as the talloc api requires a type symbol for about half of it's macro-based api calls. Fears that this will pollute the language can be largely set aside as it will only ever work when used against macros based C api. Examples of legitimate but problematic C: 1. type-less macros 1a. File can be int or char* : #define open(file) (typeof(file)==int)?(open_id(file)):(open_name(file)) 1b. In case that looks too unlikely, here's an example from math.h. x can be float, double or long # define signbit(x) \ (sizeof (x) == sizeof (float)\ ? __signbitf (x)\ : sizeof (x) == sizeof (double) \ ? __signbit (x) : __signbitl (x)) 2. Naked identifiers This case uses the ##paste operator to compare fields of kerberos credentials. item_name is a naked identifier that does NOT need translating from vala naming to C naming. #define CRED_ITEM_COMPARE(cred1, cred2, item_name) \ ( ( (cred1->item_name##_obtained >= CRED_CALLBACK_RESULT && \ cred2->item_name##_obtained >= CRED_CALLBACK_RESULT && \ (0 == strcmp(cred1->item_name, cred2->item_name))) ) || \ (cred1->item_name##_obtained < CRED_CALLBACK_RESULT && cred2->item_name##_obtained < CRED_CALLBACK_RESULT) ) .. if (!CRED_ITEM_COMPARE(cred1, cred2, principal)) return false; .. 3. Naked type symbols. type is the C type, and as with the patch supplied for bug 558106 does need turning from a vala type to a C type. #define get_priv_data(session, type) (type *)_get_priv_data_check(session, sizeof(type), #type) struct mydata* data = get_priv_data(session, struct mydata); Note this is not about writing new vala, but about having new vala link to old and new C. The question is: How shall vapi files specify: * that an argument may be any type * that an argument may be a non-type type, e.g. a type symbol or identifier Jürg has suggested CCode attributes; so we could try to wrap these examples like this: 1. type-less macros 1a. #define open(file) (typeof(file)==int)?(open_id(file)):(open_name(file)) becomes open([CCode untyped] void file); 1b. # define signbit(x) \ (sizeof (x) == sizeof (float)\ ? __signbitf (x)\ : sizeof (x) == sizeof (double) \ ? __signbit (x) : __signbitl (x)) becomes signbit([CCode typeclass="numeric"] void x); 2. Naked identifiers #define CRED_ITEM_COMPARE(cred1, cred2, item_name) \ ( ( (cred1->item_name##_obtained >= CRED_CALLBACK_RESULT && \ cred2->item_name##_obtained >= CRED_CALLBACK_RESULT && \ (0 == strcmp(cred1->item_name, cred2->item_name))) ) || \ (cred1->item_name##_obtained < CRED_CALLBACK_RESULT && cred2->item_name##_obtained < CRED_CALLBACK_RESULT) ) becomes CRED_ITEM_COMPARE(Credentials cred1, Credentials cred2, [CCode identifier] void item_name); 3. Naked type symbols #define get_priv_data(session, type) (type *)_get_priv_data_check(session, sizeof(type), #type) becomes get_priv_data(Session session, [CCode typesymbol] void type); Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Removal of Mono
* Jiří Zárevúcky wrote, On 29/06/09 16:00: > > There is nothing ridiculous about (most of) this discussion. I agree > this mailing list is probably not the best for it, but then no mailing > list is. > > IMO, there is nothing of value left to be said anyway, so I suppose > this thread is already dead. If someone has any more comments for > anything, post responses directly to the sender / interested parties > and not to the list, thanks. > I think Jiří is right; I merely post now to say that I had expected nothing /at all/ to be posted for months in this thread, certainly not this quantity of on-topic and off-topic content. I give my sincere apologies to placid readers for the way in which my post seems to have polluted the mailing list and raised the ire of many normally calm participants. I still cannot understands how it did so, or what must be the missing context stimulating these totally un-anticipated off-topic ill-mannered and disrespectful responses. The rest of the posts were totally relevant to vala and promoting the use of vala, and I thank those vala users who posted them. This is just another in the series of life-lessons I am trying earnestly not to learn; entitled "Don't try". Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Removal of Mono
* Levi Bard wrote, On 29/06/09 15:35: >> The "on topic" results of the thread so far are: >> > ...pretty worthless. > clearly not to the people who made them, and further down you even find one to have been worthwhile. >> automatic language conversion of C# >> The code won't compile but the syntax would be valid. >> Maybe Vala's parser could parse C# into a Vala AST which it could re-emit as >> vala code >> Maybe some perl/python tool to fix up or highlight the various constructs >> Maybe just conversion of the mono project files into an automake file >> > > FFS, this is A Bad Idea. > However you don't say what is bad about the idea, you just compare it to a worse, off-topic, idea. For some-one who is porting to Vala, a tool that did the mundane conversions would be a good tool. If many people will do a port, then such a tool is a good idea. > Maybe we could write a parser frontend for every known language in > existence, map that into Common Lisp, then re-emit it as Objective > CAML. > Then we could write another tool in [incr Tcl] to fixup or highlight > the various constructs. > ? This is off topic, except on CAML mailing list. > And then we could implement a tool to convert automake and autoconf > files into Makefiles. > automake and autoconf already do that. >> vapi/vala re-writes of some common mono dependencies >> (This would also improve the gnome eco-system) >> If these can be made available to mono again, it would support a seamless >> bottom up migration >> > > There really aren't any "common mono dependencies," except for Mono. > See, you're already adding value to the discussion, although from your attitude it's hard to tell if you are trying to be accurately helpful, or saying whatever you think will stop discussion. Maybe mod_mono (for apache) is an example of the sort of dependency I was thinking of: http://ibbie.xanga.com/686874553/item/ > If you rewrote Mono in Vala, then migrated Mono to Mono, you'd still have > Mono. > (Insert Xzibit meme here.) > I don't understand why you make this statement. No-one is suggesting this. You seem to be making nonsense suggestions in order to prove this to be the sort of thread you imagine it to be. >> Improve vala documentation (particularly to be useful for developers not >> familiar with gobject) >> > > This is actually worthwhile, although its inclusion in the list for > competitive reasons and not on its own merit is disheartening. > There is nothing competitive about it. It's not part of a "vala is better than mono" attempt or anything at all like it. > >> Port Tomboy as a show-case project port >> > There is already a project that showcases Vala in comparison to C, > C++, and C#: http://code.google.com/p/vala-benchmarks/ > Yes, but it talks about show-casing Vala. We were talking about show-casing a port to vala - i.e. show-casing the port process, not Vala or tomboy. It is of interest to see how easy it is to port something to Vala. > Can we please stop the ridiculousness now? Please? > As the ridiculousness seems to be all in your mind as you mis-interpret the entire thread and it's purpose, I don't see that we can do anything to help. I've done what I can with explanatory posts but you seem unable to grasp that the thread is merely for this: To have interested vala developers be aware to notice things that might be done in order to help mono projects move to Vala /in case a move from mono occurs/, and to consider if these things that might be done are worth doing. On-topic discussion moved faster than I thought and already 4 things which /might/ be done come to light so already. Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Removal of Mono
Michael Torrie wrote: Stupid and wasted, yes. Absolutely. But the only way to get a complete comparison that might change the "gimmicky" view of Vala would be to do a straight port of some Mono application. At least if the developer is trying to compare (however foolishly) the two development systems. It would also be instructive in comparison with the process of writing gnote in C++ A re-write of Tomboy in C (if ever) would complete the comparison table; the same project written in C, C++, Vala and Mono. Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [OT] Removal of Mono
Michael Torrie wrote: Sam Liddicott wrote: Get over what? I don't understand your attitude in this response! I merely advocated keeping a weather eye open in case we could help a migration from mono. I don't advocate that we actually DO anything. Who's we? It was meant to be vala mailing list subscribers who had in interest increasing the take-up of vala among those who are moving away from mono. But let "we" be everyone who appreciates the value of this thread. If "[we're]" not to do anything then what is the point of the post in the first place? To find out (over a period of time) what might be worthwhile and acceptable to do. I think the biggest reason for a reaction is that your post comes across as an off-topic, non-sequitur. It is definitely a non-sequitur; although I would be surprised if the evangelizing of Vala hadn't been discussed at all in the mailing list or IRC. I don't think it is off-topic, though clearly others disagree. I'm not sure what anything you said has to do with Vala really, or Vala's stated purpose. Obviously Vala developers are savvy and follow current affairs. So the post brings out something of a "huh?" reaction. Hmmm, clearly I expressed my intent badly although as many people have picked up on what I meant as have totally missed it. Along with your off-topic post, however, I don't see Vala displacing Mono. Nor do I; but I anticipate the possibility of some displaced programmers/projects. Rather I hope that Vala begins to be used more and more to develop and maintain core GTK libraries and friends (and Gnome libraries). yep. I'd rather not see Mono apps become core Gnome components. Perhaps Vala is a better fit here as well, although I prefer python (which would only be an advantage over mono because it's not encumbered by MS). As you state it's not the language that's problem (Vala is similar to C# syntactically); it's the CLR and the virtual machine that pose the problem with regards to bloat, patent minefields, etc. These are the reasons that others have for encouraging a move away from Mono. The on topic nature of this thread was to be aware of how to help those that may move away from mono to move towards vala. The on topic results of this thread are posted in another message without [OT] in the subject line. Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Removal of Mono
Raphael Bosshard wrote: I'd rather like a possibility to automatically convert (or semi-convert, with manual fixes) C# code to Vala. There are some C#/Mono libraries out there (like Banshees ListView implementation) which provide a real benefit. Right now these libraries are only available to Mono applications. In some cases it would make sense to have a 'low level' implementation. It would be nice if they were available for the whole Gnome eco-system. I hadn't considered how it would enrich gnome in general, but of course you are right, and this is one of the advantages of Vala. The "on topic" results of the thread so far are: 1. automatic language conversion of C# The code won't compile but the syntax would be valid. * Maybe Vala's parser could parse C# into a Vala AST which it could re-emit as vala code * Maybe some perl/python tool to fix up or highlight the various constructs * Maybe just conversion of the mono project files into an automake file 2. vapi/vala re-writes of some common mono dependencies (This would also improve the gnome eco-system) If these can be made available to mono again, it would support a seamless bottom up migration 3. Improve vala documentation (particularly to be useful for developers not familiar with gobject) 4. Port Tomboy as a show-case project port Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Removal of Mono
I've trimmed my response after reading Aaron Andersen's post, who expressed very neatly the issues at stake. I'm clarifying on-topic as I seem to have given Michael the wrong impression on a topic that is more politically charged than i realised. * Michael B. Trausch wrote, On 26/06/09 16:03: > Last message on-list on this topic, because *this topic does not > belong here*. I was talking about influencing the development of the vala language which does belong here. > > On Fri, 26 Jun 2009, Sam Liddicott wrote: > >> * Michael B. Trausch wrote, On 26/06/09 13:54: >> > > While Mono may be in the back of many people's minds (whether > correctly or not) is irrelevant. This list's only topic is Vala. Mono > does not relate directly to Vala, and C# only does in that Vala is > "C#-like" and potentially in the discussions of adopting certain > semantics or grammar from C#. That's what I'm taking about! There may be aspects of C# (particularly relating to interfaces) or other aspects which vala could unofficially make room for to aid a migration of C# programs if the political move from mono increases. THAT'S what I'm talking about. >> There is enough long-term noise about the removal of mono, and any >> action on this could result in an increased usage of vala. Where's the >> harm in being prepared for this? > > That makes no sense, unless you assume that Vala is only "prepared" > for a userbase of nil. The issue being raised is not whether or not Vala is prepared for any size of user base, but that we might become aware of what degree it is worth making vala "prepared" for a load of C# users with existing code, and what that preparation might be, and what preparation would be acceptable within the direction that the vala language is developing. The answer may be "none" but I don't want to presume that. > It is an evolving language that takes a fresh approach to native-code > systems with assisted memory management and no additional run-time > requirements besides already-existing libraries. yes! Pricisely because it is evolving it is worth keeping a "weather eye" open. You are making the case for this discussion being on-topic quite effectively. > That is quite an accomplishment, and dicussion which pertains to it > directly is quite welcome. If you feel that there is some manner in > which it isn't "prepared" for a particular usage, address that point > directly, not any tangents from that point. That statement is almost directly what "keep a weather eye open" meant in my original post. I was inviting those who felt that Vala might not be prepared for porting from C# to speak out, and inviting the rest to be open to notice such things as it may turn out to be particularly relevant. It was a call to spot low hanging fruit. > > Blindly changing from the CLI to something like Vala is possible, > maybe even desired, in some cases. But Vala is not intended to replace > the CLI nor the BCL (particularly the latter, since it does not have a > specialized RTL). If there is a feature that you feel is missing, > discuss that instead of "[the] removal of Mono", because that is > not-at-all relevant to Vala. nor did I bring it up, I'm not sure why you are mentioning it. The removal of mono can only be relevant to Vala if it actually happens. Until we know whether or not it will happen we cannot know whether or not it will actually be relevant to Vala, but the the degree of relevance will be governed by the degree of preparation (whether planned or incidental). Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Removal of Mono
* Michael B. Trausch wrote, On 26/06/09 13:54: > On Fri, 26 Jun 2009, Sam Liddicott wrote: > >> It may be prudent to keep a weather eye open for the removal of mono on >> the horizon. > > Wrong forum. This list is for users of Vala, not Mono trolls, no > matter how subtle. Go away, thanks. Mike, your attitude makes you look like a vala troll, contrary to what one would expect from your history on this list. It's not very flattering. Your post also makes it look like you don't know what "weather eye" means even though I provided a link for you. Alas, you being rude draws more attention to this. There is enough long-term noise about the removal of mono, and any action on this could result in an increased usage of vala. Where's the harm in being prepared for this? Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Removal of Mono
* Jiří Zárevúcky wrote, On 26/06/09 13:10: > Ah, ok, I'm sorry for my impulsive response. I may have implied a > thing or two from following parts: > no problem > Subject: Removal of Mono > -- What the hell? > true enough; it was the theme for a set of posts I'd been reading about Gnome and vala, with a timeline 2 years or more and it got me thinking. > "It may be prudent to keep a weather eye open for the removal of mono on > the horizon." > -- As with the subject, this implies you want Mono removed. > I see how this confusion occurs. I was recognizing that many people do want it removed; intimating that it might be an advantage if we (vala) were prepared. I see that some-one is re-writing tomboy in C++ as gnote - why they aren't using Vala is puzzling - probably they never heard of vala. The effort of a re-write and the effort of naked gnome in C/C++ seem like a waste of effort. Surely gnome vala is better than gnome C++, and surely vala is closer in syntax and language feature to C# than to C++; and this is perhaps evident in that gnote still lacks many tomboy features. The C# is a template for the C++, and if the C# were mechanistically converted to vala, the results merely lacking a few fixups it may be quicker to get the conversion with all the features. > "Sure, we don't want Vala spoiling by mono" > -- This, on the other hand, implies you consider Mono as something bad > that would spoil Vala. > I was trying to pre-empt what Juergbi would say (or has said in response to some of my patches!) and make clear that the suggestion was not to have vala compile C# > "I'm not advocating the vala be able to compile C# code" > -- You're suggesting it. Otherwise you would mention that possibility at all. > > I mentioned it in order to avoid that discussion (fail fail!). I wanted to avoid the conversation being about a C# mode for Vala or the corruption of Vala in order to bring in features which are adequately dealt with already in C# or other langauges. > Along with that, Vala and C# are different languages with different > principles and different target audiences. People wanting to switch > just for the purpose of not using Mono logically must be either stupid > or mono-haters. > > or politically wary; don't forget the background of the whole free-software movement. Of course the politically wary are often called stupid, but I prefer the word wary. It's a way of managing perceived risk, and if people doing that will switch to Vala then I think it is good news on this mailing list. I am personally wary of mono because I am wary of MS who have a history of scheming. However the issue that stimulated my post is the number of other people who feel the same way and who do advocate the removal of mono (hence the post title) - and that I would rather they moved to vala than to C/C++ if they are going to move at all. Hence "keep a weather eye" > Anyway. With the kind of things those anti-mono guys are writing > lately, I may have switched into an "anti-anti-mono" mode a bit too > early. Sorry about that. Just shows how these people spread hate among > peaceful guys like me. :) > heh - looks like I was reading the same stuff as you. It is true that people often exchange their opinion with the point of convergence of similar opinion; e.g. replace wariness of mono with being anti-mono from a political stance; or replace wariness of Novell with being anti-mono from an anti-Novell stance. I'm just trying to help Vala get some benefit from this atmosphere of disquiet. > Regarding your original post, there is really nothing to "keep a > weather eye open" related to Mono. You can just look forward to a > stable version and see it mature. > No doubt this is right as far as mono goes; I meant in relation to a migration from mono, perhaps in relation to the gnome project. I believe that if Vala was around before mono, mono would not exist. I do prefer vala vastly to mono. I think it needs better memory management, but it has been tied to gnome's memory management and I think it has incorporated that very well. So I said a lot more that I was trying to say, having clarified things through the discussion I was trying to avoid... thanks for speaking up, there is no offence taken, I think it was worthwhile. regards, Sam > Dne 26. červen 2009 13:48 Sam Liddicott napsal(a): > >> * Jiří Zárevúcky wrote, On 26/06/09 12:28: >> >>> Ah, another one of the anti-mono guys. Sigh... >>> >>> >> Ah, another one of those guys who sees anti-mono guys everywhere. >> >> >>> Let me tell you, that from the sole principle of how Vala works, it >>> will never be possible to convert C# code in a mec
Re: [Vala] Removal of Mono
* Jiří Zárevúcky wrote, On 26/06/09 12:28: > Ah, another one of the anti-mono guys. Sigh... > Ah, another one of those guys who sees anti-mono guys everywhere. > Let me tell you, that from the sole principle of how Vala works, it > will never be possible to convert C# code in a mechanistic fashion. > Of course it will, it just won't compile or run. > You could maybe try creating some sort of automatic converter, which > wouldn't work anyway, as it would result in a lot of bugs, inferior > performance and (in better case) memory leaks. You could try this too. I think I'll wait to see if there is a need. > Just the possibility of > "Vala being able to compile C# code" is so ridiculous I wonder who > came up with that. > I've never heard the idea suggested, and I didn't suggest it. It seems you are the one who came up with it. I wish you had read my message. In it I acknowledged some of these points. I think you read the message you thought I had written. But there will be some language features of C# which are not within the vala philosphy or language direction but which might be supported and thus making some migration easier; I merely suggest keeping an open eye for these. I don't expect any mechanistically converted C# to "compile and work" with Vala, but it could be valid vala, with the parts that need re-working annotated. > Anyway. Why hating Mono? I don't hate mono (although I prefer Vala). I wrote a nice mono application for controlling my USB experimenter board. > Mono is a great software platform and people > will use it no matter what MS-haters say about it. Good for them. (And me, I'm one of them). > Get over it people. > Get over what? I don't understand your attitude in this response! I merely advocated keeping a weather eye open in case we could help a migration from mono. I don't advocate that we actually DO anything. Sam > 2009/6/26 Sam Liddicott : > >> It may be prudent to keep a weather eye open for the removal of mono on >> the horizon. >> >> Vala is excellent, and I prefer it to mono; however it may become >> pricelessly important that mono code can be converted to vala in a >> mechanistic fashion. >> I'm talking about language features, not library dependencies and linkages. >> >> Sure, we don't want Vala spoiling by mono, and I'm not advocating the >> vala be able to compile C# code; I'm not advocating anything specific... >> >> ..just to keep a weather eye open... >> >> [http://en.wiktionary.org/wiki/keep_a_weather_eye_open] >> >> Sam >> ___ >> 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] Removal of Mono
It may be prudent to keep a weather eye open for the removal of mono on the horizon. Vala is excellent, and I prefer it to mono; however it may become pricelessly important that mono code can be converted to vala in a mechanistic fashion. I'm talking about language features, not library dependencies and linkages. Sure, we don't want Vala spoiling by mono, and I'm not advocating the vala be able to compile C# code; I'm not advocating anything specific... ..just to keep a weather eye open... [http://en.wiktionary.org/wiki/keep_a_weather_eye_open] Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] malloc/free CCode attributes
* Arc Riley wrote, On 24/06/09 17:55:
> While don't you write an example of what your proposal would look like
> to the list? I honestly don't understand how your proposed solution
> would work for non-gobject bindings.
Off my head, with possibly wrong syntax, possibly abuse of abstract in
interfaces:
*/* somewhere in the bowels of vala */*
*interface* IManagedMemory {
*abstract* void ref_function();
*abstract* void unref_function();
*abstract static *void* alloc_function(int size);
*abstract* void free_function();
}
*/* in the vapi for my python-ish object */*
*interface* IPythonManagedMemory : IManagedMemory {
void ref_function() { Py_IncRef(this); }
void unref_function() { Py_DecRef(this); }
void* alloc_function(int size) { return PyObject_Malloc(size) }
void free_function() { PyObject_Free(this); }
}
[Compact]
[CCode (lower_case_cprefix = "PyObject_"]
public class Object : IPythonManagedMemory {
..
When the code generator wants to do any memory management operations, it
casts to IManagedMemory (if it can) and then goes with that. Shame there
is no IInterface to be involved as a cast helper, as with Microsofts
interface model, but a way around this deficiency is to have an
implementation if IManagedMemory which makes calls to the memory
management library I referred to which tracks the allocating module
based on the pointer value, so that the right referencer/de-referencer
can be called.
That way python could create a bitmap, or libgd could create a bitmap
and as long as they both used the memory management mallocer, it would
always know based on pointer value who it belonged to.
Sam
>
>
> On Wed, Jun 24, 2009 at 12:38 PM, Sam Liddicott <mailto:s...@liddicott.com>> wrote:
>
> Yes, but it is much cleaner and nicer to express it as an
> interface than a bunch of ccode attributes.
>
> And not all structs of the same type are allocated by the same
> subsystem or want freeing with the same free function.
>
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] malloc/free CCode attributes
Yes, but it is much cleaner and nicer to express it as an interface than a
bunch of ccode attributes.
And not all structs of the same type are allocated by the same subsystem or
want freeing with the same free function.
Sam
Sam
-Original Message-
From: Arc Riley
Sent: 24 June 2009 07:23
To: vala-list
Subject: Re: [Vala] malloc/free CCode attributes
I may not be understanding you correctly, but an interface is a gobject
mechanic. This is intended as a quick and simple mechanism for non-gobject
library bindings.
Free shouldn't actually be needed, since that's handled by the specified
unref_function, but something as simple as:
[Compact]
[CCode (lower_case_cprefix = "PyObject_",
ref_function = "Py_IncRef",
ref_function_void = true,
unref_function = "Py_DecRef",
new_function = "PyObject_Malloc")]
public class Object {
Like ref_function and unref_function, it's just a drop-in replacement for the
memory allocation function Vala would otherwise use which doesn't work with
some bindings as they use their own internal memory management.
On Thu, Jun 18, 2009 at 4:03 AM, Sam Liddicott wrote:
I've given this a lot of thought.
Here's some ideas:
A memory management interface which implements these. A class implements the
interface with it's own specific management.
This would be better done by late binding, the microsoft way, where the object
supports IInterface so it can be queried for a complete memory management
interface.
As this isn't likely to be magically compatible with what we have now; I have
another solution; based on a tree of memory allocation pools.
Any allocation of memory (or super allocation) is registered with the memory
pool library. It is then possible to call find_allocation(void* ptr) and be
returned the management interface for that pointer.
It may be easier if a library will mmap memory it allocates, it become a
matter of checking which range of mmap'd memory the pointer lies between.
Thus it will be easy to get the memory management interface associated with a
pointer.
Sam
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] malloc/free CCode attributes
* Arc Riley wrote, On 18/06/09 00:20:
> It would be extremely helpful in developing bindings for other object
> systems if the glib's memory management could be overridden, ie;
>
> [Compact]
> [CCode (lower_case_cprefix = "PyObject_",
> ref_function = "Py_IncRef",
> ref_function_void = true,
> unref_function = "Py_DecRef",
> alloc_function = "PyObject_Malloc",
> free_function = "PyObject_Free")]
> public class Object {
> ...
>
> Thoughts?
I've given this a lot of thought.
Here's some ideas:
A memory management interface which implements these. A class implements
the interface with it's own specific management.
This would be better done by late binding, the microsoft way, where the
object supports IInterface so it can be queried for a complete memory
management interface.
As this isn't likely to be magically compatible with what we have now; I
have another solution; based on a tree of memory allocation pools.
Any allocation of memory (or super allocation) is registered with the
memory pool library. It is then possible to call find_allocation(void*
ptr) and be returned the management interface for that pointer.
It may be easier if a library will mmap memory it allocates, it become a
matter of checking which range of mmap'd memory the pointer lies between.
Thus it will be easy to get the memory management interface associated
with a pointer.
Sam
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Val(a)IDE 0.5 - IDE for Vala
* Nicolas Joseph wrote, On 12/06/09 12:11: > 2009/6/12 Andre "Osku" Schmidt : > > >> in (at least) ubuntu9.04 /bin/sh -> dash, and as dash seems to give that >> "[[:" not found error, it would be probably worth to note that "bash >> apply_patches.sh" doesn't give that error. >> >> > > What is your shell ? [ is an alias for "test" program. > > The shell is dash, but [[ is a bash-ism. Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Problem converting library
You could try running the headerfile through the C pre-processor first (gcc -E)
with any required includes so you expand out special declaration macros.
Sam
-Original Message-
From: Nicolas
Sent: 15 May 2009 19:12
To: vala-list@gnome.org
Subject: [Vala] Problem converting library
Hi,
I'm trying to port a non Glib library, and i have some problems.
For example, when vala-gen-introspect try to convert this:
GAULFUNC population *ga_genesis_integer( const int
population_size,
const int num_chromo,
const int len_chromo,
GAgeneration_hook generation_hook,(!!!
this is the line 507 !!!)
GAiteration_hookiteration_hook,
GAdata_destructor data_destructor,
GAdata_ref_incrementor data_ref_incrementor,
GAevaluate evaluate,
GAseed seed,
GAadapt adapt,
GAselect_oneselect_one,
GAselect_twoselect_two,
GAmutatemutate,
GAcrossover crossover,
GAreplace replace,
vpointeruserdata );
It return:
/usr/local/include/gaul.h:507: syntax error, unexpected identifier
/usr/local/include/gaul.h:509: syntax error, unexpected typedef-name,
expecting identifier or '(' or '*'
/usr/local/include/gaul.h:510: syntax error, unexpected identifier,
expecting ',' or ';'
/usr/local/include/gaul.h:512: syntax error, unexpected typedef-name,
expecting identifier or '(' or '*'
/usr/local/include/gaul.h:513: syntax error, unexpected typedef-name,
expecting identifier or '(' or '*'
/usr/local/include/gaul.h:514: syntax error, unexpected typedef-name,
expecting identifier or '(' or '*'
/usr/local/include/gaul.h:515: syntax error, unexpected typedef-name,
expecting identifier or '(' or '*'
/usr/local/include/gaul.h:516: syntax error, unexpected typedef-name,
expecting identifier or '(' or '*'
/usr/local/include/gaul.h:517: syntax error, unexpected typedef-name,
expecting identifier or '(' or '*'
/usr/local/include/gaul.h:518: syntax error, unexpected typedef-name,
expecting identifier or '(' or '*'
Do you know what can i do to resolve this problem ?
Thanks in advance to everyone who can help me.
Nicolas.
___
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] Listing directory content with GIO
Yeah... Nicer to be implicit though.
Sam
-Original Message-
From: Levi Bard Sent: Wednesday, May 06, 2009 7:48 PM
To: Sam Liddicott
Subject: Re: [Vala] Listing directory content with GIO
On Wed, May 6, 2009 at 2:42 PM, Sam Liddicott wrote:
> I prefer:
>
> while ((FileInfo fileinfo = enumerator.next_file(null)) != null)
> {
> stdout.printf("%s\n", fileinfo.get_name());
> }
>
> Which allows you to have a fake scope surrounding the loop to keep the loop
> variable temporary to the loop.
>
> I don't know any language that likes it though :-(
{
FileInfo fileinfo;
while(null != (fileinfo = enumerator.next_file(null)))
{
// stuff
}
}// ?
--
http://homes.eff.org/~barlow/EconomyOfIdeas.html
http://www.dreamsongs.com/MobSoftware.html
http://www.gnu.org/philosophy/shouldbefree.html
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Listing directory content with GIO
I prefer:
while ((FileInfo fileinfo = enumerator.next_file(null)) != null)
{
stdout.printf("%s\n", fileinfo.get_name());
}
Which allows you to have a fake scope surrounding the loop to keep the loop
variable temporary to the loop.
I don't know any language that likes it though :-(
Sam
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] why this new and innovative programming language called Vala?
Philip Van Hoof wrote: Jürg has denied it, but we all know that secretly Jürg is a big fan and stalker of Vala Mal Doran. Another reason is the French word voila. As in "Voila! That's how you do it!" We'll never know, Jürg has so far denied any guess we made at conferences and meetings. Which means that Vala comes from Vala Mal Doran. I mean, woah! My guess is from Tolkein: http://en.wikipedia.org/wiki/Vala_(Middle-earth) A Vala is ancient but powerful. Vala is C but with all the good bits. Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] shortcut: Better co-routine support with fibers
Michael 'Mickey' Lauer wrote: Sam, this is exciting stuff, I'd love to see this in Vala. aye! I got it working in samba yesterday. I had a function that used LOADS of variables and was quite long and complicated and I really didn't want to break it up into composite parts sharing common structures. Using libpcl I just started it off on another stack, and everytime I had to wait on an async call, I did something like this: req = client_async_req_send(); req->callback.fn = co_call; req->callback.data = co_current(); /* yield to main process stack */ co_resume(); status = receive_result(req); Samba has it's own libtevent based message loop, but this code doesn't "know" about that, it just provides a callback address called by Samba's event loop. My team and I are working on the Vala-reimplementation of the freesmartphone.org mobile phone middleware, which makes heavy usage of asynchronous dbus on server side. cool. What phone do you have? I've got an HTC universal but have about given up on it. It's a shame because the size and weight and keyboard and screen and double cameras are perfect. It just needs more RAM, GPS and a newer WLAN to be better than the T1 in every way! And there's even a slot on the board for GPS! AGGGHGHG I also like the LG Versa, although the keyboard layout ought to earn someone a smack, but sadly it seems to run LG-freakos instead of WM or Linux. One of the two things holding further work back is the lack of dbus error marshalling and server side async dbus support, the latter preferably with coroutines, since it makes parsing the control flow so much better than with dozens of callbacks. Well libpcl is nearly as portable as linux pthreads. The only thing I think it needs is the ability to use mmap'd stacks so the RAM is only committed as it is used, then it becomes efficient to over-allocate a stack "in case". Sam With this method, "yield" will switch back to the main context, and should only be called from a co-routine context. Something must generate the co-routine instance. In samba it happens explicitly when the function consciously decides to defer execution of a specific task, but I'm not sure if this carries over well to some vala examples where yield might be used during io selection and so forth. In Python it also happens explicitly -- I don't see a way around this and as far as I'm concerned, I think explicitly is better for clarity. :M: ___ 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] Autocasting for lambdas
* pancake wrote, On 23/04/09 10:33:
> It is possible to reduce this code?
>
> gw.graph.nodes.sort(
> (a,b) => {
> Grava.Node *na = a;
> Grava.Node *nb = b;
> return (int)(na->y - nb->y);
> }
> );
>
I don't think you can do this, but try it - it would be nice if it would
work:
gw.graph.nodes.sort(
(Grava.Node *a, Grava.Node *b) => {
return (int)(a->y - b->y);
}
);
It certainly matches the non-lambda way of doing it (which in C might
require a cast of the function pointer).
Sam
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] libpcl - was Re: shortcut: Better co-routine support with fibers
libpcl is partly based on earlier coroutine work and the GNU Pthread
library and seems complete and up to date (although libcoro seems to
have some work-arounds for Irix that libpcl doesn't have)
So I'm doing some experiments with libpcl
For anyone who wants to play, the source is available from:
http://www.xmailserver.org/pcl-1.6.tar.gz
If you copy the source to /usr/src/redhat/SOURCES (adjust for your
configuration) you can build rpms with this spec file:
http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/~checkout~/SPECS/libpcl.spec?rev=1.4;content-type=text%2Fplain
rpmbuild -ba libpcl.spec
Although I had to add this line at the end of the %install section
rm -f "$RPM_BUILD_ROOT"/%{_libdir}/libpcl.so.1
to avoid complaints about libpcl.so.1
Sam
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] shortcut: Better co-routine support with fibers
Some of you know I've been wanting the coroutine/continuation support for better async handlers in Samba. I've just read Ralf Engelschall's seminal "Portable Multithreading" paper, which led to GNU Pthreads, and realised that he has enough in there to do proper portable coroutine support in vala without dependencies on particular event driven frameworks. Rather than needing vala to declaring continuation structs to hold automatic variables (which doesn't entirely solve the problem), it works by allocating a new stack context from that point, which of course automatically holds all automatic variable. If the stack is allocated with mmap specifying that the region is to be allocated as it is used, then we can be memory efficient without having to worry about running out of stack. As useful starting points I suggest: libcoro - coroutines using Ralphs methods http://software.schmorp.de/pkg/libcoro.html coroutine usage based on libcoro - Jurg may be familiar with this one http://felipec.wordpress.com/2008/09/28/continuations-in-c-easy-asynchronous-stuff/ Bug asking for fibers in GLib, mentioning the above two links http://bugzilla.gnome.org/show_bug.cgi?id=565501 Libfiber - simple fiber library http://www.rkeene.org/projects/info/wiki/22 PhuckThreads - thin skin around Ralph Engelschall's examples https://lunastorm.dyndns.org/svn/PhuckThreads/ Implementing a thread library - See makecontext and longjmp implementations http://evanjones.ca/software/threading.html Windows setcontext stuff in case we need it http://www.codeproject.com/KB/threads/ucontext.aspx Of course we don't want a thread library, but coroutines are pretty much directly scheduled fibres. To continue a co-routine, just call sched_thread(thread_stack_ptr) - which nicely requires calling a function that takes a single pointer - something compatible with most callback types. I'll be trying something like this on Samba and I expect it to be straightforward, but not quite so simple for Vala, unless Vala intends to support fibers? With this method, "yield" will switch back to the main context, and should only be called from a co-routine context. Something must generate the co-routine instance. In samba it happens explicitly when the function consciously decides to defer execution of a specific task, but I'm not sure if this carries over well to some vala examples where yield might be used during io selection and so forth. I haven't seen any vala examples where a corouting instance is generated. I hope someone knows what I'm talking about and speaks out. Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Optional output parameters?
Although my suggestion was clearly obscene from a coding point of view I think it ought to have worked. It ought to be possible to pass an dereferenced pointer as an out. Maybe vala rejected it because it was an expression. Try putting the expression in the line before and storing the result in an int* tmp and then passing *tmp. If that doesn't work then it is a vala bug IMHO. Sam -Original Message- From: Jan Hudec Sent: Friday, April 10, 2009 5:39 PM To: vala-list@gnome.org Subject: Re: [Vala] Optional output parameters? Sam Liddicott writes: > > The expression of an out parameter must be an LHS (left hand side) assigment. > > You can try > > *(condition?&inh:(inh_type*)NULL) > > You'll have to fill inh_type with thr right type Tried: *(true?&inh:(int *)null) Gives me an error: error: Cannot pass value to reference or output parameter With out modifier before: error: ref and out method arguments can only be used with fields, parameters, and local variables Without *: error: Argument 7: Cannot convert from `int*' to `int' And the same errors when I replace the expression by pointer variable. I also tried nullable variable, which compiled, but does not do what I want, because the generated C code creates a new temporary and passes in the pointer to that, independent on the old value of the nullable variable. ___ 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] Optional output parameters?
The expression of an out parameter must be an LHS (left hand side) assigment. You can try *(condition?&inh:(inh_type*)NULL) You'll have to fill inh_type with thr right type Sam -Original Message- From: Jan Hudec Sent: 09 April 2009 20:10 To: vala-list@gnome.org Subject: [Vala] Optional output parameters? Hello Folks, I want to use the Glib.Process.spawn_async_with_pipes (g_spawn_async_with_pipes) function. It has three output parameters through which is passes back pipes it connected to the newly created process' stdin, stdout and stderr respectively. The underlying function will not create the pipes if the respective pointer is NULL. Now that would be OK, if whether it will need the handler or not didn't depend on an argument of the calling function. I want to construct a conditional expression (to avoid having four calls to the spawn_async_with_pipes), that will pass either pointer to the variable or NULL, but I am out of guesses. I tried various things like: condition ? out inh : null out condition ? inh : null out (condition ? inh : null) ??? and always got either "incompatible expressions" or "syntax error" errors. Thanks, Jan ___ 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] Idea: Change escaped comments to Logger calls
I find thay my debug statements are more helpful that my comments; my comments
explain what I'm trying to do, by debug statements explain what is being done
and why.
Debug stataments by definition and out of necessity help one understand the
code flow.
But why not just write a debug statement instead of a special comment? It's the
care in crafting a debug statement that makes it so useful.
Sam
-Original Message-
From: Endi
Sent: 05 April 2009 03:04
To: vala-list@gnome.org
Subject: [Vala] Idea: Change escaped comments to Logger calls
Usually a programmer writes comments about what the next few code lines will
do. When something goes wrong, stdout.print() or Glib.debug() lines are also
inserted for debug purposes:
// Opening a file
Glib.debug("Opening a file");
..
code block
..
It isnt a good thing document something twice, so I advise the following syntax
for this:
//$ Opening a file
..
code block
..
Then in C, the comment line would change to:
g_debug("Opening a file");
Other suggestions:
//$ = //$D = Debug
//$W = warning
.. and so on
I used the "$" character there, because it reminds me to the bash prompt (where
the messages will be shown), but anything goes.
People would really use it and like it, because it is much more handy than
stdout.print an the others. IDEs could show these with different colors (like
comments), so logger calls could separate from valuable code.
What do you think, is this a good idea?
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Creating executables without glib/gobject
-Original Message- From: JustFillBug Sent: 14 March 2009 06:00 To: vala-list@gnome.org Subject: Re: [Vala] Creating executables without glib/gobject >This is crazy. If go down this path, people will eventually reinvent >glib at the end. Maybe. But glib wil never get linked into the kernel. Or grub. And no-one will recreate glib - but maybe many people will create bits of it as they need... Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Replacing "void method ( out Type)" with "Type method()"
You can write small functions in the vapi file;. Sam -Original Message- From: Adi Roiban Sent: Wednesday, March 11, 2009 9:20 PM To: vala-list@gnome.org Subject: [Vala] Replacing "void method ( out Type)" with "Type method()" ... Now I could rename the Gtk.TextBuffer class in the gtk+ VAPI file and implement my own Gtk.TextBuffer class inheriting the renamed class. Is there a way to modify a VAPI file to fix this problem and give us this syntactic sugaring ? Maybe there is a way to write small functions inside a VAPI file for helping VALA with the code generation. Many thanks! -- Adi Roiban ___ 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] Creating executables without glib/gobject
* Andrea Bolognani wrote, On 11/03/09 11:12: > On Wed, 11 Mar 2009 17:46:06 +0800 > Barry Kauler wrote: > > >> #define G_BEGIN_DECLS >> #define G_END_DECLS >> > > I can't answer your question, but I'd like to point out that G_BEGIN_DECLS > and G_END_DECLS, as the names suggest, are supposed to be before and after > the declarations respectively. > > So you should move G_END_DECLS to the end of your glib.h. > He's #define'ing them to nothing, not using them :-) He's making a fake glib.h to get rid of all the glib extra stuff that vala insists on emitting. Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Coroutines / async methods - info needed for talk
* Frederik wrote, On 11/03/09 10:38:
> Sam Liddicott wrote:
>
>> I've come up with this Vala example to help me see what is going on:
>>
>> using GLib;
>>
>> int foo (int y) yields {
>> int x;
>> x=1;
>> message ("hello");
>> yield;
>> y=2;
>> message ("world");
>> yield;
>> y=3;
>> message ("thats all folks");
>> return 5;
>> }
>>
>> void main () {
>> foo.begin (0);
>> message ("vala");
>>
>> var loop = new MainLoop (null, false);
>> loop.run ();
>> }
>>
>
> Does this compile for you? For me it doesn't (latest Vala from git):
>
Me too, and I don't even know if it is because the vala is invalid
because I can't find clearer examples or instructions.
> async.c: In function 'foo':
> async.c:32: error: 'data' undeclared (first use in this function)
> async.c:32: error: (Each undeclared identifier is reported only once
> async.c:32: error: for each function it appears in.)
> async.c:35: error: case label not within a switch statement
> async.c:41: error: case label not within a switch statement
> async.c: In function 'foo_co':
> async.c:83: error: 'x' undeclared (first use in this function)
> async.c:89: error: 'y' undeclared (first use in this function)
> error: cc exited with status 256
> Compilation failed: 1 error(s), 0 warning(s)
>
Yeah, but it can still be instructive to look at the generated C - but
not only does it not compile, it looks wrong too, when you try and make
sense of the C - and I don't just mean the stepped switch/case statement
in foo_co which looks abominable and surely will interleave badly with
any vala case statements.
Sam
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Coroutines / async methods - info needed for talk
I've been accepted to give a talk at in April SambaXP 2009 on the topic
of programming Samba with Vala. The focus will particularly be on how
co-routines can simplify async programming.
It would help me very much if I was able to find out a little more on
the plans for co-routines/async method implementation of which it was
said recently that they were not a priority for Vala 0.6; and for which
little information or examples are available.
In this message I show what I've been able to find out - which I suspect
is not very complete - and then talk again about my hopes for vala
coroutines.
Specifically I'm interested in the various ways the "yield" keyword may
be used, and if/how continuations based on explicit callbacks rather
than events in a compliant event loop can be managed - or how firm Jürg
is that only gnome async programming should be supported.
I've come up with this Vala example to help me see what is going on:
using GLib;
int foo (int y) yields {
int x;
x=1;
message ("hello");
yield;
y=2;
message ("world");
yield;
y=3;
message ("thats all folks");
return 5;
}
void main () {
foo.begin (0);
message ("vala");
var loop = new MainLoop (null, false);
loop.run ();
}
But I think there is more that can be done, if only I knew what, and
what the underlying limits were.
I don't like the fact that foo.begin is required in the vala, but I
think that's a gnome thing and I can live with it (I was expecting that
any function that contains async-ish keywords would be generated the
async way, and that when called the async initialising entry point would
be used - but that's fine.
(I hope that a static class/interface can be provided for the underlying
async model so that rather than g_slice_new0 and
g_simple_async_result_new etc being emitted in the C code everywhere
there is vala-time control over the names of the functions that do these
generic operations, so that other async models can be supported)
Also, consider the generated C:
static gboolean foo_co (FooData* data) {
switch (data->state) {
I suggest instead explicit callback entry points:
static gboolean foo_co_1 (FooData* data) {
data->state=1;
return foo_co(data);
}
..so that continuation addresses can be passed to libraries accepting a
callback function address.
Jürg, what are your feelings on this and how this would be expressed in
vala. I've suggested a few notations in the past.
Sam
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Confused with valagenieparser & valaparser
* Yu Feng wrote, On 25/02/09 06:24: I am working on a patch to allow typeof(expr) [bug 583075]. The two parsers in vala/, namely genieparser & parser confuse me a lot. What is the difference between them? Which file should I patch? I don't find bug 583075 in bugzilla, but I do find: http://bugzilla.gnome.org/show_bug.cgi?id=558106 which has a patch attached to do something similar. Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [Having fun with Vala] Multiboot kernel using Vala!
I wouldn't want to use glib, which was the point of my post. Sam -Original Message- From: Michael Torrie Sent: 14 February 2009 21:31 Cc: vala-list Subject: Re: [Vala] [Having fun with Vala] Multiboot kernel using Vala! Sam Liddicott wrote: > I think that is great. > > I'm determined to write a netfilter kernel module in vala. Can kernel modules link to glib? Seems like that would be needed for any features of vala. I guess you could statically link glib. But what about if you have 2 modules written in vala? Can they coexist in kernel space? Any global structures created by glib would tend to be a problem in this case. ___ 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] [Having fun with Vala] Multiboot kernel using Vala!
* Yu Feng wrote, On 11/02/09 16:35: Hi Matias, I am curious about how GLib was staticly linked to your kernel. I didn't see any flags on this in your makefile. Yu On Mon, 2009-02-09 at 12:45 -0200, Matías De la Puente wrote: Hello all!, I was playing with vala to see if it's posible to write a minimal kernel using vala. Based in the multiboot sample (http://www.gnu.org/software/grub/manual/multiboot/html_node/Example-OS-code.html), I was able to wrote a minimal multiboot kernel in vala. ;) I wrote a multiboot binding and a video binding for displaying the information.. In the attachment there's the code and a iso file to use with an emulator, I use: qemu -m 8 -cdrom cdrom.iso For compiling the code you need nasm, gcc, vala and genisoimage. Use make cdrom.iso to build the image of the iso You can download the code from here: http://sites.google.com/site/mfpuentear/Home/multiboot-vala.tar.bz2?attredirects=0 Have fun ;) Matias ___ 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-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] vala gnome integration
* Zeeshan Ali (Khattak) wrote, On 13/02/09 12:01: Hi! On Fri, Feb 13, 2009 at 10:44 AM, Sam Liddicott wrote: It often troubles me how tightly vala is bound to glib. Of course this isn't a fault, as such, because vala is designed for writing glib applications - but I want to use it for writing samba modules and kernel modules which don't (and won't) use glib. Dude! you are using vala for writing kernel modules? er... it's on my plans. I do have a half conversion of the samab4 vfs cifs module to vala. Seriously, I wouldn't advice that. Vala is still in it's infancy to be taken so far unless you are really eager to contribute lots of patches to Vala that will extend it in the ways you want/need it to be. I have some patches against vala 0.4* to improve compact class support. I'm effectively using vala as a powerful C pre-processor - I check that it generates the C I ought to have been writing, but enjoy writing vala. However I've not had time to touch vala since the summer, sadly. Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] vala gnome integration
It often troubles me how tightly vala is bound to glib. Of course this isn't a fault, as such, because vala is designed for writing glib applications - but I want to use it for writing samba modules and kernel modules which don't (and won't) use glib. Right now I have a fake glib.h which defines many glib items to be normal. Clearly some of the defines below e.g. g_slice_new0 becomes talloc_zero are specific to me; but I think I would rather vala either: 1. generated more generic calls like: vala_alloc0 and such like, having a macro file to convert these for glib or 2. used different target definitions so that a generated c file might make use of different primitives according to the target chosen when the vala file was compiled; and include another base header file instead of glib.h Below are the definitions I'm using on vala 0.4x to compile a samba module. #define G_END_DECLS #define gint int #define gboolean bool #define gpointer void* #define FALSE false #define TRUE true #define g_slice_new0(A) talloc_zero(NULL,A) #define g_slice_free(A,V) talloc_free(V) #define g_return_if_fail(expr) #define g_return_val_if_fail(expr,value) #define g_type_class_peek_parent(x) NULL // for structs that can't have a free_function yet #define g_free(x) talloc_unref(x) ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] How to wrap select(2)'s fd_set?
* Michael 'Mickey' Lauer wrote, On 12/02/09 12:39:
Am Thursday 05 February 2009 17:27:52 schrieb Sam Liddicott:
Anything we can do about that or just give in and leaving FdSet a full
class?
use memset ?
Heh, right. Will you try to get the patch into the respective c
libraries?
I thought we were talking about vapi files. Something like
[Compact]
public class FdSet
{
[CCode (cheader_filename = "string.h")]
public void zero () {
memset(this, 0, sizeof(this));
}
But I suppose you could also call FD_ZERO from the body too...
Oh amazing! It didn't occur to me that vala code is allowed in vapi files :)
Juergbi has it define a static function in each C file that uses it, but
*I* think it should define a C macro in the header file... I know just
saying that made Juergbu feel sick...
Sam
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [Having fun with Vala] Multiboot kernel using Vala!
* Yu Feng wrote, On 11/02/09 16:35: Hi Matias, I am curious about how GLib was staticly linked to your kernel. I didn't see any flags on this in your makefile. I figured he wasn't using GLib or libc. He doesn't use any glib stuff, printf is provided by grub Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [Having fun with Vala] Multiboot kernel using Vala!
I think that is great. I'm determined to write a netfilter kernel module in vala. Sam * Matías De la Puente wrote, On 09/02/09 14:45: Hello all!, I was playing with vala to see if it's posible to write a minimal kernel using vala. Based in the multiboot sample (http://www.gnu.org/software/grub/manual/multiboot/html_node/Example-OS-code.html), I was able to wrote a minimal multiboot kernel in vala. ;) I wrote a multiboot binding and a video binding for displaying the information.. In the attachment there's the code and a iso file to use with an emulator, I use: qemu -m 8 -cdrom cdrom.iso For compiling the code you need nasm, gcc, vala and genisoimage. Use make cdrom.iso to build the image of the iso You can download the code from here: http://sites.google.com/site/mfpuentear/Home/multiboot-vala.tar.bz2?attredirects=0 ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] How to wrap select(2)'s fd_set?
* Michael 'Mickey' Lauer wrote, On 05/02/09 15:39:
Am Thursday 05 February 2009 15:03:57 schrieb Sam Liddicott:
Ok, I now found out:
FD_ZERO is defined as __FD_ZERO which in turn is defined as:
/* We don't use `memset' because this would require a prototype and
the array isn't too big. */
#define __FD_ZERO(s) \
do { \
unsigned int __i; \
fd_set *__arr = (s); \
for (__i = 0; __i < sizeof (fd_set) / sizeof (__fd_mask); ++__i) \
__FDS_BITS (__arr)[__i] = 0; \
} while (0)
The valac-generated part
readfds = (FD_ZERO (&_tmp0), _tmp0);
is a syntax error then.
Anything we can do about that or just give in and leaving FdSet a full
class?
use memset ?
Heh, right. Will you try to get the patch into the respective c libraries?
I thought we were talking about vapi files. Something like
[Compact]
public class FdSet
{
[CCode (cheader_filename = "string.h")]
public void zero () {
memset(this, 0, sizeof(this));
}
But I suppose you could also call FD_ZERO from the body too...
Sam
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] How to wrap select(2)'s fd_set?
* David Keijser wrote, On 05/02/09 13:07:
2009/2/5 Michael 'Mickey' Lauer :
Am Friday 30 January 2009 14:26:51 schrieb Michael 'Mickey' Lauer:
Am Friday 30 January 2009 08:30:43 schrieb Jürg Billeter:
FdSet should be a struct, not a class, we do not need reference type
semantics here. This eliminates unnecessary heap allocation. FD_ZERO
should be bound as initialization method as it just zeroes the streuct.
Understood.
[CCode (cname = "fd_set", cheader_filename = "sys/select.h"]
public struct FdSet {
[CCode (cname = "FD_ZERO")]
public FdSet ();
...
}
With this change, I get a strange C-compilation error:
/local/pkg/fso/fso-gsm0710muxd/src/multiplexer.c: In
Funktion »multiplexer_writefd«:
/local/pkg/fso/fso-gsm0710muxd/src/multiplexer.c:324: Fehler: expected
expression before »do«
/local/pkg/fso/fso-gsm0710muxd/src/multiplexer.c:325: Fehler: expected
expression before »do«
/local/pkg/fso/fso-gsm0710muxd/src/multiplexer.c:326: Fehler: expected
expression before »do«
The respective generated code is:
gboolean multiplexer_writefd (Multiplexer* self, const char* command, gint
fd) {
fd_set _tmp0 = {0};
fd_set readfds;
fd_set _tmp1 = {0};
fd_set writefds;
fd_set _tmp2 = {0};
fd_set exceptfds;
struct timeval t = {(glong) 1, (glong) 0};
gint r;
gboolean _tmp3;
gssize bwritten;
g_return_val_if_fail (self != NULL, FALSE);
g_return_val_if_fail (command != NULL, FALSE);
readfds = (FD_ZERO (&_tmp0), _tmp0);
writefds = (FD_ZERO (&_tmp1), _tmp1);
exceptfds = (FD_ZERO (&_tmp2), _tmp2);
FD_SET (fd, &writefds);
...
I have no idea where this 'do' comes from.
Ok, I now found out:
FD_ZERO is defined as __FD_ZERO which in turn is defined as:
/* We don't use `memset' because this would require a prototype and
the array isn't too big. */
#define __FD_ZERO(s) \
do { \
unsigned int __i; \
fd_set *__arr = (s); \
for (__i = 0; __i < sizeof (fd_set) / sizeof (__fd_mask); ++__i) \
__FDS_BITS (__arr)[__i] = 0; \
} while (0)
The valac-generated part
readfds = (FD_ZERO (&_tmp0), _tmp0);
is a syntax error then.
Anything we can do about that or just give in and leaving FdSet a full class?
use memset ?
I have this vague memory of there being a way of marking a function as
a macro in vapi. if not perhaps it should be considered adding it as
macros are quite common.
Try the gcc extension something like:
readfds = (__extension__ ({ FD_ZERO(&_tmp0)} ), _tmp);
I recall someone saying that generally vala code is compiled by gcc.
However I would like vala to be able to disentangle the long tuples and
write some human looking code... although it is a nasty job as the
re-written code can no longer be followed by variable declarations, but
this is much simpler to read:
FD_ZERO(&_tmp0);
readfds = _tmp0;
I wonder why _tmp0 needed to be used at all - I would have guessed to
stop readfds accessing an uninitialized struct, but that doesn't make
sense if readfds starts out as an uninitialized struct...
Sam
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Ownership syntax changes
Why not [owned] ? Sam -Original Message- From: JürgBilleter Sent: 20 December 2008 07:32 To: jamie.mccr...@gmail.com Cc: vala-list Subject: Re: [Vala] Ownership syntax changes On Fri, 2008-12-19 at 20:49 -0500, Jamie McCracken wrote: > On Sat, 2008-12-20 at 02:19 +0100, Hans Vercammen wrote: > > On Fri, 2008-12-19 at 12:10 +0100, Jürg Billeter wrote: > > > > > > * `(owned)' cast replaces `#' reference transfer expression > > > > > > Even less used, equally unintuitive. Example of new syntax: > > > > > > string foo = (owned) bar; > > > > I don't have a strong opinion on this since I don't really need it, but > > using a cast expression feels a bit wrong. Not sure if we want to keep > > the option open of having operator overloading, but what about something > > like: > > > > string foo <= bar; > > or > > string foo << bar; > > <= and << are already operators in use and would be confusing but i do > agree the use of cast syntax here is odd > > I would suggest something thats not a cast but still clear: > > string foo owns bar; It needs to be an expression, as it can also be used as a method argument, not just in assignments. > or > > string foo = owned bar; We could of course remove the parentheses, however, I don't really see how this should be more intuitive than my proposal. (owned) probably stands out a bit more in the code, which is a good thing for rarely used syntax. I proposed a cast syntax as a short for a full cast including the type and modifier: string foo = (owned string) bar; Just like with a cast, we still refer to the same object, we just also modify ownership behavior. 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] foreach performance
* Jürg Billeter wrote, On 17/12/08 13:51: > On Wed, 2008-12-17 at 13:39 +0000, Sam Liddicott wrote: > >> * Jürg Billeter wrote, On 17/12/08 13:04: >> >>> foreach is meant to be used for read-only iteration over a collection as >>> this is very common. It's really just a bit syntactic sugar. If you need >>> more features, use a while loop with an appropriate iterator. I read that as applying to arrays, and not to anything implementing the iterable interface, my mistake >> Thinking back to my dylan days (anyone ever use dylan?) it was common >> to have modifiable iterators. >> >> I'm suggesting that foreach could also be used on objects that support >> an iterable interface, so that a function could return an iterator >> that is used by foreach and destroyed after the for-each. >> >> Thus the syntactic sugar could remain but also support modifying the >> collection if the collection could produce a safe iterator. >> > > I don't quite understand, foreach works on objects that implement the > iterable interface. What exactly are you proposing? > Precisely that I also mis-read Phil's response and also the original question from Кутейников Дмитрий. And I've not been well lately :-) Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] foreach performance
* Jürg Billeter wrote, On 17/12/08 13:04: > On Tue, 2008-12-16 at 17:58 +0300, Кутейников Дмитрий wrote: > >> Why there are no operator to remove current object in foreach block? >> > > foreach is meant to be used for read-only iteration over a collection as > this is very common. It's really just a bit syntactic sugar. If you need > more features, use a while loop with an appropriate iterator. > Thinking back to my dylan days (anyone ever use dylan?) it was common to have modifiable iterators. I'm suggesting that foreach could also be used on objects that support an iterable interface, so that a function could return an iterator that is used by foreach and destroyed after the for-each. Thus the syntactic sugar could remain but also support modifying the collection if the collection could produce a safe iterator. Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] HashTable get_keys() and get_values() methods. Bug or my fault?
* Vlad Grecescu wrote, On 04/12/08 23:55: > > > On Wed, Dec 3, 2008 at 2:04 PM, Sam Liddicott <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > * Daniele Benucci wrote, On 03/12/08 11:42: > > Grabel's Law: > > 2 is not equal to 3 -- not even for large values of 2. > I've seen some 2's masquerading as uncharacteristically small > values of > aleph-null, which some poor newbie made the mistake of trying to > de-reference. > > And as aleph-null is actually a singleton as a class variable > affecting > all classes,and the result's weren't pretty. As a consequence, the > contents of each dimension n (from 1 to infinity) had to be moved to > dimension n*2, and all the odd numbered dimensions became out of > bounds. > > > Nice one Sam, Are you implying that HashTable.get_keys() actually > dereferences aleph-null? No but I'd like to see it try... Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] HashTable get_keys() and get_values() methods. Bug or my fault?
* Daniele Benucci wrote, On 03/12/08 11:42: > Grabel's Law: > 2 is not equal to 3 -- not even for large values of 2. I've seen some 2's masquerading as uncharacteristically small values of aleph-null, which some poor newbie made the mistake of trying to de-reference. And as aleph-null is actually a singleton as a class variable affecting all classes,and the result's weren't pretty. As a consequence, the contents of each dimension n (from 1 to infinity) had to be moved to dimension n*2, and all the odd numbered dimensions became out of bounds. Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [Bindings]instance position
* Mihail Naydenov wrote, On 24/11/08 12:33: > Hi, > Im writing a vapi for a C library (FreeImage) > I need to set the instance position to custom value (like second > param) for some of the functions, but right now nothing else except > first position > ( 0 <= instance_pos < 1) and last ( instance_pos < 0) seams to work. > > Is it planed this option to be full-featured anytime soon? I really > need this to make the api consistent. > 10x! > MihaiNaydenov > > PS Im sending this mail a second time because it did not show up in > the list, Im sorry if it is received twice by someone ... 3 times; 14th November, 23rd November, 24th November. It was answered on 14th November by Jürg: On Fri, 2008-11-14 at 04:29 -0800, Mihail Naydenov wrote: > > Hi, > > I started writing a vapi for a c library and I want to use > > instance_pos to set the place of the instance parameter. > > Problem is, I need it to be the *second param*, but instance_pos = 1 > > or instance_pos = 2 remove it altogether. > > I tested it a bit end it turned out 0 > values < 1 - make it the first > > param, values < 0 - make it the last, and thats about it. > Try instance_pos = 1.1 - this inserts the instance parameter after the first parameter. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Implicit lamdas/closures
Thanks for continuing this conversation, I know it is a distraction to
your async work. I do appreciate it.
* Jürg Billeter wrote, On 04/11/08 12:14:
> On Mon, 2008-11-03 at 20:15 +0000, Sam Liddicott wrote:
>
>> (I'm not sure how you are generating the continue entry points, but if
>> you are using wrapper functions, then the continuation lambda would
>> just be a way of specifying the body, type signature and name of that
>> wrapper, instead of whatever the async model would do)
>>
>
> The code is all in a single function and a switch statement jumps to the
> right statement.
>
This seems to mean that "yields" functions will be seen to have extra
parameters when invoked from C, e.g. C users of a vala library; I
suppose this will tie C uses into the particular async model.
Have you considered having entry-point wrapper-functions that merely
call the main body with the correct switch value? (- Although I digress
somewhat, and it no longer affects me, as callbacks probably won't need
the "yields" modifier and their wrapper function will be the lambda
anyway...)
>> I would also need to use something like the keyword yield to specify a
>> continuation point and that the return should not free the closure.
>>
>> I could probably do without the yield blocks I suggested and have
>> "continue inline" refer to the next yield statement, thus avoiding
>> polluting the language too much;
>>
>> despite this though I think the yield bocks are safer as they ensure
>> that the "continue inline" lambda is specified in the yield block and
>> prevents the callback occuring in a diffent block by careless placing
>> of the next yield statement
>>
>> So it seems that "continue inline" and yield blocks are the only
>> outward language polutions I'm proposing, and maybe not yield
>> blocks...
>>
>
> One major concern I have is how do you intend to pass values returned
> from the callback back to the main method? The parametrized continue you
> proposed seems to be too cryptic, do you have an alternative idea?
>
Do you mean the pastebin example:
(thing, secret) => { continue(thing, secret); return true; }
or the example in my recent message of:
(thing, secret) => { continue inline; return true; }
in which lambda arguments that are also defined in the main body are
used to receive the callback data, otherwise they become local (and
temporary) to the scope of the lambda itself?
Of course the lambda callback could do:
(thing, secret) => { main_thing = thing; main_secret=secret + "hee hee";
continue inline; return true; }
I don't think either is particularly cryptic if one knows that the
feature exists, and for someone who doesn't - when they see it - it will
certainly get their attention, so they won't miss it. If they don't know
what it is they will know that it's something new/puzzling rather than
come to the wrong conclusion - (and I think many would guess right).
Sam
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Implicit lamdas/closures
Jürg, I'll call your stuff "async" and mine "callbacks". You're right that I can do most of what I need with continuation lamdas. Perhaps I could abuse the keyword pair "continue inline" to cause the lambda to invoke the main body at the correct point. (I'm not sure how you are generating the continue entry points, but if you are using wrapper functions, then the continuation lambda would just be a way of specifying the body, type signature and name of that wrapper, instead of whatever the async model would do) I would also need to use something like the keyword yield to specify a continuation point and that the return should not free the closure. I could probably do without the yield blocks I suggested and have "continue inline" refer to the next yield statement, thus avoiding polluting the language too much; despite this though I think the yield bocks are safer as they ensure that the "continue inline" lambda is specified in the yield block and prevents the callback occuring in a diffent block by careless placing of the next yield statement So it seems that "continue inline" and yield blocks are the only outward language polutions I'm proposing, and maybe not yield blocks... Continue inline is important to unroll what would otherwise be nested lamda soup - in contrast to which nested methods would be better, but continue inline is better still. If it helps I'll post the samba composite-connect which is a multi-stage (with branching) async authentication protocol negotiator. (i.e. It has to find out what authentication is supported and make one of them work). Unrolling this into one function is my holy grail for callbacks. Thanks for your input. Sam -Original Message- From: JürgBilleter <[EMAIL PROTECTED]> Sent: 03 November 2008 07:34 To: Sam Liddicott <[EMAIL PROTECTED]> Cc: Michael 'Mickey' Lauer <[EMAIL PROTECTED]>; vala-list@gnome.org Subject: RE: [Vala] Implicit lamdas/closures On Mon, 2008-11-03 at 07:25 +, Sam Liddicott wrote: > -Original Message- > From: JürgBilleter <[EMAIL PROTECTED]> > Subject: RE: [Vala] Implicit lamdas/closures > > >The generated C code uses GAsyncReadyCallback > >and GAsyncResult from GLib/GIO. > > Are you inclined to support use by plain boring delegate style > callbacks where libraries have their own async framwork and just want > a delegate to use as a callback? The main issue I see is that the delegates probably all look a bit different, which may make it hard to implement in a generic way. It should be possible to write a backend plug-in to support a different async framework in the future. Do you have a code example, so that we can see whether that allows a generic implementation or not? Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Implicit lamdas/closures
-Original Message- From: JürgBilleter <[EMAIL PROTECTED]> Subject: RE: [Vala] Implicit lamdas/closures >The generated C code uses GAsyncReadyCallback >and GAsyncResult from GLib/GIO. Are you inclined to support use by plain boring delegate style callbacks where libraries have their own async framwork and just want a delegate to use as a callback? ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Implicit lamdas/closures
The delgates may have extra parameters though and not be glib based. Sam -Original Message- From: JürgBilleter <[EMAIL PROTECTED]> Sent: 02 November 2008 07:30 To: Christian Hergert <[EMAIL PROTECTED]> Cc: Sam Liddicott <[EMAIL PROTECTED]>; vala-list@gnome.org Subject: Re: [Vala] Implicit lamdas/closures On Sat, 2008-11-01 at 18:01 -0700, Christian Hergert wrote: > It would be useful if delegates could through exceptions here too. > Particularly when you do async calls that take a delegate. Delegates can already throw exceptions. However, I don't really see the relation to async calls as it won't be necessary to manually pass delegates to the async methods. I'll write some examples when it's working. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Implicit lamdas/closures
It'll be a couple of weeks at least before I can look at it. Jürg, are you intending to allow the callbacks to pass in additional variables? Are you planning to base it around any particular async framework? Will callbacks be able to continue a loop where it left off? Sam -Original Message- From: JürgBilleter <[EMAIL PROTECTED]> Sent: 01 November 2008 08:27 To: Michael 'Mickey' Lauer <[EMAIL PROTECTED]> Cc: vala-list@gnome.org Subject: Re: [Vala] Implicit lamdas/closures On Wed, 2008-09-17 at 16:22 +0200, Michael 'Mickey' Lauer wrote: > Am Wednesday 17 September 2008 00:34:08 schrieb Jürg Billeter: > > 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. > > That sounds amazing. Could we use this to have the missing support for async. > dbus server support or is that only useful for the client? Yes, async D-Bus server support will be built on top of this scheme. I'm planning to start working on this soon. 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] __str__ method in vala ?
* Roberto Majadas wrote, On 24/10/08 12:50: > Hi everyone : > > Could be really interesting a method like __str__ method in python. > > >From python doc : > > __str__( > self) > Called by the str() built-in function and by the print statement > to compute the ``informal'' string representation of an object. > This differs from __repr__() in that it does not have to be a > valid Python expression: a more convenient or concise > representation may be used instead. The return value must be a > string object. > > Examples : > > Opinions ? > I suppose you could define a debug interface that objects could implement. Is is possible to query a vala object to see if it implements a certain interface? That is one of the IInterface benefits I forgot about on IRC this week. Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [ANNOUNCE] Vala 0.4.0 - Compiler for the GObject type system
* Jürg Billeter wrote, On 21/10/08 12:00:
> The restriction to property assignment statements has been lifted, which
> means that you can have any kind of statements in the constructors /
> creation methods. However, you should be careful not to mix the two
> construction schemes too much. If you want to use the new mechanism,
> don't use any construct properties.
>
> It's also possible to chain up to the base constructor now, similar as
> in C# and Java. This won't yet work when subclassing from C library
> classes, but I'm planning to fix that. Short example:
>
> public class Foo {
> public Foo () {
> ...
> }
> }
>
> public class Bar : Foo {
> public Bar () {
> base ();
> ...
> }
> }
>
> You can also call named constructors `base.with_foo ()' and constructors
> of the same class `this ()' or `this.with_foo ()'.
>
Thanks Jürg, thats brilliant.
Sam
___
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
* Sam Liddicott wrote, On 20/10/08 07:24:
> Yu Feng wrote:
>> 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.
Probably because I'm trying to merge continuations, lambdas and closures
into one, for use on libraries that support mere callbacks. I may not
have made the breadth of my intentions clear, and only by reflecting on
your message did it become that clear to me.
Based on recent posts, I'm suggesting that the word "continue" be used
to let a lambda's execution continue back into the enclosing function.
Using examples from recent posts would give based on current syntax:
client.post_request("GET ...",
(response) => {
debug("Hurrah!");
continue;
},
(second_callback) => {
debug("boo!");
return;
};
);
// continue carries on here
client.post_request("GET some more",
or with the new suggested syntax:
client.post_request("GET ..."):
(response) => {
debug("Hurrah!");
continue;
},
(second_callback) => {
debug("boo!");
return;
};
client.post_request("GET some more",
Combining with a previous suggestion of mine, if the first lambda is
nothing but a continue statement, then the inline psuedo function
definition "continue" can be used to declare the callback.
client.post_request("GET ...",
continue(String response),
(second_callback) => {
debug("boo!");
return;
};
);
// continue carries on here
client.post_request("GET some more",
And possible the String type specifier for the parameter can be missed
out if response is already declared, otherwise it declares a new
variable in the block of the continue target.
Or maybe this notation is preferred:
(response) => continue
and
(String response) => continue; // response not already declared
Finally, as the function is supposed to return implicitly after the
post_request, I would do it like this:
return {
if (S_OK != client.post_request("GET ...",
continue(String response),
(second_callback) => {
debug("boo!");
return;
};
)) throw new Error(..);
return;
};
// continue carries on here
client.post_request("GET some more",
The continuation point always being the end of the { } block that is
part of the return statement, avoiding the need for the ever-unpopular
labels.
Sam
___
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
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 <[EMAIL PROTECTED]> Sent: 19 October 2008 15:40 To: Sam Liddicott <[EMAIL PROTECTED]> Cc: Ali Sabil <[EMAIL PROTECTED]>; Christian Hergert <[EMAIL PROTECTED]>; Vala Mailing list 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 sin
Re: [Vala] Proposal for an improved delegate/lambda handling
[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.
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 <[EMAIL PROTECTED]>
Sent: 19 October 2008 15:40
To: Sam Liddicott <[EMAIL PROTECTED]>
Cc: Ali Sabil <[EMAIL PROTECTED]>; Christian Hergert
<[EMAIL PROTECTED]>; Vala Mailing list
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 <[EMAIL PROTECTED]>
Sent: 19 October 2008 11:31
To: Christian Hergert <[EMAIL PROTECTED]>
Cc: Vala Mailing list
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
<[EMAIL PROTECTED]> wrote:
I like it. Might get confusing if someone wanted to mix di
Re: [Vala] Proposal for an improved delegate/lambda handling
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 ___ 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
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.
Sam
-Original Message-
From: Ali Sabil <[EMAIL PROTECTED]>
Sent: 19 October 2008 11:31
To: Christian Hergert <[EMAIL PROTECTED]>
Cc: Vala Mailing list
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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]___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Proposal for asynchronous DBus calls.
* 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] Proposal for asynchronous DBus calls.
* 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.
If you seach recent vala posts by me, you'll see some discusion on this topic.
I hope to be able to start coding something along these lines in a couple of
weeks.
My current plan is that such functions are generated as lamdas, with a set of
wrappers for entry points. There is no need for an async keyword.
Callbacks can pass extra parameters.
The vala notaton I now favour is:
//async-able function
Int func(int arg1) {
..
return {
...
Do-something(...,continue(int arg2, int arg3));
Return 1;
}
Use(arg3)
..
}
Continue() is a psuedo function which generates the address of a wrapper with
the specified parameter list which continues execution just after the return
block.
I don't know how GLibs g_idle works or fits in.
Sam
-Original Message-
From: Yu Feng <[EMAIL PROTECTED]>
Sent: 16 October 2008 14:39
To: vala-list
Subject: [Vala] Proposal for asynchronous DBus calls.
= intro =
Vala has embedded DBus calls through its dynamic method mechanism.
It is nice, but this is not yet the complete story of DBus.
Aside from the sync calls, DBus can also make async calls. In an async
call, the caller starts a DBus call on a DBusGProxy by
dbus_g_proxy_begin_call, giving a callback to be invoked when the call
is finished. In the callback, dbus_g_proxy_end_call is called to collect
the 'out' args.
Here is a tutorial on how to make asynchrous dbus calls.
http://maemo.org/maemo_training_material/maemo4.x/html/maemo_Platform_Development/Chapter_05_Asynchronous_GLibDBus.html
= current solution =
In current vala, the related functions are exposed in dbus-glib-1.vapi,
and in principle one can always write explicit code with these api to
achieve an async call. lambda functions for DBusGProxyCallNotify can be
used to to mitigate the discontinuity problem of async calls.
= proposed solution =
What if vala can also embed async DBus calls the same way as sync DBus
calls?
I have a vague, inchoate idea in mind. The newly introduced keyword is
'async', to describe an async function call.
async Object . Method(method paramters) += callback;
where callback is either a class/namespace method or a lambda function.
Here is an example
dynamic DBus.Object something;
int int_param = 1;
string string_param = "hello";
async something.Method(string_param, int_param) += (rt1, rt2) => {
message("async call returns: rt1 = " + rt1.to_string() + "rt2 = " +
rt2.to_string());
}
At the implementation level, valaccodedynamicmethodbinding has to be
modified to generate appropriate wrappers for the callback function by
invoking dbus_g_proxy_end_call.
= Problems =
Note: current vala doesn't support type signatures on parameters of
lambda functions, but we can use a class member function(which has
explicit parameter types) instead. Bug 511879 is related to this.
The implication of asynchronous calls is a running MainLoop. this
implication is not a new one, because we already need a mainloop for
dynamic signals anyways.
= Benifits =
Embedding the support of async calls into Vala makes vala better
suitable for writing async programs which do not block the UI for long
time DBus calls.
The 'async' keyword makes it extremely easy to modify existed sync
program to async programs. In some cases if the return value is not
interested, the modification is merely prefixing the 'async' keyword.
= further =
This can also be extended to non-dynamical methods, by GLib's g_idle
mechanism.
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] TreePath from TreeView.get_cursor() never freed?
I suggest that these attributes should be able to be declared in the C header file using vala key words which in C are #defined to nothing. Sam -Original Message- From: Hans Vercammen <[EMAIL PROTECTED]> Sent: 12 October 2008 03:26 To: [EMAIL PROTECTED] Cc: vala-list@gnome.org Subject: Re: [Vala] TreePath from TreeView.get_cursor() never freed? On Sat, 2008-10-11 at 14:50 -0700, Geert Jan wrote: > When I don't use a weak TreePath, like this: > > TreePath path; > weak TreeViewColumn focus_column; > treeview.get_cursor (out path, out focus_column); > > I get this error: > > error: duplicating TreePath instance, use weak variable or explicitly invoke > copy method > treeview.get_cursor (out path, out focus_column); > Yes, you should use a strong reference for the Gtk.TreePath parameter. This is a bug[1] in the gtk+-2.0.vapi file. The current signature in Gtk.TreeView reads: public void get_cursor (out weak Gtk.TreePath path, out weak Gtk.TreeViewColumn focus_column); While it should be something like: public void get_cursor (out Gtk.TreePath? path, out weak Gtk.TreeViewColumn? focus_column); The vala api files for GObject based libraries are automatically generated through introspection. But sometimes there is not enough information on how to use the parameters correctly, so these additional attributes are added in a metafile as described in the wiki[2]. For most api's it should be ok, but it's always possible some parameters need additional information which isn't there yet. If you encounter similar problems feel free to file a bug at http://bugzilla.gnome.org/. Hans [1] http://bugzilla.gnome.org/show_bug.cgi?id=555972 [2] http://live.gnome.org/Vala/Bindings ___ 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 justed noted that my main requirement in all this has been that I want
it possible to use the same function body whether or not the functions
it calls turn out to be synchronous or asynchronous in it's response;
this will help me get rid of a load of duplicate function bodies in samba.
So far I've re-moved the sync response handler and just call the async
response handler manually to handle sync responses, but thats not nice
anyway as I've got no lambda support in C so I have to do my "local
vars" struct manually, but in any case it doesn't help with the more
complex state machines that do protocol negotiation.
I mention this because I just realised that some of you are coming from
a different position in this with different requirements.
I also forgot to reply-to-all so some of you weren't cc'd to my previous
message (below)
Sam
Sam Liddicott wrote:
Christian Hergert wrote:
Christian, when you said:
var value = yield obj.do_something ();
Did you mean that the lamda continuation address be implicitly
passed to do_something()?
When you talk of the yield returning a value, do you mean to the
caller? So that yield is equivalent to "return" but just doesn't
free the local vars?
I'm thinking that if a method uses the yield syntax, that calling
method itself would need to be an asynchronous method.
In samba4, A proxied close request of a read-only file would be
synchronous because the response could be given to the client
immediately without waiting for the response from the server being
proxied, but if the file had been written to then it would be an
asynchronous request. Similarly for cached file reads, credential
fetches etc. So the caller could not always know in advance if the
full response will be given synchronously or asynchronously.
Also the caller may be in-process and request a synchronous response
precisely because a state-machine setup was too complicated, and this
samba code would really benefit from continuation capabilities in vala.
So sometimes, synchronous-ness is not a property of a method itself
but of it's execution. A method may-or-may not give a synchronous
response, and the caller would have to know how to interpret that (and
does).
It also depends on the semantic context (ugh) of the caller; if it's
intended only to have a distant effect then it can be said to be
synchronous, even if that effect requires multi-stage processing using
yield. Even a synchronous request to file-read may use yield in order
to process some additionally requested read-ahead blocks, so I think
your case doesn't hold in a general sense.
I can see that asynchronous methods might be meaningful to some event
driven frameworks but it seems very specific.
I don't think we need (or I don't need) to especially introduce a
concept of asynchronous methods, just another way to express and
implement lambdas. If the lambda can be implemented as a function
pointer and a void* pointer (and with libffi's trampolines we can get
by with just a function pointer !) then we can cope with all cases
including specific frameworks.
I'm now pressing for concensus on some aspects
Does anyone have concern with the implementation that has
* the message body with a load of goto's at the top, and then
* an entry-wrapper for the main function to setup the local vars struct,
* an entry-wrapper for each callback entry point to process additional
arguments and set the goto-point
?
Are people happy that the continuation lambdas should accept
parameters as lambdas currently do?
Do people prefer the [out] notation of a fake yield function call to
receive the extra parameters or some other notation?
If labels are out of favour (reminder)
something.callback=label_name;
return STATUS_ASYNC;
label_name(int extra_param):
do_something_with(extra_param);
is this preferred:
something.callback=yield([out] int extra_param) {
return STATUS_ASYNC;
};
do_something_with(extra_param);
I prefer the label, because yield() isn't really a function call and
making it look line one doesn't help, it's confusing that all it's
arguments MUST be [out] and it only allows one callback to be setup;
consider this which is possible with normal lambdas and so should be
possible with continuation lambdas.
something=send_request();
if (something.async) {
something.callback=got_result;
something.error_handler=failed_result;
return STATUS_ASYNC;
}
got_result:
stash(something.result);
result;
failed_result(int error_code):
log_error(error_code);
return;
}
The requirement to have "return" looks unclean only if you think that
the called function is always asynchronous, which needn't be true even
for non-error responses.
I'm not opposed to a yield command or a concept of asynchronous
methods to do some of this automatically
Re: [Vala] Implicit lamdas/closures
Christian Hergert wrote:
Christian, when you said:
var value = yield obj.do_something ();
Did you mean that the lamda continuation address be implicitly
passed to do_something()?
When you talk of the yield returning a value, do you mean to the
caller? So that yield is equivalent to "return" but just doesn't
free the local vars?
I'm thinking that if a method uses the yield syntax, that calling
method itself would need to be an asynchronous method.
In samba4, A proxied close request of a read-only file would be
synchronous because the response could be given to the client
immediately without waiting for the response from the server being
proxied, but if the file had been written to then it would be an
asynchronous request. Similarly for cached file reads, credential
fetches etc. So the caller could not always know in advance if the full
response will be given synchronously or asynchronously.
Also the caller may be in-process and request a synchronous response
precisely because a state-machine setup was too complicated, and this
samba code would really benefit from continuation capabilities in vala.
So sometimes, synchronous-ness is not a property of a method itself but
of it's execution. A method may-or-may not give a synchronous response,
and the caller would have to know how to interpret that (and does).
It also depends on the semantic context (ugh) of the caller; if it's
intended only to have a distant effect then it can be said to be
synchronous, even if that effect requires multi-stage processing using
yield. Even a synchronous request to file-read may use yield in order to
process some additionally requested read-ahead blocks, so I think your
case doesn't hold in a general sense.
I can see that asynchronous methods might be meaningful to some event
driven frameworks but it seems very specific.
I don't think we need (or I don't need) to especially introduce a
concept of asynchronous methods, just another way to express and
implement lambdas. If the lambda can be implemented as a function
pointer and a void* pointer (and with libffi's trampolines we can get by
with just a function pointer !) then we can cope with all cases
including specific frameworks.
I'm now pressing for concensus on some aspects
Does anyone have concern with the implementation that has
* the message body with a load of goto's at the top, and then
* an entry-wrapper for the main function to setup the local vars struct,
* an entry-wrapper for each callback entry point to process additional
arguments and set the goto-point
?
Are people happy that the continuation lambdas should accept parameters
as lambdas currently do?
Do people prefer the [out] notation of a fake yield function call to
receive the extra parameters or some other notation?
If labels are out of favour (reminder)
something.callback=label_name;
return STATUS_ASYNC;
label_name(int extra_param):
do_something_with(extra_param);
is this preferred:
something.callback=yield([out] int extra_param) {
return STATUS_ASYNC;
};
do_something_with(extra_param);
I prefer the label, because yield() isn't really a function call and
making it look line one doesn't help, it's confusing that all it's
arguments MUST be [out] and it only allows one callback to be setup;
consider this which is possible with normal lambdas and so should be
possible with continuation lambdas.
something=send_request();
if (something.async) {
something.callback=got_result;
something.error_handler=failed_result;
return STATUS_ASYNC;
}
got_result:
stash(something.result);
result;
failed_result(int error_code):
log_error(error_code);
return;
}
The requirement to have "return" looks unclean only if you think that
the called function is always asynchronous, which needn't be true even
for non-error responses.
I'm not opposed to a yield command or a concept of asynchronous methods
to do some of this automatically in simple cases, but I'm pressing for
the same capabilities that lambdas currently have, as this would be
prefereable to a mass of nested lambda which could do mostly the same
thing (not quite) in an ugly way.
Sam
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Implicit lamdas/closures
Thanks for your responses everyone.
Christian, in relation to ownership of mutable strings and other ref counting
within the closure; I understod that local vars will all be declared on a
struct which is allocated on the heap in order to preserve the local vars for
when the closure (or closures) are entered. Surely this struct (which must
endure for the lifetime of the closures) will have ownership; when the struct
is free'd all it's members will be un-ref'd or free'd just as local variables
are when a function exits.
Precisely HOW it can be known that the closure is finished with is hard to say.
I guess we can say that closures used as linear continuations must only occur
once (what if they are nevr used?) but normal closures could be used as often
as the subsystem wants to make a callback. It's a problem but not particular to
linear continuations.
Jürg, I like the yield idea. However it can't dispense with the may_async which
was an rpc-server specific control feature; although if the entire rpc server
and framework were written in vala with linear continuations, maybe it would
not be needed.
It seems like yield only deals with functions that would block, and can't
handle actual callbacks, especially if they have additional arguments -
something which closures do support.
It seems like the yield mechanism is dependant on features of the underlying
event dispatcher like twisted or gnome, and requires the blocking function to
integrate with that.
My example permitted non blocking calls that organize a callback "somehow",
more like signals I suppose. How would yield deal with a callback from a timer?
Its not that a sync and async version of a function need generating but that
the function itself may want to mke multiple async (or not) calls.
Christian, when you said:
var value = yield obj.do_something ();
Did you mean that the lamda continuation address be implicitly passed to
do_something()?
When you talk of the yield returning a value, do you mean to the caller? So
that yield is equivalent to "return" but just doesn't free the local vars?
Samuel; I looked at having a separate genrated function for each continuation
point as you suggested but its only simply possible if the points are at the
top level of a function. To have the yield be able to resume inside any code
block like loops (and I guess try blocks, I haven't seem how the C is
generated) the generated C function really needs to be 1 big body with goto's
at the top so as to be able to resume halfway through.
The idea that a function could be marked "asyncable" intreagues me, but I don't
like it; it is merely a particular form of delegate lambda, and in my example
there was no asyncable blocking function, it is clearly a "request a callback"
operation, and the lambda delegate address was not passed as a function
argument but asigned to an object delegate field.
I think we all agree that "rest of function as a lambda" is useful and
simplifies some async programming knots.
I'm suggesting that such "rest of function" lambdas still be able to take
additional arguments; if the C label syntax is unpleasant we could express the
yield as a function call with [out] arguments to receive the parameters.
E.g.
Instead of:
something.callback=do_more;
return: (or yield)
do_more(FileInfoList f):
We could have
something.callback=yield([out] FileInfoList f);
Where yield returns the name of the generated wrapper function that will
re-enter the method body and goto a label that will be emitted in C right after
this vala statement has emitted it's C.
Of course that means that assigning the delegate also returns and seems to lose
control of the non-final return value. Also in my case there is other setup
that needs doing before this non-final return so I don't like the idea that
taking the addres of the continuation lambda implies a return. I can see why
people don't like labels though.
Maybe the return preamble could be enclosedlike this:
Something.callback=yield([out] FileInfoList f) { request.did-async=true;
Return NT_STATUS_OK; }
So that the resume point wil unambiguously be after any exit code.
I don't just want to do "something" to help async coding, but I want to be able
to take the address of and jump back into a lambda.
I posted the "generated" c code seperately:
www.liddicott.com/~sam/sam/rpc_server.html
So it will be easy to see that the wrapper functions for each return type can
have different calling signtures and how they can still jump to the right part
of the lambda.
Sam
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Implicit lamdas/closures
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? Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Implicit lamdas/closures
Based on the idea I posted last night, I've done a proof-of-concept for
what I'm going to rename for the third time as "unrolled continuations"
which allows asynchronous clients (in server-client relationship) to be
coded synchronously but still implemented asynchronously by means of
continuations. This is most useful where the client also happens to be
an asynchronous server as samba4 is in my case.
The work is built upon the (not yet written) local variable lambda
support for vala.
I have for download a small vala project that uses the gtk event loop to
drive asynchronous handlers for continuations.
http://www.liddicott.com/~sam/sam/contin-0.1.0.tar.gz
When running the demo, if you click on the first button it makes an
basic rpc server object and issues an async request.
Click on the second button to answer that request.
When the answer is received a loop commences which issues 3 more
requests that need responding too.
Altogether the respond button is clicked 4 times, final response is then
ready to send back to the non-existent client.
This shows off that continuations can break-off and carry-on halfway
through a loop.
This all makes more sense after reviewing rpc_server.vala and rpc_server.c
rpc_server.vala uses a notation I will discuss below, but of course vala
can't handle this, so rpc_server.c and rpc_server.h have been severely
tweaked to have the form which I think ought to be generated.
I'm proposing a concept of inline lambdas that are supported using C's
label notation; e.g.
int a_function(int x) {
do_something(x);
a_label:
do_someting_else(x);
and within a_function, "a_label" can be used as if it were a function
pointer which internally takes 1 void* parameter which points to the
heap-allocated locals as is currently on the roadmap for lambda functions.
The labels and heap-allocated local variables allow a callback to
continue part-way through the function as if it had never left off.
I also propose this extended notation where parameters can follow the
label. If the parameters are already declared as local variables then
the type could (must?) be omitted.
They are a means of the callback passing extra data for cases where the
callback provides more than just a void* private data parameter.
It is important to realise that the label could also be reached WITHOUT
a callback occuring so the default value is also used to initialize the
local variable as well as a default parameter when (if) the callback
occurs. (Hmmm... do default parameters work for delegates?)
e.g.
int a_function(int x = 100) {
do_something(x);
// note that the label also has parameters
a_label(int y = 10):
do_something
so that the generated wrapper will be declared something like:
int a_function__a_label(a_function__local_vars *vars, int y) {
vars->y=y;
return a_function__body(vars,1);
}
where the 2nd parameter 1 signifies the first label that a case
statement at the top of in a_function__body will "goto" (see below)
The a_function will generate two C functions, one to prepare and
initalize the heap:
int a_function(int x) {
struct a_function_vars vars=malloc(sizeof(struct a_function_vars));
vars->parameters.x=x;
vars->locals.y=10;
return a_function__body(vars, 0);
}
and then the real function body:
static int a_function__body(struct a_function__vars *vars, int label) {
switch (label) {
case 0: break;
case 1: goto a_label;
}
do_something(vars->locals.x);
a_label:
...
...
So, when making an async call that wants to use the rest of the function
as a continuation:
int a_function(int x) {
request_callback(next_position);
return;
next_position:
// do some more here
return;
}
For purity the async "return" maybe should be hidden? For samba4 I'll be
using a vapi-wrapped C macro which checks that the callback was
allocated and then returns so vala won't even know there was a return -
which also aids readability, but the other problem is that if vala knows
there is a return it starts unref'ing al the local variables which is
clearly wrong for a lambda - I guess vala will have to deal with this
when it finishes lambda support.
I imagine the heap-allocated local-vars struct will be ref-counted, so
that the variables will all get free'd when there are no more
continuation references.
Otherwise maybe all the heap-allocated local vars could be explicitly
freed with "finally return" or some such strong hint.
Maybe for even better neatness we want an implicit label called "next"
or something, which if used causes vala to effectively insert a
return_default after this vala statement, and imply a label following that..
Sam
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Implicit lamdas/closures
A simpler implementation comes to mind.
Any function that wants to be re-entered halfway through as a result of
lamda-ly continuation type callbacks is implemented like this:
The header function which sets up the local vars on the heap according to
normal lambda behaviour and then calls the main body which takes the heap
pointer and a goto-value.
The main body does a case-dispatch on the goto-value to jump to the right
labels halfway through the function.
For each label that serves as a lamda-re-entry; a stub function exists which
calls the main body with the heap and the right goto-value.
These stub functions become the various continuation entry callbacks that are
passed to the subsystem that will issue the callback.
I never though C goto would be so useful.
It allows the main function body to stay as one function and even allows loops
to properly work.
And involves less vala freakery to implement.
Comments?
Sam
-Original Message-
From: Sam Liddicott <[EMAIL PROTECTED]>
Sent: Monday, September 15, 2008 9:57 AM
To: vala-list@gnome.org
Subject: [Vala] Implicit lamdas/closures
I've been thinking a lot on how vala can make programming asynchronous rpc
servers as simple as programming synchronous rpc servers; I.e. No need to worry
about continuations/callbacks.
What I've come up with is implicit lamdas; without the need for ()=>{} which is
some cases would be nested, gettimg very ugly.
Simple rpc call handlers are self-enclosed and synchronous. Eg
rpc_server_get_next(thing x) {
return next(x);
}
But some rpc calls can only be satisfied by making other async calls
rpc_server_check_credentials(creds c) {
req r=auth_server.check_creds(c);
return r.wait_for_response();
}
And unless you have a new thread or process for each call, this is going to
block other rpc requests. Consider this case:
rpc_server_read_file(file f, int offset, int len) {
return sysread(f, offset, len);
}
It should be possible to use asynchronous io on some modern systems, yet it is
hardly worth allocating a new thread over.
Samba4 has each server request marked whether or not it may be processed in an
async manner, usually it can.
If the server module chooses to do so it also marks the request when it returns
so that a response is not sent right away. The module sends the response later
after one or a few callbacks from async client requests used to fulfil the
original server request.
However the processing of asyc client responses is generally identical to the
processing of the same responses done synchronously.
The general pattern is look this
server_do_things(stuff) {
req=do_thing(stuff, otherstuff);
req.add_callback(finish,stuff,otherstuff)
If (stuff.may_async) {
stuff.did_async=true;
Return OK;
}
// this also calls finish callback
req.wait_till_done();
return(stuff.status);
}
The obvious candidate for the lambda is the finish function, giving something
like this
(assuming lambda local-vars support is complete)
server_do_things(stuff) {
req=do_thing(stuff, otherstuff);
req.add_callback( (req) => (
stuff.status=req.receive(stuff);
// do more stuff here
) )
If (stuff.may_async) {
stuff.did_async=true;
Return OK;
}
// this also calls finish callback
req.wait_till_done();
return(stuff.status);
}
It's a little puzzling that the lamda appears halfway through; but it gets more
complicated if the server has to issue more than one client request; the nest
lambdas make the whole thing look like lisp.
The idea of implicit lamdas is to allow the code to be laid out as if it were
synchronous but still work asynchronously, see:
server_do_things(stuff) {
req=do_thing(stuff, otherstuff);
req.add_callback(finish,stuff,otherstuff)
If (stuff.may_async) {
stuff.did_async=true;
Return OK;
} else {
// this also calls finish callback
req.wait_till_done();
return (stuff.status);
}
finish:
stuff.status=req.receive(stuff);
// do more stuff here
return(req.status);
}
finish: is a regular C style label; but if it's address is taken for a delegate
then it becomes simultaneously a lambda until the end of the enclosing block
and also a call to that lambda.
Thus the code can be run_into during normal execution as well as apparently
run-into for async execution.
If such a thing were possible, the rpc glue would differ so as to make better
use of it.
Here's a more complex case which unwinds a terrible state machine into an
apparent linear function:
server_auth(stuff) {
req=send_get_auth_types(stuff);
// I'll talk about block this later...
if (stuff.may_async) {
req.add_callback(type);
Stuff.dyd_async=true;
return;
} else {
Req.wait_for_response();
}
type:
if (stuff.kerberos) {
kreq=send_kerberos(krb);
...
krb:
If (kreq.success)...
} else if (stuff.ntlm) {
}
}
I said that implicit lambdas ought to last to the end of the containing block,
but really when that block finishes a new implicit lambda shou
[Vala] Implicit lamdas/closures
Dear all,
I agree that until or unless justice will not prevail in the society, it
will keep deteriorating and frustration of the people will keep mounting.
However, we cannot only stick to the judiciary crisis. We have so many other
important issues engulfing us that we cannot stay stick to this for long
(that movement can be carried in parallel with little flexibility, if all
the parties are not agreeing to a single point) and ignore all others saying
that first of all this should be done then come rest of the problems. I
think that we should move-on, find a middle way out and start focusing on
the other issues as well. I am a great supporter of a good judiciary system
but we cannot jeopardize the whole nation on this issue and ignoring other
issues with which life of common man is concerned more.
I totally respect your point of you, but I think its not about giving chance
to one party or the other, we cannot keep trying different sects of society.
Even then, some would say, they are good and some will say they are not. We
need to think on a wider frame, I guess.
Best regards,
Irum
On Tue, Sep 2, 2008 at 11:54 PM, Nauman Ilyas <[EMAIL PROTECTED]>wrote:
>
> Dear Natasha,
>
> I believe that we as common people of Pakistan should give these lawyers a
> chance. Everybody (politician, army, bureaucracy) got a chance; why not
> these lawyers. Who knows what good they will bring to this country; I am
> sure you agree with me that these lawyers will do no damage to our beloved
> country as compared to what Army and our political elite did.
>
> Nauman.
>
>
> >
>
--~--~-, otherstuff);
req.add_callback(finish,stuff,otherstuff)
If (stuff.may_async) {
stuff.did_async=true;
Return OK;
}
// this also calls finish callback
req.wait_till_done();
return(stuff.status);
}
The obvious candidate for the lambda is the finish function, giving something
like this
(assuming lambda local-vars support is complete)
server_do_things(stuff) {
req=do_thing(stuff, otherstuff);
req.add_callback( (req) => (
stuff.status=req.receive(stuff);
// do more stuff here
) )
If (stuff.may_async) {
stuff.did_async=true;
Return OK;
}
// this also calls finish callback
req.wait_till_done();
return(stuff.status);
}
It's a little puzzling that the lamda appears halfway through; but it gets more
complicated if the server has to issue more than one client request; the nest
lambdas make the whole thing look like lisp.
The idea of implicit lamdas is to allow the code to be laid out as if it were
synchronous but still work asynchronously, see:
server_do_things(stuff) {
req=do_thing(stuff, otherstuff);
req.add_callback(finish,stuff,otherstuff)
If (stuff.may_async) {
stuff.did_async=true;
Return OK;
} else {
// this also calls finish callback
req.wait_till_done();
return (stuff.status);
}
finish:
stuff.status=req.receive(stuff);
// do more stuff here
return(req.status);
}
finish: is a regular C style label; but if it's address is taken for a delegate
then it becomes simultaneously a lambda until the end of the enclosing block
and also a call to that lambda.
Thus the code can be run_into during normal execution as well as apparently
run-into for async execution.
If such a thing were possible, the rpc glue would differ so as to make better
use of it.
Here's a more complex case which unwinds a terrible state machine into an
apparent linear function:
server_auth(stuff) {
req=send_get_auth_types(stuff);
// I'll talk about block this later...
if (stuff.may_async) {
req.add_callback(type);
Stuff.dyd_async=true;
return;
} else {
Req.wait_for_response();
}
type:
if (stuff.kerberos) {
kreq=send_kerberos(krb);
...
krb:
If (kreq.success)...
} else if (stuff.ntlm) {
}
}
I said that implicit lambdas ought to last to the end of the containing block,
but really when that block finishes a new implicit lambda should start in the
outer block as if it were declared in the same manner as discussed; and so on
until the end of the enclosing function block is reached.
That way parts of the function can be deferred or executed immediately without
a problem.
I don't know how such a lamda would cope with being in a loop.
The If block for which I said: "// I'll talk about block this later..." clearly
it's a pain to have to repeat that async/sync fixup code everytime, but I think
I've said enough to layout the problem and how lamdas could unwind horrible
continuation chains and async state machines, so I'm open for comment.
Sam
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Patch: allow TypeSymbols in emitted C code for some C library macros
[This time with the patch attached]
The attached patch to vala 0.3.5 allows vala to emit naked type symbols
as arguments to ellipses functions.
(The ellipses is really a red-herring, but it is currently the favoured
way to pass non-type-checked arguments to library macros which vala is
wrapping as functions - maybe some work could be done on "void" here, or
"any" [like python] for un-type-checked arguments)
This function is useful when a macro wants the C type passing, generally
for stringifying or casting; I particularly need it to make use of this
Samba4 talloc library macro:
#define talloc_zero(ctx, type) (type *)_talloc_zero(ctx, sizeof(type),
#type)
which is a pretty darn useful macro, wrapped with this vapi:
[CCode (sentinel="")]
public void* zero(void* mem_ctx, ...);
NOTE: only one of the fragment for
gobject/valaccodeinvocationexpressionbinding.vala
and
gobject/valaccodegenerator.vala
is needed.
valaccodeinvocationexpressionbinding has the most specific patch only
covering the ellipses case in method invocation generation,
valaccodegenerator has a more general case and triggers quite often and
so for all I know has some broader side effects.
Comments?
Sam
diff --git a/ccode/Makefile.am b/ccode/Makefile.am
index d335e02..7d0b016 100644
--- a/ccode/Makefile.am
+++ b/ccode/Makefile.am
@@ -61,6 +61,7 @@ libvalaccode_la_VALASOURCES = \
valaccodewhilestatement.vala \
valaccodewriter.vala \
valaccodeelementaccess.vala \
+ ccode/valaccodetypesymbol.vala \
$(NULL)
libvalaccode_la_SOURCES = \
diff --git a/ccode/valaccodetypesymbol.vala b/ccode/valaccodetypesymbol.vala
new file mode 100644
index 000..d9c0e1b
--- /dev/null
+++ b/ccode/valaccodetypesymbol.vala
@@ -0,0 +1,39 @@
+/* valaccodetypesymbol.vala
+ *
+ * Copyright (C) 2008 Sam Liddicott
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ * Author:
+ * Sam Liddicott <[EMAIL PROTECTED]>
+ */
+
+using GLib;
+
+/**
+ * Represents a type symbol in the C code, which is only any use if it is being
+ * passed to a library C macro instead of a function.
+ */
+public class Vala.CCodeTypeSymbol : CCodeExpression {
+public string c_type_name { get; construct; }
+
+ public CCodeTypeSymbol(string _c_type_name) {
+ c_type_name = _c_type_name;
+ }
+
+ public override void write (CCodeWriter writer) {
+ writer.write_string (c_type_name);
+ }
+}
diff --git a/gobject/valaccodegenerator.vala b/gobject/valaccodegenerator.vala
index 29ce6c3..049a1eb 100644
--- a/gobject/valaccodegenerator.vala
+++ b/gobject/valaccodegenerator.vala
@@ -2651,6 +2651,10 @@ public class Vala.CCodeGenerator : CodeGenerator {
if (expr.ccodenode != null && !expr.lvalue) {
// memory management, implicit casts, and boxing/unboxing
expr.ccodenode = transform_expression ((CCodeExpression) expr.ccodenode, expr.value_type, expr.target_type, expr);
+ } else if (expr.value_type == null && expr.ccodenode == null && expr.symbol_reference is TypeSymbol) {
+ /* naked TypeSymbol's emit the underlying C type. The semantic analyser restricts this
+ to working only on ellipses arguments; useful for some library C macros */
+ expr.ccodenode = new CCodeTypeSymbol((expr.symbol_reference as TypeSymbol).get_cname());
}
}
diff --git a/gobject/valaccodeinvocationexpressionbinding.vala b/gobject/valaccodeinvocationexpressionbinding.vala
index 744216a..54b136e 100644
--- a/gobject/valaccodeinvocationexpressionbinding.vala
+++ b/gobject/valaccodeinvocationexpressionbinding.vala
@@ -309,6 +309,12 @@ public class Vala.CCodeInvocationExpressionBinding : CCodeExpressionBinding {
if (param.ctype != null) {
cexpr = new CCodeCastExpression (cexpr, param.ctype);
}
+} else {
+ /* Passthrough TypeSymbol for ellipses */
+ if (cexpr == null && arg.value_type == null && arg.symbol_reference is TypeSymbol) {
+ cexpr = new CCodeTypeSymbol((arg.symbol_reference as TypeSymbol).get_cname());
+ arg.ccodenode = cexpr;
+ }
}
arg_pos = codegen.get_param_pos (param.cparameter_position, ellipsis);
} else {
diff --git a/vala/valasemanticanalyzer.vala b/vala/valasemanticanalyzer.vala
index 1634636..3d2c706 100644
--- a/vala/valasemanticanal
[Vala] Patch: allow TypeSymbols in emitted C code for some C library macros
The attached patch to vala 0.3.5 allows vala to emit naked type symbols as arguments to ellipses functions. (The ellipses is really a red-herring, but it is currently the favoured way to pass non-type-checked arguments to library macros which vala is wrapping as functions - maybe some work could be done on "void" here, or "any" [like python] for un-type-checked arguments) This function is useful when a macro wants the C type passing, generally for stringifying or casting; I particularly need it to make use of this Samba4 talloc library macro: #define talloc_zero(ctx, type) (type *)_talloc_zero(ctx, sizeof(type), #type) which is a pretty darn useful macro, wrapped with this vapi: [CCode (sentinel="")] public void* zero(void* mem_ctx, ...); NOTE: only one of the fragment for gobject/valaccodeinvocationexpressionbinding.vala and gobject/valaccodegenerator.vala is needed. valaccodeinvocationexpressionbinding has the most specific patch only covering the ellipses case in method invocation generation, valaccodegenerator has a more general case and triggers quite often and so for all I know has some broader side effects. Comments? Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] patch to add read/write to FileStream
In the definition use a default parameter: ..., int nmemb = 1)... Which means if the caller code doesn't supply a value then vala fills in a 1. sam -Original Message- From: Cliff Brake <[EMAIL PROTECTED]> Sent: 04 September 2008 23:14 To: vala-list@gnome.org Subject: [Vala] patch to add read/write to FileStream The below patch adds read/write to FileStream: Index: vala-0.3.5/vapi/glib-2.0.vapi === --- vala-0.3.5.orig/vapi/glib-2.0.vapi 2008-08-29 17:39:43.0 -0400 +++ vala-0.3.5/vapi/glib-2.0.vapi 2008-09-04 17:05:11.0 -0400 @@ -2426,6 +2426,10 @@ public int scanf (string format, ...); [CCode (cname = "fflush")] public int flush (); + [CCode (cname = "fread", instance_pos = -1)] + public int read (char[] buf, int nmemb); + [CCode (cname = "fwrite", instance_pos = -1)] + public int write (char[] buf, int nmemb); } [CCode (lower_case_cprefix = "g_file_", cheader_filename = "glib/gstdio.h")] Question: is there any way I can always set nmemb=1 so the caller does not have to set that variable? In vala, I would just do: read(buf), instead of read(buf, 1) Thanks, Cliff -- === Cliff Brake http://bec-systems.com ___ 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] initializing structures
* Cliff Brake wrote, On 03/09/08 21:38:
> Looking at the Vala test code, I realized the syntax should be:
> ...
> mystruct[] my_a = {
> mystruct() {test1 = "this is a test", test2 = 10},
> mystruct() {test1 = "this is a test"},
> mystruct() {test2 = 12}
> };
>
Wow. That's weird.
Sam
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Simpler RE: embedding c code snippet in vala source.
You can probably simplify it and perhaps make it less offensive by getting rid of the C parsing for symbol names and try another way. For my work on compact classes vmt expressions etc, I implement it as a macro body; if you implement the snippet as a macro body it and pass in the vala parameters then the C preprocessor will do the symbol replacement for you, and you van treat the snippet as an opaque string that becomes the macro bodyguards For my own stuff the macro args are fixed, but I guess for you they will be the methods own args. Sam Sam -Original Message- From: Yu Feng <[EMAIL PROTECTED]> Sent: Thursday, August 21, 2008 7:27 PM To: vala-list Subject: [Vala] embedding c code snippet in vala source. Dear all, I made a patch that allows embedding c code snippet in vala source. http://bugzilla.gnome.org/show_bug.cgi?id=548897 This is quite primitive and more has to be done, especially to translate the vala variable names to cnames. I would like to analogue this with embedding asm code in c. :-) Another direction of this patch is to allow small wrapping code in the .vapi declarations (which might ease the vapi authors's life) 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] embedding c code snippet in vala source.
* Jürg Billeter wrote, On 22/08/08 11:26: > >>[CCode (snippet = "g_free(this);")] >>public void free(); >> > > We don't want free functions in the bindings API, we already have > `delete' to free memory if you use raw pointers. > Darn, I'll need them for compact classes... Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] embedding c code snippet in vala source.
* Alexey Lubimov wrote, On 22/08/08 12:53: > Jürg Billeter пишет: >> On Fri, 2008-08-22 at 06:45 -0400, Yu Feng wrote: >> >>> Man this is a trap. There is no logical relation between failing to >>> provide examples and the the validaty of a feature. >>> >> >> I agree, however, I don't see a reason to merge a feature as long as >> there is no use case for it. >> >> Cheers, >> Jürg >> >> > I hope, this is good feature for hackers, for non trivial bindings or > debug purposes; > > For example, You can copy any existing vapi file to project tree and > add debug assert to them without vala source code modifications. > > Or wrap several lib-functions (allocate buffers or any other service > ) to one function for vala. > > > Maybe, this is not good cases for develop production software, but > this is very important for beginers and hackers. It will help me prototype the remainder of the compact-class implementation, so I'll be patching my compiler with it anyway. Sam ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] embedding c code snippet in vala source.
Surely it's OK for VAPI files whose purpose is to integrate with C anyway; and certainly preferable to having to ship an extra vapi .h file with inline function or macro definitions... I think its great. I prefer the name cexpression to snippet, I use such things in my compac class virtual method enhancement, the expression use used by vala to locate the virtual method table for acompact class or object. Sam -Original Message- From: Emmanuele Bassi <[EMAIL PROTECTED]> Sent: Thursday, August 21, 2008 11:18 PM To: vala-list@gnome.org Subject: Re: [Vala] embedding c code snippet in vala source. On Thu, 2008-08-21 at 14:27 -0400, Yu Feng wrote: > Dear all, > > I made a patch that allows embedding c code snippet in vala source. > > http://bugzilla.gnome.org/show_bug.cgi?id=548897 > > This is quite primitive and more has to be done, especially to translate > the vala variable names to cnames. no, please: let's not turn Vala into the new GOB. this makes the code an unbearable mess - been there, done that. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ 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] Lacking of a ref-counted string.
One of the uses of char* is a string buffer, not immutable but not neccesarily weak either. Vala doesn't make it simple to transfer ownership but keep a weak reference when passing a shared string. You can do it with an extra variable because quite naturally it is the variable that is weak, not the string... I think this complicates the transmution from String to string because it will depend on if a shared buffer was intended. Sam -Original Message- From: Yu Feng <[EMAIL PROTECTED]> Sent: 20 August 2008 22:09 To: JürgBilleter <[EMAIL PROTECTED]> Cc: Vala Mailing list Subject: Re: [Vala] Lacking of a ref-counted string. On Wed, 2008-08-20 at 22:43 +0200, Jürg Billeter wrote: > On Wed, 2008-08-20 at 22:29 +0200, Ali Sabil wrote: > > > > > > On Wed, Aug 20, 2008 at 9:10 PM, Yu Feng <[EMAIL PROTECTED]> > > wrote: > > Dear Devs, > > > > Is there any particular reason that GLib doesn't provide a > > ref-counted > > string and a ref-counted array type? Lacking them in GLib > > makes the VALA > > language a real pain. > > > > I don't really see your point, strings in vala are immutable, so there > > is no real point in having them shared across objects. > > Well, it would certainly be nice to have reference counted strings to > avoid endless strdups, however, I don't think it would help if glib > introduced ref-counted strings now. The existing libraries can't and > won't just switch to the new type, so we just have to deal with multiple > string types. > The point is, if GLib has a ref-counted string, then it becomes reasonable to support unmanaged non-ref-counted strings in VALA. Then it becomes reasonable to provide routines do the manual memory management for non-ref-counted strings. And we are out from the strdups. Make a distinguish between String and string: String: ref-counted, can be strongly referred or weakly referred, managed by vala just as other classes. No special treatment and strdup for no more. string: non-ref-counted, can only be weakly referred, managed by the programers with new and delete. It becomes the programmer's duty to copy them when needed. (either by an explicitly string.dup method or a special new operator) For general programers, they only need String. For those who are gluing with GLib and knows what they are doing, string can meet their requirement. The same principle also works for arrays. > Also, as strings are immutable, there would be no practical difference > in using strings in Vala, it'd really just be an optimization. As > creating a single GObject is way more expensive than a string copy, I'd > assume that string copies are usually not the biggest performance issue. > If strings are copied and freed frequently, won't the memory become fragmented? See JohnMoser's talk at http://live.gnome.org/MemoryReduction I have a strong feeling that Vala's strdup's tend to make the UUxxU pattern but haven't been able to prove it. Yu > 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] Lacking of a ref-counted string.
I think it has what you ask for, if a class doesn't inherit from gobject then internally it inherits from gtypeinstance which is what you said. Sometimes people don't distinguish between the two, though. However I want compact non-gobject non-gtype instance (I want I want... Never satisifed with what Juerg et al have produced for me...) Sam -Original Message- From: Ali Sabil <[EMAIL PROTECTED]> Sent: Wednesday, August 20, 2008 9:25 PM To: Bastien Nocera <[EMAIL PROTECTED]> Cc: gtk-devel-list <[EMAIL PROTECTED]>; Vala Mailing list Subject: Re: [Vala] Lacking of a ref-counted string. On Wed, Aug 20, 2008 at 9:15 PM, Bastien Nocera <[EMAIL PROTECTED]> wrote: On Wed, 2008-08-20 at 15:10 -0400, Yu Feng wrote: > Dear Devs, > > Is there any particular reason that GLib doesn't provide a ref-counted > string and a ref-counted array type? Lacking them in GLib makes the VALA > language a real pain. You could just wrap simple GObjects around GString and GPtrArray. Wouldn't that be overkill ? do we need signals and properties for strings and arrays ? maybe GLib/GObject should have something like GstMiniObject that only provides reference counting and no signals/properties ? ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] error on property;
Yu Feng wrote:
On Wed, 2008-08-20 at 18:54 +0100, Sam Liddicott wrote:
Yu Feng wrote:
Hi Alex,
Fortunately I was dealing with the same problem too.
The key is for a property, you almost always want a weak string, and
manage the string in the object. In other words, this code will be fine:
public class Info.PersonInfo {
private string fio_;
public weak string fio {
get {
fio_ = get_fio();
return fio_;
I don't think that is safe.
I hope vala will strdup the returned value when I do a
string foo = personinfo.fio.
I think you are right; my mistake... I was confusing what you did with
an error I had previously made :-)
Although next time somebody reads fio, the old fio_ will get free'd and
we had better hope the old user has finished with it; it may be better
to only generate fio_ once for the life of the object.
I agree that it is problematic; part of the issue seems to be that
strings can't be reference counted and (apart from "weak") are also
immutable. The strdup's in generated code drive me mad.
I've pointed out a 'solution' to them is to abandon any attempt of
managing the strings and leave the job to programmers in the other
post(the 'workaround' one)
Yeah :-) I'm trying to think of a solution that covers both problems.
Vala seems based on gobject and does a very good job of making gnome
projects simple, but I think we're trying to make it cover non-gnome too.
I shall mention again that the talloc allocator not only ref-counts
and has owners but has destructors AND is type-safe. Talloc for string
management at least would make things much simpler. However it could
complicate transferring ownership to glib libraries which would use
the wrong free function.
In one word, talloc is not in GLib and doesn't fit into the GLib backend
of Vala. right? So far what I can understand is vala hasn't yet separate
the GLib backend from the core compiler.
Vala will always want to be good for glib, but I agree that a keeping
the language features without glib will be good too, it's something I'm
working on.
I've got indirect subclassing working where an instance has a pointer to
the parent instance which has a pointer to the child instance, and that
complicated valainstancecast quite a bit; I stll need to sort out
construction and instantiation for this; but I really need to have
support for talloc ref counting.
I'm still convinced there is something in my malloc pool idea where a
pointer (by examining against memory ranges) can be efficiently pinned
down to a malloc pool and malloc pool handler, which bestows features or
interfaces on the object being pointed to. For best efficiency, each
malloc system will need it's own anonymous mmap'd range to allocate from
in order that the pointer can be identified to that handler, but
sub-allocating large blocks from the real pool will work at a pinch.
There are still issues with fixed-length char arrays as part of a larger
allocated struct which are not real char* but may look like it when
passed as an argument...
So I'm still thinking... but I think vala needs two string types, a
boring char* (with optional max-len and option count) and a proper string...
Sam
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
