[Vala] [ANNOUNCE] Libgee 0.5.2 - GObject collection library
We are very pleased to announce version 0.5.2 of Libgee, the GObject collection library. Libgee 0.5.2 is now available for download at: http://download.gnome.org/sources/libgee/0.5/ Also please note that Libgee has its own mailing-list http://mail.gnome.org/mailman/listinfo/libgee-list and its own #gee IRC channel. New in 0.5.2 * Build system enhancements to conform Gnome's style. * Bug fixes in TreeSet, TreeMap and Collection.to_array. * Deprecated Map methods marked with [Deprecated]. For more information about the 0.5 release series, see: http://live.gnome.org/Libgee/NewAndNoteworthy-0.5 http://live.gnome.org/Libgee/Migration-0.5 Libgee is a collection library providing GObject-based interfaces and classes for commonly used data structures. Libgee provides the following interfaces: * Iterable o Collection + List + Set + MultiSet + Queue # Deque * Iterator * Map * MultiMap The ArrayList, HashSet, HashMap, HashMultiSet, HashMultiMap, LinkedList, PriorityQueue, TreeSet, TreeMap, TreeMultiSet, and TreeMultiMap classes provide a reasonable sample implementation of those interfaces. In addition, a set of abstract classes are provided to ease the implementation of new collections. Around that, the API provide means to retrieve read-only views, efficient sort algorithms, simple, bi-directional or index-based mutable iterators depending on the collection type. Libgee is written in Vala and can be used like any GObject-based C library. It's planned to provide bindings for further languages. More information about Vala is available at http://live.gnome.org/Libgee Didier Villevalois ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Why no functions returning lists in libgee?
Hi Martin, On 12/07/10 13:26, Martin DeMello wrote: > How come libgee doesn't have any functions that return new lists (in > particular list.map() and list.filter())? Is it to avoid allocation? > I've been looking at porting ruby's Enumerable module to vala, but I > thought I'd check first as to why it isn't there already, and if this > sort of thing is for some reason a bad idea. There has been some proposals to add functional operators to libgee, but none yet got to something. See : http://mail.gnome.org/archives/libgee-list/2010-June/msg1.html and also : http://bugzilla.gnome.org/show_bug.cgi?id=589968 You are very welcome to contribute to libgee. Also you can discuss that on bugzilla, libgee-list or #gee. Best regards, Didier. ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] How to abort sorting in Gee.ArrayList?
[Hum, guess that should go to the list too...] Hi Christer, Could you open a feature-request ticket in Gee bug-tracker for that ? Best regards, Didier. On 28/06/10 20:26, Christer wrote: > Hi Didier, > > Yes, the async method idea with a Cancellable argument is something I > think could work. I will try it and see what kind of results I get. > > Right now Im just throwing the list away in the middle of the sorting > when a user moves to a new directory. It works, but its not very elegant. :) > > Kind regards, > Christer, Sweden > > 2010/6/28 Didier 'Ptitjes' mailto:ptit...@free.fr>> > Hi Christer, > > On 06/27/10 10:36, Christer wrote: > > Whats a smart way of aborting sorting a list? I have objects in a > ArrayList > > being sorted using the Comparable interface. My application is > handling > > millions of items being sorted and I sometimes would like to abort the > > sorting if the user chooses to do something else. > > Indeed, I think none ever submitted a such use-case. > > Should the original list be left untouched in case of cancellation ? In > that case, a temporary view should be used instead of the original list. > > Else, the original list would be left partially sorted (which might not > be a problem for certain use-cases). > > Then I guess sort() could also be defined as an async method with an > additional Cancellable argument. Would that fit your use-case ? > > > And thanks for Vala and Gee once again, Im loving the speed of > them both and > > plan to use them for many projects on Linux. :) > > Glad to hear that :) > > Best regards, Didier. > ___ > vala-list mailing list > vala-list@gnome.org <mailto: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] Graphic toolkits for Vala?
On 07/02/10 01:05, CaStarCo wrote: > At the end i thought may be i could make a program to help me to create > beautiful diagrams.. but never i made a program that works with editable > graphic elements. > > ¿Whic libraries should i use? (Probably i'll program it with Vala) Maybe a vala binding for FlowCanvas could help you. http://drobilla.net/software/flowcanvas/ Check Patchage, Ingen and Machina to see its capabilities... Best regards, Didier. ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] How to abort sorting in Gee.ArrayList?
Hi Christer, On 06/27/10 10:36, Christer wrote: > Whats a smart way of aborting sorting a list? I have objects in a ArrayList > being sorted using the Comparable interface. My application is handling > millions of items being sorted and I sometimes would like to abort the > sorting if the user chooses to do something else. Indeed, I think none ever submitted a such use-case. Should the original list be left untouched in case of cancellation ? In that case, a temporary view should be used instead of the original list. Else, the original list would be left partially sorted (which might not be a problem for certain use-cases). Then I guess sort() could also be defined as an async method with an additional Cancellable argument. Would that fit your use-case ? > And thanks for Vala and Gee once again, Im loving the speed of them both and > plan to use them for many projects on Linux. :) Glad to hear that :) Best regards, Didier. ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Adding my custom object to libGee.List...
On 06/21/10 11:20, Xavier Bestel wrote: > On Sun, 2010-06-20 at 21:28 +0300, Arkadi Viner wrote: >> Thanks, that did the trick. >> >> On Sun, Jun 20, 2010 at 5:02 AM, Didier 'Ptitjes' wrote: >> >>> Hi, >>> >>> On 06/19/10 23:48, Arkadi Viner wrote: >>>> *so, the declaration look like this:* >>>> private Gee.List pdfDocuments = new Gee.ArrayList (); >>>> >>>> *and when I try to add some thing to it:* >>>> pdfDocuments.add(new PdfDocument(file_chooser.get_filename >>> ()); >>>> *I get compilation error:* >>>> main.vala:99.13-99.24: error: missing generic type arguments >>>> Process return 256 execution time: 0.90 s >>> >>> I guess you have to make your declaration: >>> >>> private Gee.List pdfDocuments = >>>new Gee.ArrayList (); > > How about: > > var pdfDocuments = new Gee.ArrayList (); I thought "var" only worked for a local variable. Am I wrong ? Here pdfDocuments is a private member. Best regards, Didier. ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Adding my custom object to libGee.List...
Hi, On 06/19/10 23:48, Arkadi Viner wrote: > *so, the declaration look like this:* > private Gee.List pdfDocuments = new Gee.ArrayList (); > > *and when I try to add some thing to it:* > pdfDocuments.add(new PdfDocument(file_chooser.get_filename ()); > *I get compilation error:* > main.vala:99.13-99.24: error: missing generic type arguments > Process return 256 execution time: 0.90 s I guess you have to make your declaration: private Gee.List pdfDocuments = new Gee.ArrayList (); Best regards, Didier. ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Strangeness with sorting using Gee ArrayList
Hi folks, On 06/15/10 18:47, Dr. Michael Lauer wrote: > Am 15.06.2010 um 17:52 schrieb Abderrahim Kitouni: >> Yes, it is. It's however fixed in git >> http://git.gnome.org/browse/libgee/commit/?id=06ec26321cd3a475ac10ca3d47a4e4dbb4e44e00 >> >> I wonder why this didn't result in a bug fix release. > > The maintainer is MIA and we need to find another one. Indeed! Sorry for that... Best regards, Didier. ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Gee.ReadOnlyMap could not be found?
san hoi wrote:
Thanks!
Use Gee.Map as type and use my_map.read_only_view to retrieve the read-only
view for my_map.
umm...but I don't know how to use it.
Is there a sample code?
Is there something unclear in the three documents I linked ? Or did you
find it easier to ask than to read them ?
read_only_view is a property on the Map interface :
http://www.gnome.org/~dvillevalois/libgee/doc/gee-1.0/Gee.Map.read_only_view.html
Or do you mean that you need sample code to use a property ?
Anyway...
public Gee.Map streams {
get { return _streams.read_only_view; }
}
2009/12/23, Didier 'Ptitjes' :
Didier 'Ptitjes' wrote:
Hi,
[Cross-posting on gee-l...@gnome.org]
san hoi wrote:
wizbit/commit.vala:63.10-63.41: error: The type name `Gee.ReadOnlyMap'
could not be found
public Gee.ReadOnlyMap streams {
[...]
umm... Gee.HashMap is ok, but Gee.ReadOnlyMap is error.
ReadOnlyMap is deprecated?
Yeah ReadOnlyMap does not exist anymore. Use Gee.Map as type and use
my_map.read_only_view to retrieve the read-only view for my_map.
See http://live.gnome.org/Libgee/NewAndNoteworthy-0.5
and http://live.gnome.org/Libgee/Migration-0.5
Also the API docs might be of interest for you (valadoc.org has not been
updated yet)
http://www.gnome.org/~dvillevalois/libgee/doc/gee-1.0/index.htm
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Gee.ReadOnlyMap could not be found?
Didier 'Ptitjes' wrote:
Hi,
[Cross-posting on gee-l...@gnome.org]
san hoi wrote:
wizbit/commit.vala:63.10-63.41: error: The type name `Gee.ReadOnlyMap'
could not be found
public Gee.ReadOnlyMap streams {
[...]
umm... Gee.HashMap is ok, but Gee.ReadOnlyMap is error.
ReadOnlyMap is deprecated?
Yeah ReadOnlyMap does not exist anymore. Use Gee.Map as type and use
my_map.read_only_view to retrieve the read-only view for my_map.
See http://live.gnome.org/Libgee/NewAndNoteworthy-0.5
and http://live.gnome.org/Libgee/Migration-0.5
Also the API docs might be of interest for you (valadoc.org has not been
updated yet)
http://www.gnome.org/~dvillevalois/libgee/doc/gee-1.0/index.htm
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Gee.ReadOnlyMap could not be found?
Hi,
[Cross-posting on gee-l...@gnome.org]
san hoi wrote:
wizbit/commit.vala:63.10-63.41: error: The type name `Gee.ReadOnlyMap'
could not be found
public Gee.ReadOnlyMap streams {
[...]
umm... Gee.HashMap is ok, but Gee.ReadOnlyMap is error.
ReadOnlyMap is deprecated?
Yeah ReadOnlyMap does not exist anymore. Use Gee.Map as type and use
my_map.read_only_view to retrieve the read-only view for my_map.
See http://live.gnome.org/Libgee/NewAndNoteworthy-0.5
and http://live.gnome.org/Libgee/Migration-0.5
Best regards, Didier.
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Compile failed because of libgee.
bharani deepan wrote: On 11/17/2009 06:02 PM, G.S.Alex wrote: It seems that I've meet some problems with libgee. The sample code works fine. But when I try to compile Vala toy for gedit and Vala plugin for anjuta, it syas: symbol.vala:23.7-23.9: error: The namespace name `Gee' could not be found using Gee; ^^^ I've looked into the makefile.am and find that there is no " --pkg gee-1.0 ". But when I add it manually , errors change to : utils.vala:40.21-40.37: error: `ArrayList' is an ambiguous reference between `Vala.ArrayList' and `Gee.ArrayList' var results = new ArrayList (); ^ I too have the same error. But i have no error when i downgrade to the previous version of vala. There was a mandatory change needed in Vala to hide to collections the vala compiler internally use. This was creating collision with tools using libvala but needing to use the (more complete) libgee collections. One example of such tool is Valadoc. Before, it was defined in the 'Gee' namespace. To solve that problem, now the internal collections classes of valac are directly defined in the 'Vala' namespace. Please request the vtg and anjunta authors to update their package for the latest Vala. OR fix it yourself by removing all the "using Gee;" statements in the sources of both these tools. And please give some patches to the maintainers of those tools as this is maybe the third time I hear such complains on the Vala ML. Best regards, Didier. ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Who updates references.valadoc.org?
Hi Magnus, Magnus Therning wrote: On 16/10/09 08:29, Didier 'Ptitjes' wrote: Florian told me he would update it this WE. Excellent. I have no problems making do with the .vapi file in the meantime ;) This may finally take a little more time. So as an interim, I published the generated docs from the Gee build there: http://www.gnome.org/~dvillevalois/libgee/doc/gee-1.0/index.htm Hope this helps. Best regards, Didier. ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Who updates references.valadoc.org?
Hi Magnus, Magnus Therning wrote: I just got around to upgrading to Gee 0.5.0, but references.valadoc.org doesn't seem to have been updated yet so it's all turning out to be a bit more work than I had hoped. Who should I poke to get the Gee reference docs updated? Florian told me he would update it this WE. In the meantime, the New and Noteworthy guide may give some information: http://live.gnome.org/Libgee/NewAndNoteworthy-0.5 And also, there is this migration guide available: http://live.gnome.org/Libgee/Migration-0.5 Finally, there is a documentation directory inside Gee itself since 0.5. (You need to build valadoc for that, available on the gnome git). Configure Gee with --enable-doc, and when make, it will build the valadoc in doc/gee-1.0/. There you'll find quite the same data as on valadoc.org. There might be some glitches however, as we are actively working on valadoc these days. (which is the reason why references.valadoc.org has not been updated recently). Best regards, Didier. ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [ANNOUNCE] Libgee 0.5.0 - GObject collection library
Ildar Mulyukov wrote: Ok. But IMHO you should at least note this somewhere. And, better, put a check in configure.in I only changed it on http://live.gnome.org/Libgee. I'm sorry I should have put it in the release notes. My bad. Best regards, Didier. ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] [ANNOUNCE] Libgee 0.5.0 - GObject collection library
We are very pleased to announce version 0.5.0 of Libgee, the GObject collection library. Libgee 0.5.0 is now available for download at: http://download.gnome.org/sources/libgee/0.5/ Also please note that now Libgee has its own mailing-list http://mail.gnome.org/mailman/listinfo/libgee-list and its own #gee IRC channel. New in 0.5.0 * API changes * Introduce Functions hash, equal and compare function factory * Introduce Comparable interface * Implementations provides defaults when constructed without function * ReadOnly* made internal in favor of a `read_only_view` properties * Iterator is now mutable and resettable * Introduction of BidirIterator bidirectional iterators * List.list_iterator () returns a specialized ListIterator * Various API contracts clarifications and enhancements * Introduce List.sort () with TimSort implementation * Complete Map API rework * Introduce Queue and Deque interfaces * Introduce MultiSet and MultiMap interfaces (Ali Sabil) * Introduce SortedSet interface (Maciej Pietchotka) * New implementations * HashMultiSet and HashMultiMap (Ali Sabil) * TreeMultiSet and TreeMultiMap. * PriorityQueue * LinkedList now implements Deque * TreeSet now implements SortedSet (Maciej Pietchotka) * Infrastructure * New test framework and complete tests refactoring (Julien Peters) * New doc/ documentation directory (--enable-doc) * Test coverage analysis using lcov (--enable-coverage) * Basic benchmark framework and sort benchmark (--enable-benchmark) * Use silent rules by default for users of automake 1.11 * Code Quality * Many bug fixes * Many optimizations * Lots of additional documentation * Better overall encapsulation, public setters have been removed * Better test coverage (more than 90%) For more information about the 0.5.0 release, see: http://live.gnome.org/Libgee/NewAndNoteworthy-0.5 http://live.gnome.org/Libgee/Migration-0.5 Libgee is a collection library providing GObject-based interfaces and classes for commonly used data structures. Libgee provides the following interfaces: * Iterable o Collection + List + Set + MultiSet + Queue # Deque * Iterator * Map * MultiMap The ArrayList, HashSet, HashMap, HashMultiSet, HashMultiMap, LinkedList, PriorityQueue, TreeSet, TreeMap, TreeMultiSet, and TreeMultiMap classes provide a reasonable sample implementation of those interfaces. In addition, a set of abstract classes are provided to ease the implementation of new collections. Around that, the API provide means to retrieve read-only views, efficient sort algorithms, simple, bi-directional or index-based mutable iterators depending on the collection type. Libgee is written in Vala and can be used like any GObject-based C library. It's planned to provide bindings for further languages. More information about Vala is available at http://live.gnome.org/Libgee Didier 'Ptitjes' Villevalois ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Final / Sealed classes in Vala
Hi Jan,
Jan Hudec wrote:
Just like my earlier example with inheriting string, similar reasons apply to
inheriting concrete collection classes. For example a collection of options
would make perfect sense to be a collection plus special constructor or
initialization method to load it from a file and maybe a method to save it
back. Or a collection of headers would make perfect sense to be a collection
that does checks keys are valid identifiers on insertion.
IMHO, for both you examples, composition would be better design choice.
For the all those reasons: encapsulation, reuse and maintainability.
Both these can *almost* be done by delegation, except
- it's a lot more typing, so users will hate you for that, and
Wrong. With the support for events in gee you could do (exact API not
yet defined so please consider this as it is, some pseudo code :p) :
Example 1: Options
public class Options {
private string _filename;
private bool _automatically_save = false;
private Set _options;
private bool _changed = false;
public Set options { get { return _options; }
public Options (string filename, bool automatically_save) {
_options = new HashSet ();
_filename = filename;
_automatically_save = automatically_save;
try_load ();
_options.change.connect (() => {
_changed = true;
});
}
~Options () {
if (_automatically_save) {
commit_changes ();
}
}
// Rest of code would be the same as with inheritance
public void commit_changes () {
if (_changed) {
// ...
_changed = false;
}
}
// ...
}
Example 2: Headers
public class Includes {
private List _headers;
public List headers { get { return _headers; }
public Includes () {
_headers = new ArrayList ();
_headers.insertion.connect ((index, header) => {
check_valid_header (index, header);
});
}
// ...
}
- if some other interface expects the base class, you have to give it the
delegee, but you loose any additional checking.
I guess you obviously understand that by the above design this statement
is simply wrong, as we don't use delegation.
You can argue, that the second case should not happen, because any API should
take the interface, not the class, but all this is about user's who don't
know better, because those who do won't complain when they break things with
incorrect overriding.
'sealed' also for that purpose as noted Micheal. It has documentation
and educative roles. 'sealed' on a class also means:
"Hey you wanted to subclass me ? Guess what ? There is another possible
design. So please stand back and think more about your needs and how you
will achieve them!"
So you can persuade me to agree it makes sense to declare, and ensure, that
particular virtual methods must not be overriden (carefuly -- my second
example involves overriding add!), but I don't buy the argument that the
class as a whole may not be inherited.
I think you mismatch things here. I'm a fervent supporters of design
patterns and the first thing I've read about it is that most of the time
composition is to be preferred to inheritance. The latter only brings
too deep class hierarchies, unmaintainable code and, what is the most
important defect for me, confusion in the head of your users (why the
hell are there so much collection-unrelated methods on that collection ?
what does check_header has to do in a collection class ? ...)
There are Abstract* abstract classes available if one wants to start
a new collection implementation.
I don't want to. I want to add some auxiliary functionality or additional
semantic checks to the otherwise completely standard collection
implementation.
Then compose, by using the observer, wrapper or bridge design patterns
in an appropriate manner depending on your use case.
In anyway, you don't have to interfere with the design and
implementation choices made by the developers of the libraries you use.
('sealed' as a mean to avoid encapsulation failures)
Also it is worth to note that enabling sub-classing on concrete
implementations (like it is now) allows a possible failure because
of the badly-design GObject construction. Thanks to Jakob Kroon to
have pointed that to me.
The GObject system is somewhat strange and it is a little tricky to get the
usage right, but it is possible to implement the classes so they are
always constructed correctly.
Unfortunately this clashes with correct generics initialization. Please
test that by yourself.
And by the way, it has nothing to do with inheritance -- there are many other
cases where creating objects via
Re: [Vala] Final / Sealed classes in Vala
Arto Karppinen wrote: I still think that these kind of problems can be avoided in Vala code by carefully selecting what and when to virtualize. Once again to take the example of Gee. We needed to provide default behaviour for add_all, remove_all, retain_all, ... methods, but wanted concrete implementations to be able to override the default behavior to optimize it for their concrete implementation. This is what is doing ArrayList for add_all for instance. Even so we do not want people to sub-class ArrayList (or any other concrete implementation). Now, tell me how you would enable the same amount of code reuse without sacrificing performance by "carefully selecting what and when to virtualize" ? I'm open to hear any opinions/ideas/advices. I'm sorry if i was unclear. No problem. Best regards, Didier. ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Final / Sealed classes in Vala
Arto Karppinen wrote: For those examples to apply to Vala, you would first have to explicitly allow something to be virtualized, and then explicitly forbid that virtualization, which would to me sound more like a design failure in the framework rather something that Vala should support. Then please explain how you do a multi-level class hierarchy with no virtual methods ? There needs a mean and we've shown plenty uses cases to seal a virtual methods chain. ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Sorting a GLib.List
Hi Magnus, Magnus Therning wrote: What function should I use to sort a list of strings to avoid the compiler warning I get with strcmp: ... my_list.sort( strcmp ); ... Test.vala:60: warning: passing argument 2 of ‘g_list_sort’ from incompatible pointer type /usr/include/glib-2.0/glib/glist.h:101: note: expected ‘GCompareFunc’ but argument is of type ‘int (*)(const char *, const char *)’ You have to explicitly cast it to CompareFunc. Indeed, the GLib.strcmp is just a convenience binding around stdlib's strcmp, and they appear to not have the exact same signatures. IIRC those are: int strcmp (void* a, void* b) gint GCompareFunc (gconstpointer, gconstpointer) However, I would suggest you to use libgee-0.5 which is expected to be (finally) released on Monday September 29, 2009 (or master from git). Gee.List.sort uses an efficient TimSort algorithm, and for free you get: * transparent uses of standard compare funcs for primitive, string and object types * possibility to make your classes inherit Comparable * rid of equal functions at List construction time for primitive, string and object types Best regards, Didier. ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Final / Sealed classes in Vala
Michael B. Trausch wrote: The idea of a sealed/final class can be used to mean a few things: ... To follow Phil with use cases, Libgee would be in great need for final classes and methods. As an example, we would like that concrete collection implementations cannot be sub-classed. The public methods of these implementations all guarantee the respect of API contracts. Also those methods are for most overrides of virtual methods because the framework is made to be extensible and allow future enhancements (possibly by sub-classing). There are Abstract* abstract classes available if one wants to start a new collection implementation. Also it is worth to note that enabling sub-classing on concrete implementations (like it is now) allows a possible failure because of the badly-design GObject construction. Thanks to Jakob Kroon to have pointed that to me. Best regards, Didier. ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Strange Map behaviour in Gee
Magnus Therning wrote: 2009/9/23 Matías De la Puente : Take a look here http://live.gnome.org/Vala/Tutorial#head-7b3930bf3573a66028940bf6123b19e19a33f9a5 should be: var map = new HashMap (str_hash, str_equal); Bugger, yes you are right. I'm such an idiot at times ;-) Starting with the 0.5 version (expected to be release at the end of the week), you won't be forced anymore to provide functions to the implementations almost for (non-boxed) primitive types, strings, and objects. Also in 0.5, a Comparable interface is provided for those who wants to implement order amongst the instance of a class. Best, regards. ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Final / Sealed classes in Vala
Jan Hudec wrote:
On Tue, Sep 22, 2009 at 06:40:10 +0200, Marco Trevisan (Treviño) wrote:
Is it possible to define both in VAPIs and in a vala code a class which
can not be extended?
I mean something like "final" does for Java and "sealed" for C#...
I don't think so. Though some classes are not inheritable because they lack
proper construction functions. That's (unfortunately) the case for most
classes in the GLib namespace.
And I think vala should *NOT* get 'sealed'. It does not need it. In fact, C#
does not need it either -- they added it because Java had 'final', but in
Java it partly replaces missing non-virtual methods. In C# it's mostly
annoying.
I must disagree on this. There are use cases for 'sealed' or 'final' (or
whatever you name it).
For instance you may have an abstract class A that defines some methods
as virtual, a child class B that re-implements some of the virtual
methods of A and that wish the sub-classing to be blocked at its level,
because subclasses would break its behavior by miss-overriding the virtuals.
That's only useful in Java which does not have non-member methods. And even
there the final keyword is useless -- it's static, so it cannot be virtual
and if you call it as Utility.my_method(), you always call that method and
nothing else. Only instance methods may be overriden.
In vala, you just use namespace as:
namespace Utility {
public void my_method();
}
I there is a mix here between two issues:
- static function sets (where namespaces could apply but this is only
one point of view)
- the need to seal some classes to avoid sub-classing
I think the problem to not have it in Vala is more a technical problem
where nothing will avoid C users (in the current GObject) to subclass
the classes that would be marked as sealed in Vala.
Best regards, Didier.
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [Async] why use .begin ?
Jan Hudec wrote: > I didn't notice that thing -- it's indeed good tool for the job. I would > still prefer something to mark in the source that we are synchronizing an > async function. Maybe a .sync() "submethod" to match .begin() and .end() and > state clearly what is happening: .sync() is exactly what I proposed Jürg initially :p ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [Async] why use .begin ?
Jan Hudec wrote: > I can imagine a special syntax that will make vala generate this might be > accepted in future. My suggestion would be > > var result = yield sync foo_async(); I guess I would propose: var result = foo_async(); We talked about that on IRC today with Jürg, and it may be possible to implement such a thing, correctly with g_main_context_push_thread_default() (GLib 2.21). :D ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] libgee on Windows
Hi Mr. Maxwell, Mr. Maxwell . wrote: > I tried putting all the files in a Dev-C++ project and setting these command > line options > compiler-mms-bitfields -ID:/vala-0.7.4/include/glib-2.0 > -ID:/vala-0.7.4/lib/glib-2.0/include > linkerD:/vala-0.7.4/lib/glib-2.0.lib > When I compiled the project I got hundreds of these errors > [Linker error] undefined reference to xyz I don't know well Windows so I can't help you more but I just can tell you that there is no xyz symbol in Gee! Best regards, Didier. ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] removing an element from a list
Jiří Zárevúcky wrote: > If the dependency concerns you, you can simply copy the class you use > into your application. :) Vala compiler itself includes a copy of the > whole library. Jiří, please, remember that Valac includes that code for bootstrap reasons! Libgee is written in Vala. Vala compiler depends on libgee. Libgee's code is only copied inside the Vala compiler code in order to simplify the bootstrap process for packagers and distro maintainers. Copying code inside your application would just give you some more maintainance work to keep that in sync with the library. (Not to mention the plethora of reasons that made us use libraries...) Best regards, Didier. ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [LibGee] LinkedList does not increase stamp
Re Tomaž, Quikee wrote: > In the add and insert methods of LinkedList I saw this two line: > > // Adding items to the list during iterations is allowed. > //++this._stamp; > > Additionally remove_at and/or remove also does not increase the stamp. > > But this is the wrong way to do this! Stamp should be increased always > but the iterator should be changed if you want to allow changing of > the list during iteration. The author of the doubly Linked List, Mark Lee, claimed that items can be added, inserted and removed during iterations. Hence this has been put in comment to "document" the choice. This should IMHO be specified in the valadoc comment. > I would go even further and make stamp a read-only property on the > Collection interface. The trick is that with this "outside" Iterators > could be build - for example a SortedIterator for every Collection. > Such a iterator could then do a to_array and sort the list for the > iteration, but such an iterator needs to know if the collection he > used as the origin was changed from the outside or not. If it was it > should make the iterator invalid and not allow the iteration to > proceed (in whatever way). Such an iterator could be extended to allow > such cases but only through the iterator and not from outside. stamp is an implementation detail. IMHO, we should not make it public. The support for sorted collections (and thus iterator) can be achieved with views: We will support for collection change event notification. Views will be wrapper collections (such as ReadOnly*) that would register to the collection change event notification. I wonder if this covers your use case ? We will have such SortedCollection wrappers in the future. I would like that to become part of the API for libgee 0.7. > BTW. It would be nice if LibGee would have its own mailing list as well. :) Hum... Maybe it is a bit early. If Vala list readers don't mind we will make some noise here for some more time! :) BTW I'd like to thank you a lot for all your contribution. Cheers, Didier. ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [LigGee] remove_all behavior at removing same items
Hi Tomaž! Quikee wrote: > In what way should remove_all work in case of removing the same items. > Currently there is an inconsistency in this behavior from remove_all > on AbstractCollection and the implementation in ArrayList. > The AbstractCollection implementation will call remove for every > element which will in case of n same items in list 1 and m same items > in incoming list 2 remove n-m items. > > For example: > list1 has items 1,1,1,1,1 and list2 has items 1,1,1 > after remove_all in list1 would remain items 1,1 > > The implementation on ArrayList will always remove all items from the > list if the incoming list has such an item. > So in the same example as above list1 after the call would not have any items. > > I have looked also how Java's ArrayList behaves in such a case and it > did behave in a different way as above. The Java's ArrayList treated > the incomming collection as a set and did delete only one element from > the list1. > So the example would look like this: > list1 has items 1,1,1,1,1 and list2 has items 1,1,1 > after remove_all in list1 would remain items 1,1,1,1 > > Which of this behavior would you prefer? That's a good thing you point here. IMHO we should explicit API contracts in the collection interfaces. I would prefer that remove is said to remove the first element. And that remove_all removes every element instances. IMHO this will enable to respect the same API contract for multi-sets. As you can read in Apache Commons Collections, which build upon and derives from Java Collections, their Bag interfaces explicitly override the defined behavior for contains|remove|*All methods. [1] Thus I would prefer if our Collection interface already defines a such API contract: remove_all removes all the element occurrences. In simple sets, it would obviously remove only one instance. Best regards, Didier. [1] http://commons.apache.org/collections/apidocs/org/apache/commons/collections/Bag.html#removeAll(java.util.Collection) ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [Libgee][RFC] Making Map a Collection - Was: Libgee's Roadmap proposal
Levi Bard wrote:
>> - Renaming Map.remove(K key) in Map.unset(K key)
>> - Renaming Map.contains(K key) in Map.has(K key)
>> - Make Map inherit from Collection>
>
> I like unset. "has" is not different enough from "contains" for my
> liking - I can see it being a source of future confusion ("What's the
> difference between contains and has?!").
> How about something that's clearly map-related, the way "unset" is?
> "maps"? "has_set"?
> (For a point of reference, ruby uses "has_key?" and "has_value?".)
Then I would say *get, set, unset, reset, has_key and has_value*...
It seems to me those names are short and expressive. They are coherent
altogether, whereas the actual get, set, remove and contain are really less.
My vote goes to those names.
If we can agree then, I'll make the changes and introduce the
inheritance relationship.
Didier.
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Libgee's Roadmap proposal
Re, Quikee wrote: > Hi, > >>> - is_empty() >> Do we make this a property or a method ? > > I think this should be a method as it generally is only a convenience > method for size property. > >>> - is_empty() >> Same comment as for Collection.is_empty() - property or method ? > > It is the same here as above. But those could equally be represented as a property or method. Properties may only be gettable and have a real function body to be implemented. The only difference is from the point of view of the user, having to add a parenthesis pair or not. >>> - set_all(Map map) >> Do we provide also remove_all and contains_all ? > > Not yet but those make sense. I will add them today. Cool. >>> One observation is that implementation of most of the methods could be >>> generic for all, which means that they could be implemented on the >>> interface itself but maybe it would be better to introduce a common >>> abstract superclass just to keep interfaces clean. >> Yes we have to provide some AbstractCollection and AbstractMap base >> implementations. > > In this case I will provide the implementation because currently the > only common code are those additional methods. In fact I am, at the time we speak, just working on that. So maybe do not introduce the abstract classes, just implement the methods on one of them and I'll will rebase the whole (but keep your authorship). I may push that in the end of the afternoon. >> Could you provide some patches for all the above ? >> >> All the best, Didier. >> > > Of course. I have the changes locally in the git repository. I am new > to git so I don't really (yet) how to provide the changes most > efficiently. But first I will like to clean up the code and write > "vala docs" for the methods properly. Oki :) > One additional thing I had saw what could be improved in the tests is > to provide tests for interfaces itself. For example test for List > interface methods would be the same for all the implementations > ArrayList and LinkedList because they should behave the same anyway. I > saw that most of the test between implementations are anyway > copy/paste which is not efficient when test are added of changed. I > have already made a example how this could be done efficiently but > first I want to finish the first task. That is true. I would also like to enhance that. I had no time for now to do it. We can do that later in another commit. Didier. ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [Libgee][RFC] Making Map a Collection - Was: Libgee's Roadmap proposal
Quikee wrote: > I agree with the proposal but I have already tried to implement a > similar thing like this and every time I tried I had a problem with > iterators get method (I think I have reported this issue in bugzilla > but this might be some time ago). The first thing I would do is to > implement an quick example which would prove that this would work with > Vala and if not report and maybe fix the issues if it exists. What problems did you have with Iterator.get ? (I can't find any bug report for that...) ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] [Libgee][RFC] Making Map a Collection - Was: Libgee's Roadmap proposal
Hi list, I thought a lot about that and I'd like to make the following proposal. Levi Bard wrote: > Why not rename some of the Map methods (contains => contains_key, > remove => remove_key) and then map the Collection methods as-is with G > == Pair? First my proposal will break the API. Libgee being in its development phase, I think there is no problem for that. Libgee 0.2.x release will be available for bug fixes for a while. Current master branch is going towards 0.3.0. Library so names will be changed in order to reflect the API/ABI changes. Also there are already changes pushed in the repo for 0.3.0 that break the API/ABI. So here is the proposal: - Renaming Map.remove(K key) in Map.unset(K key) - Renaming Map.contains(K key) in Map.has(K key) - Make Map inherit from Collection> Please comment and argue ;) Best regards, Didier. ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Libgee's Roadmap proposal
Re Tomaž, Quikee wrote: > Anyway I have partially done this. Now I have added to collection > interface methods: > - is_empty() Do we make this a property or a method ? > - add_all(Collection collection) > - contains_all(Collection collection) > - remove_all(Collection collection) > - retain_all(Collection collection) That fits me. > on list interface: > - first() > - last() OK for that too. > on map interface: > - is_empty() Same comment as for Collection.is_empty() - property or method ? > - set_all(Map map) Do we provide also remove_all and contains_all ? > One observation is that implementation of most of the methods could be > generic for all, which means that they could be implemented on the > interface itself but maybe it would be better to introduce a common > abstract superclass just to keep interfaces clean. Yes we have to provide some AbstractCollection and AbstractMap base implementations. Could you provide some patches for all the above ? All the best, Didier. ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Libgee's Roadmap proposal
Hi list, I tweaked the road map to include more of the things proposed here. I did not include the little stuff, but I'll create tickets for them. The road map is published here: http://live.gnome.org/Libgee/Roadmap Thanks to Julien for its Wiki integration :) As you might note I post-dated the 0.2 release in order to have even minor versions for stable branches, as to follow Vala's versionning way. I will make the 0.2 release during the day or tomorrow, so if you have some last minute bug to correct please chime in. (I'm ptitjes on #vala) Best regards, Didier. # Libgee 0.2 (2009-07-22) * Generate GIR file * Branch for 0.2.x stable release # Libgee 0.3 (2009-08-03) * Deprecate setters for hash and equal functions * Introduce to_array() methods * LinkedList implementation (Mark Lee) * TreeMap and TreeSet implementations (Maciej Piechotka) * MultiMap and MultiSet interfaces and Hash* implementations (Ali Sabil) # Libgee 0.4 (2009-08-17) * Bug fix release * Branch for 0.4.x stable release # Libgee 0.5 (2009-08-31) * Extract Sorted* interfaces from Tree* implementations * LinkedHashMap and LinkedHashSet (with predictable iteration time) * Introduce EnumMap and EnumSet (specialized map|set with enum keys) * Introduce Collections class to host convenience algorithms * Introduce Queue and Stack interfaces and implementations # Libgee 0.6.0 (2009-09-14) * Bug fix release * Branch for 0.6.x stable release # Libgee 0.6.1 (2009-09-28) * Bug fix release # Libgee 0.7.0 (2009-10-12) * Introduce collection change events # Libgee 0.7.1 (2009-10-26) * Introduce WeakHashMap (hash map with weak keys) # Libgee 0.7.2 (2009-11-09) * Updatable views # Libgee 0.7.3 (2009-11-23) * Concurrent collections implementations # Libgee 0.8.0 (2009-12-07) * Bug fix release * Branch for 0.8.x stable release # Libgee 0.9.0 (2010-01-18) * API Freeze # Libgee 0.9.90 (2010-02-01) * Bug fix release # Libgee 0.9.91 (2010-02-15) * Bug fix release # Libgee 0.9.92 (2010-03-01) * Bug fix release # Libgee 1.0.0 (2010-03-15) * Documentation complete ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Libgee's Roadmap proposal
Hi Tomaž,
Quikee wrote:
> Hi,
>
> A little more than a year ago I have made a proposal to extend LibGee
> when I rewrote the tests for it, but at that time there was not much
> interest in the changes. It may be good to repeat what I had in mind
> at that time:
>
>> I would also like to propose an extension to the interfaces in form of
>> additional convenient / often used methods. What I had in mind is this:
>>
>> Collection interface:
>> - void add_all(Collection) - Adds all items from the input collection to
>> this collection. Convenient for joining collections. Java also has this on
>> the interface of Collection.
>> - bool contains_all(Collection) - Checks if all items in the input
>> collection are present in this collection. Convenient for checking items for
>> example if "a" AND "b" exist in collection.
>> - bool contains_any(Collection) - Checks if any items in the input
>> collection are present in this collection. Convenient for checking items for
>> example if "a" OR "b" exist in collection.
>> - bool is_empty() - special state of a collection when it doesn't contain
>> any value. Added because it is clearer as list.size == 0.
>>
>> List interface
>> - G first()
>> - G last() - First and last items are often special - it adds better clarity
>> to the algorithm if they don't need to be "addressed" as list.get(0) or
>> worse list.get(list.size -1).
>>
>> Set interface
>>
>> Map interface
>> - void set_all(Map) - Same as add_all for collections.
>> - expose Node and make it possible to iterate through Nodes:
>> foreach (Node item in map.get_nodes()) {
>> }
>>
>> Iterators
>> - It would be convenient to have a reverse iterator for lists which would
>> also allow to iterate backwards.
>> - class with special iterators/iterables that can iterate Forward /
>> Backwards, skip elements, iterate through enumerated list, generators
>
> Some of the things have already been proposed and there are other
> things on my mind that could be done.
Indeed all those would be very nice contributions!!
> I still have the code of the changes (including tests) somewhere - I
> will seek them out and merge them with the latest libgee version.
I hope you mean rebase :)
> Maybe it would be a good thing to add on the libgee wiki a subpage
> with proposed changes/additions so that all this things aren't
> forgotten.
That would be a good idea, yeah.
Best regards, Didier.
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Libgee's Roadmap proposal
Hi, Jiří Zárevúcky wrote: > 2009/7/21 Didier "Ptitjes" : >> Hi list, >> >> Didier "Ptitjes" wrote: >>> Open questions: >> I'd like to add some more ideas: >> - Support for disengageable collection change events > > Sounds interesting, but I'm not sure about a real value. Often one needs to describe collection changes. One element has been inserted, removed, some elements have been removed. Often, one recreate such a event description classes and listening framework. Offering such a feature at the core of the collections would be a must and avoid that many people do twice the same. Also, based on the GLib signals, firing collection changes feels natural. >> - Support for collection updatable views (aka wrappers) >> - With events and views, we gain a clean implementation way for sorted >> list views > > I don't understand what you mean. Could you explain a bit more? Based on events, one can create a view|wrapper class that registers to its delegate for collection changes. It can then do proper use of the change to keep coherence in the view it gives to the user. Use of this architecture can enable multiple views of the same collection, and thus for instance provide different sortings of the same data. >> - Collection shuffling > > I suppose this would be useful only in very specific applications. This is for sure not a priority at all. >> - Collection reversing > > Definitely a must-have. > >> - Reversed iterations > > The same here. > >> - Collection-based addition|removal (add_all, remove_all, retain_all) >> - ^^^ Same for maps (set_all) > > Maybe we could generalize it a bit and implement some basic set of set > operation (no pun intended). Union, intersection, difference, etc. In > any case, it has to be implemented on the level of Collection > interface. In fact, as shown in C5 documentation, union, intersection, ... set-based operations are implementable with by one call of add_all, remove_all, or retain_all on a Set object. Please look at the C5 documentation for more details. Thus I would prefer to have the basic ones (add_all, remove_all and retain_all) which have proper semantics for all collections. (What does mean union for an arbitrary collection ?) Best regards, Didier. ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Libgee's Roadmap proposal
Hi list, Didier "Ptitjes" wrote: > Open questions: I'd like to add some more ideas: - Support for disengageable collection change events - Support for collection updatable views (aka wrappers) - With events and views, we gain a clean implementation way for sorted list views - Collection shuffling - Collection reversing - Reversed iterations - Collection-based addition|removal (add_all, remove_all, retain_all) - ^^^ Same for maps (set_all) ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Libgee's Roadmap proposal
Hi Julien, Julien Fontanet wrote: > Didier "Ptitjes" writes: >> Yeah. I agree on that, hence my question in the first mail about >> exposing an interface for map entries (that key/value pairs). > > How is that possible, the methods' signatures do not match: > - Collection.add (G item) vs. Map.set (K key, V value) > - Collection.contains (G item) vs. Map.contains (K key) > - Collection.remove (K item) vs. Map.remove (K key) > > Collection implements Iterable which provides this method: Iterator > iterator () whereas it should be Iterator> iterator () for Map. Map could not derive from Collection, but yet it can define a method to return a Collection of Entries: public Collection> get_entries (); I propose that we define a special container Entries, with special properties "key" and "value", and not that we reuse Pair which would have some generically-named properties "e1" and "e2" (or element1, element2). Best regards, Didier. ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Libgee's Roadmap proposal
Hi Mickael Michael 'Mickey' Lauer wrote: > thanks for the update! It's great that someone picks up libgee. ;) >> - Does some want a convenience Tuple (or Pair) class ? > > YES! They're very helpful. What services would you need on such a class ? (Apart from wrapping the two values :)) Best regards, Didier. ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Libgee's Roadmap proposal
Jiří Zárevúcky wrote: > 2009/7/20 Didier "Ptitjes" : >> - Are there some things missing ? >> > > Could you fit in making Map interface a Collection? It is technically > a collection of key-value pairs, and I see no reason why the interface > shouldn't reflect it. :) Yeah. I agree on that, hence my question in the first mail about exposing an interface for map entries (that key/value pairs). If we have no objections or nobody care, then I'll add that to the roadmap. Cheers, Didier. ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Libgee's Roadmap proposal
Hello list, Here is the roadmap I propose for libgee. Obviously I post this to get some feedback. So feel free to comment :) * Libgee 0.2 (2009-08-03) - Generate GIR file - Deprecate setters for hash and equal functions - Introduce to_array() methods - LinkedList implementation (Mark Lee) - TreeMap and TreeSet implementations (Maciej Piechotka) - MultiMap and MultiSet interfaces and Hash* impl. (Ali Sabil) * Libgee 0.3 (2009-08-31) - Extract Sorted* interfaces from Tree* implementations - LinkedHashMap and LinkedHashSet (with predicatable iteration time) - Introduce EnumMap and EnumSet (specialized map|set with enum keys) - Introduce Collections class to host convenience algorithms * Libgee 0.3.1 (2009-09-14) - Bug fix release * Libgee 0.4 (2009-10-12) - Introduce Queue interfaces and implementations - Introduce WeakHashMap (hash map with weak keys) * Libgee 0.5 (2009-11-09) - Concurrent list, set and map implementations ? * Libgee 0.7 (2010-01-18) - API Freeze * Libgee 1.0 (2010-03-15) - Documentation Open questions: - Is a singly linked list of interest ? - Does some want a convenience Tuple (or Pair) class ? - Is exposing an interface for map entries of any use ? - Does one need NavigableMap and NavigableSet Java-like interfaces and implementations (see Java 1.6 collection framework) ? - Are there some things missing ? Best regards, Didier. ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Libgee 0.1.6 - GObject collection library
I am pleased to announce version 0.1.6 of libgee, a GObject collection library. Libgee 0.1.6 is now available for download at: http://ftp.gnome.org/pub/GNOME/sources/libgee/0.1/ Changes since 0.1.5 * Fix build for Vala 0.7. * Bug fixes. libgee is a collection library providing GObject-based interfaces and classes for commonly used data structures. libgee provides the following interfaces: * Iterable o Collection + List + Set * Iterator * Map The ArrayList, HashSet, and HashMap classes provide a reasonable sample implementation of the List, Set, and Map interfaces. ReadOnlyCollection, ReadOnlyList, ReadOnlySet, and ReadOnlyMap are read-only wrapper classes that prevent modification of the underlying collection. libgee is written in Vala and can be used like any GObject-based C library. It's planned to provide bindings for further languages. More information about Vala is available at http://live.gnome.org/Libgee Didier Villevalois ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] libgee release plan?
Hello Heiko, Heiko Stuebner wrote: > are informations about the release plan for libgee 0.1.6 available somewhere? > It is needed for newer freesmartphone.org components, so I would be glad to > know when it will be released. FIY, note that we use a git recipe on shr/import branch of OE. http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/libgee/libgee_git.bb?h=shr/import ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala 0.7.3 & glib <2.14
Andrew Flegg wrote: On Thu, May 28, 2009 at 05:29, Didier "Ptitjes" wrote: [...] No, but the reasoning is as follows: * the build environment runs the same libraries as run on the Internet Tablet [...] I'm sorry but I still don't get the rational for that... it seems like non-sense for me :) [...] Ideally, of course, there'd be a configure switch to turn it off so I don't have to patch out the call to g_regex_split_simple; or a rewrite of the code to not require the 2.14 feature :-) Please do not hesitate to provide a patch for replacing the call. I would apply it without any doubt. :) Best regards, Didier. ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala 0.7.3 & glib <2.14
Andrew Flegg wrote: I was prodded by a user today to update the package of Vala available in maemo.org Extras (allowing Vala apps to be built in the auto-builder and deployed easily to users through the Hildon Application Manager). There is something that I don't get. Do you run valac on your phone ? ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala 0.7.3 & glib <2.14
Andrew Flegg wrote: Unfortunately, 0.7.3 depends on g_regexp_split_simple - which was introduced in glib 2.14. Hum, I'm sorry for that. I'm the one responsible for that mistake... The faulty code is here: http://git.gnome.org/cgit/vala/commit/?id=712d456a7f8ab7ffe3a157c24d0ed16e8bdf33e6 And indeed, I did not change the configure.ac... Best regards, Didier. ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Extension Methods
Hi,
Frederik wrote:
These 'categories' are even named, so you can group these additional
methods thematically. If Vala considers such a feature I would propose
the following syntax:
public class string category SpellChecking {
// ...
}
public class Gtk.Widget category GLFunctionality {
public bool set_gl_capability (...) {
// do stuff.
}
// ...
}
These category names would get lost in C code, but they could be nice
additional information in a Vala object browser.
But then why not using an aspect-orientated notation ?
In aspect-oriented language, inner-type declarations are defined in an
aspect. An aspect, thus, defines correlated functionnality that spans
multiple classes.
public aspect GLFunctionality {
public bool Gtk.Widget.set_gl_capability(...) {
// do stuff...
}
// Some other inner-type declaration
// ...
}
I think that adding syntax to the language should be very carrefully
thought. IHMO, I think that we should stick for now to adding
annotations that would modify the compiler/generator's behavior.
Best regards, Didier.
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Ellipsis syntax (Was: Ellipsis as an argument..)
Hello Shawn!
[Mode Introduction on]
I take benefit of this first post to introduce myself. I did some little
contributions these days to the Vala project, but never subscribed (ouuh
shame!) to the vala-list.
These days, I do mainly work on SHR's projects and in some tinier way to
FSO. At SHR (and FSO), we are massively switching to Vala.
For our own projects, I'm mostly interested in helping Vala for its
compile-time and runtime-time integration of gobject-introspection, and
dbus support (async, errors, ...).
[Mode Introduction off]
So.. You can probably guess my question. I have the need for a method to
take an arbitrary number of args. I know ellipsis' are the key, but
haven't a clue as to how to access them from there. I've looked through
the docs, examples and other's code to no avail. I have seen reference
to va_list, va_state and va_end from within c, but wondered if vala
didn't do some magic and auto cast them as an array object.
..or..
is it more practical/better to just pass those as a single array object?
In either case, I'd love to see the syntax for the ellipsis for my own
curiosity..
I asked the same to Jürg on the channel, and it appears there is only
for now a syntax for typed ellipsis. The following is an example of the
syntax :
public static void foo(params string[] args) {
// ...
}
So if your arguments can be subclasses of GObject, you could use "params
Object[] args".
It appears that there isn't yet any syntax to query about an untyped
ellipsis content. I think this is the best occasion to make proposals.
I have none to propose as the only I know of is the one of Java, and it
is typed as Java supports auto-boxing.
I would be glad to implement it and propose a patch if something gets
consensus. Any ideas ?
Thanks
Shawn
Best regards, Didier.
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
