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
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
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
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
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
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
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
inline: wrtOa+MS+fAielRYdFNvZnR3YXJlAAB42isvL9fLzMsuTk4sSNXLL0oHADbYBlgQU8pcAElFTkSuQmCCinline: 497470.png___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
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
I meant that these would be mandatory only for 2nd and subsequent declarations.
Sam
-Original Message-
From: Sam Liddicott s...@liddicott.com
Sent: 12 January 2010 07:25
To: Jiří Zárevúcky zarevucky.j...@gmail.com; Fabzter fabos...@gmail.com
Cc: vala-list@gnome.org
Subject: Re: [Vala
* 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
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ří
* 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 s...@liddicott.com
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
Pascal lets you have a bitwise set from an enum using
Set of ENUMTYPE
Sam
-Original Message-
From: pancake panc...@youterm.com
Sent: 02 November 2009 18:42
To: Vala ML vala-list@gnome.org
Subject: Re: [Vala] Minor features request (about structs and enums)
Michael 'Mickey' Lauer
* 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.
* 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 rainwood...@gmail.com:
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
(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
* 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
* 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
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
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
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
could help a
migration from mono. I don't advocate that we actually DO anything.
Sam
2009/6/26 Sam Liddicott s...@liddicott.com:
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
:
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
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 s...@liddicott.com
mailto:s...@liddicott.com wrote:
Yes, but it is much cleaner and nicer to express
)]
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 s
* 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
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 c.r@wanadoo.fr
Sent: 15 May 2009 19:12
To: vala-list@gnome.org
Subject: [Vala] Problem
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
Yeah... Nicer to be implicit though.
Sam
-Original Message-
From: Levi Bard Sent: Wednesday, May 06, 2009 7:48 PM
To: Sam Liddicott s...@liddicott.com
Subject: Re: [Vala] Listing directory content with GIO
On Wed, May 6, 2009 at 2:42 PM, Sam Liddicott s...@liddicott.com wrote:
I prefer
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
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
* 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
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
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 b...@ucw.cz
Sent: Friday, April 10, 2009 5:39 PM
To: vala-list@gnome.org
Subject: Re: [Vala] Optional output parameters?
Sam Liddicott s...@... 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
Sam
-Original Message-
From: Jan Hudec b...@ucw.cz
Sent: 09 April 2009 20:10
To: vala-list@gnome.org
Subject:
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
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
You can write small functions in the vapi file;.
Sam
-Original Message-
From: Adi Roiban a...@roiban.ro
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
I wouldn't want to use glib, which was the point of my post.
Sam
-Original Message-
From: Michael Torrie torr...@gmail.com
Sent: 14 February 2009 21:31
Cc: vala-list vala-list@gnome.org
Subject: Re: [Vala] [Having fun with Vala] Multiboot kernel using Vala!
Sam Liddicott wrote:
I
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
* Jürg Billeter wrote, On 17/12/08 13:51:
On Wed, 2008-12-17 at 13:39 +, 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
* 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
* 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
* 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
* 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
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 +, Sam Liddicott wrote:
(I'm not sure how you are generating the continue entry points, but if
you are using
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
* 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
* 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
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
* 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
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.
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
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
* 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
: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
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:
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
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
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
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
\
$(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
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
* 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
* 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
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
properties and property getters are all weak.
but you are also generating the string you return which is not weak.
if the actual string value returned doesn't change, you might want to
use a lazy create and have the object own the string and then you can
return a weak reference:
private string
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
realloc (and/therefore free) can then dispatch to the right handler
based on the address.
The system can thus support multiple alloc systems including those that
refcount. It would be a good addition to glib too.
Juergbi?
Sam
-Original Message-
From: Sam Liddicott [EMAIL PROTECTED]
Sent
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
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,
This patch allows sentinels to be specified on a class and apply to all
varargs methods of that class and subclasses.
it also allows an empty string to be specified
[CCode (sentinel=)]
which results in no sentinel argument being emitted.
I find it useful so I can declare access to macro's of a
* Jürg Billeter wrote, On 15/08/08 15:24:
On Fri, 2008-08-15 at 15:17 +0100, Sam Liddicott wrote:
I have the same problem:
[CCode (cheader_file = ntstatus.h, cprefix=NT_STATUS_)]
namespace NT_STATUS {
[CCode (cname=NT_STATUS_OK)]
public static NTSTATUS OK;
[CCode (cname
My first changes to he code generator will be to permit each generated node to
emit comments.
The code generator will them be able to generate commented code explaining the
reason code was generated.
I plan on multiple levels of detail.
The comment construction will also serve as a guide to
* Jürg Billeter wrote, On 23/07/08 10:40:
On Thu, 2008-06-26 at 15:09 +0100, Sam Liddicott wrote:
We see that the last function (above) has the arguments the wrong way
around because I had removed the instance_pos.
But in fact it is only the entry method that needs to take into account
So that the code generator can annotate generated code with it's own
comments, I think that CCodeNode needs to have a comment field (clearly
not a CCodeComment).
The writer methods of *Declaration classes will write out the comment
field with each declarator.
When a declarator is created, e.g.
The valac makefiles seem to be a bit buggy.
I made this change (among others) to ccode/valaccodedeclaration.vala:
-public CCodeDeclaration (string type_name) {
+public CCodeDeclaration (string type_name, string comment=) {
and then typed: make
but got errors like:
gcc -DHAVE_CONFIG_H
What's the equivalent of __FILE__ and __LINE__ in vala?
Is there an irc on which I get better ask some of these questions?
thanks
Sam
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
My previous model for allowing vapi wrapped classes to have virtual
methods involved block the object model at the vapi interface; i.e.
gobject stuff can traverse superclasses and so forth until they reach
the first vapi class, at which point class metadata is not available,
although virtual
Daniel Svensson wrote:
On Fri, Jul 18, 2008 at 4:58 PM, Sam Liddicott [EMAIL PROTECTED] wrote:
you can do:
/usr/bin/valac -C --pkg zlib --pkg gtk+-2.0 --basedir .
src/mainwindow.vala src/api.vapi
However, --pkg api automagically handles dependencies and runs
pkg-config for you, so
* Sam Liddicott wrote, On 18/07/08 09:27:
* Frederik wrote, On 18/07/08 09:11:
Yu Feng wrote:
gtk_container_forall is loop over all the children (including the
internal children), it invokes
class-forall with the parameter including_internals = TRUE;
To make it clear
I just found this out yesterday but it may help other people;
you can specify a .vapi file on the command line just like a .vala file.
Instead of:
/usr/bin/valac -C --vapidir=src --pkg api --pkg zlib --pkg gtk+-2.0
--basedir . src/mainwindow.vala
you can do:
/usr/bin/valac -C --pkg zlib --pkg
, the old
value will be stored and used if base.method is invoked.
I think thats all?
Sam
Sam Liddicott wrote:
These suggested changes would permit vapi files to wrap structs that
contained a virtual method table.
If they are not objectionable to the development of Vala, I intend to
provide patches
planning to add alternate generator actions based on node
attributes, mostly CCode.
Sam
* Sam Liddicott wrote, On 17/07/08 07:47:
I omitted to mention the self mapping that also must occur if vapi
wrapped structs can contain virtual methods.
The wrapped struct contains a private data pointer
* Sam Liddicott wrote, On 15/07/08 13:03:
* Jürg Billeter wrote, On 15/07/08 11:47:
On Tue, 2008-07-15 at 07:55 +0100, Sam Liddicott wrote:
...
The first struct I intend to wrap is struct ntvfs_ops, as that struct
define my base object; see:
http://gitweb.samba.org/?p=samba.git;a=blob
It seems like g_new0 is the hard-wired allocator for New() objects that
aren't gobject managed.
How strong is the chance the a new CCode directive could be invented to
override this?
e.g.
[CCode (new_function=talloc)]
or even
[CCode (new_expression=talloc(NULL, %s))]
And, is this OK:
Is it possible to subclass a vapi class without starting a gobject hierachy?
e.g. subclass zlibs GZFileStream
http://www.vala-project.org/doc/references/zlib.vapi/ZLib/GZFileStream.htm
and a subclass instance is still compatible with the zlib methods.
(Naturally the methods will not be
These suggested changes would permit vapi files to wrap structs that
contained a virtual method table.
If they are not objectionable to the development of Vala, I intend to
provide patches.
I like how vapi classes can wrap structs as classes; I'm investigating
how these can be almost
I've re-read the vala docs on weak references and ownership transfer:
http://live.gnome.org/Vala/Tutorial#head-e667accbcd04f19dd6a2c14a68e22b3cc2179e58
The reference counting that vala supports is only for gobject; which
is fine, but the glib vapi file shows that this is done by the vapi file
and
* gege2061 wrote, On 15/07/08 10:49:
Hello,
You could see the Hacker's guide :
http://www.lesharris.com/vala-hackers-guide/hackers.html
Thanks; I wondered where that had moved to.
The http://rodney.id.au/dev/vala/hackers.html link on
http://live.gnome.org/Vala is bad.
Sam
* Ali Sabil wrote, On 15/07/08 10:47:
2008/7/15 Sam Liddicott [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]:
* Jared Moore wrote, On 15/07/08 10:40:
And in the advanced example:
http://live.gnome.org/Vala/AdvancedSample
what does the s signify in
this.foo += s
* Jürg Billeter wrote, On 15/07/08 12:13:
On Tue, 2008-07-15 at 11:11 +0100, Sam Liddicott wrote:
* Ali Sabil wrote, On 15/07/08 10:47:
Signal handler always have the signal sender as 1st parameter, in
this case it would be the AdvancedSample instance from which the
foo signal
* Jürg Billeter wrote, On 15/07/08 11:47:
On Tue, 2008-07-15 at 07:55 +0100, Sam Liddicott wrote:
...
The first struct I intend to wrap is struct ntvfs_ops, as that struct
define my base object; see:
http://gitweb.samba.org/?p=samba.git;a=blob;f=source/ntvfs/ntvfs.h;h
* Florian Brosch wrote, On 28/06/08 22:25:
On Sat, Jun 28, 2008 at 9:06 PM, Sam Liddicott [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
However, in trying to find the signal handler signatures for
Gtk.Button, I found just:
/publicsignal void
* Andrea Bolognani wrote, On 08/07/08 10:31:
On Mon, 7 Jul 2008 12:05:29 -0700
Christian Hergert [EMAIL PROTECTED] wrote:
Hi,
Wanted to suggest a feature that would be useful to simply the
consumption of GValue based methods. Just a bit of compiler magic to
automatically box/unbox
* Jürg Billeter wrote, On 02/07/08 13:59:
On Thu, 2008-05-15 at 02:28 -0300, Matías De la Puente wrote:
vala, will include operators overload like in c#?
We're not planning to support operator or method overloading,
are there non-technical reasons for avoiding method overloading?
I
Roberto Majadas wrote:
FYI
https://launchpad.net/~roberto-majadas/+archive
If somebody need any vala package, mail me :)
Please could you do vala 0.3.4
Please could you consider installing the .gi or .gir files as part of
your package; it would help my glade/gtkbuilder integration very
What you think?
2008/6/25 Sam Liddicott [EMAIL PROTECTED]:
Thanks to Nicolas who helped convert these to use gtkbuilder.
New files and a sample project are uploaded to:
http://www.liddicott.com/~sam/?p=98
All .glade files can be converted to .ui files
All .ui files can be converted
1 - 100 of 122 matches
Mail list logo
