Re: [Vala] C# Developer

[Daniel Espinosa via vala-list]

Vala is for Gtk/GLib/GObject and recently for C programmers. Is not a good
idea to compare with what C# is and its targets.

As many point out, may is necessary a bounty in order to create a Vala
Language Server, this will push any IED to support Vala.

I would like to take a dive into valadoc code to see if it can provide some
features. Of course, as Christian said some plumbing into Vala is a good
idea, for example, adding Aunknown objects for Symbols, so you can parse
each file and get all symbols declared on it without failing for missing
ones, this is good for autocompletion.

El mar., 9 oct. 2018 a las 17:06,  escribió:

> Sorry that I started this discussion...
>
> What I wanted to make clear is that no C# developer(including me) leaves
> his comfort zone
> for a not-well-functioning IDE, however it may be called.
>
> I was really surprised when I read about it
> "Goodbye Mono, Hello Vala!"
> "ValaForCSharpProgrammers"
> and so on...
> But then came the disillusionment ;-)
>
> The use is for me as if I were back in the Stone Age.(Sorry about this
> comparison)
> And changing my C# projects to Vala seems impossible.
>
>
> No "Swiss army knife" just a IDE specially tailored to vala.
>
>
> Von: bernhard.guil...@begu.org
> Gesendet: 09.10.2018 22:36
> An: 
> Betreff: Re: [Vala] C# Developer
> Hi all,
> I am not sure which part of the thread to misuse but maybe we would be
> good to use something like bountysource or kickstarter to add feature
> wishes.
>
> In my opinion the best way for now is to forget about performance and go
> the language server way. Manly because every IDE can share the code with
> it. Of course it is not perfect and of course some things will still be
> missing. But the good thing about using language server is that it is IDE
> independent and even language independent. Most IDE and editors nowadays
> support language servers. And will continue to support them. A perfect IDE
> is just so far away that anything which will stay longer will be a good
> start. The language server can be extended for things which are not in the
> specification. But currently there is no Vala IDE which is anywhere near at
> the full feature set of the server specification. A specific IDE might die
> but I don't think that editors and IDE will stop to support the language
> server support in the future.
>
> After we are at the point that the compiler is the main problem as
> Christian Hergert pointed out later in this thread. We can add bounties to
> enhance the compiler part. But for now I don't know any IDE for which this
> is the bottleneck?
>
> So there are two servers right now that I know of:
>
> https://github.com/benwaffle/vala-language-server
>
> https://github.com/davidmhewitt/vala-language-server
>
> But both are not easy to use right now. So in my opinion we should look at
> both of them and decide which one we want to support. Add bounties for
> different features and try to convince people and companies using Vala to
> pay a bit of money to get feature sets done.
>
> benwaffle seams to be on this list so what do you think about it? I am not
> sure about davidmhewitt but I think he is on the elementary team which uses
> bountysources already?
>
> Nice pro and cons for language-servers are listed at this blog post [1]
> from a gsoc attempt to add Rust support to Kdevelop.
>
> Tarnyko pointed out that he might be willing to get paid to enhance
> Val(a)IDE. This is also a possible route.
>
> Gnome builder crashes a lot on my system and I cannot get used to the way
> it works, most of the time it is not helping me but is in my way. Mainly
> because it does quite every thing exactly the other way around that I would
> do it. But the builder has also one of the best IDE support for Vala! So it
> might also be a good route.
>
> What do you think which route we should follow?
>
> We are a small community and it would be nice to bundle the efforts to get
> a nice IDE support :)
>
> What the language server also not defines is how to get debugging support
> :/ So this part is IDE/editor dependent. Maybe we can define some API or
> wrapper for how to call gdb from any IDE to fully support Vala? Next big
> thing would be to target embedded systems for which I use Vala most. No IDE
> that I know of has some run on target and debug that damn thing built in. I
> mostly use the command line for this.
>
> My workflow for now is vscode + vala syntax highlight + valadoc + ack +
> command line + meson + gdb. I know all the tools well so I don't really
> miss an IDE but I would like to help to get it started.
>
> Regards,
> Bernhard
>
> 1
> https://perplexinglyemma.blogspot.com/2017/06/language-servers-and-ides.html
>
> wolfgang.ma...@kabelmail.de wrote on 09.10.2018 18:04:
>
> > Maybe the wrong mailing-list ...
> >
> > First of all, I think Vala is good and very performant.
> >
> > I would like to but can not...
> > If a C# developer really (not only for fun) to change to Vala, then
> must

Re: [Vala] I cannot get a simple websocket server working

[Daniel Espinosa]

May you want to take a look at Valum project for web server/development:

http://docs.valum-framework.org/en/latest/

2017-12-17 11:09 GMT-06:00 Marcin Lewandowski :

> Hello,
>
> you need to do any operation that will increase ref count on your conn in
> websocket_handler. Otherwise it will be freed as soon as the handler
> finishes. You can just call conn.ref() but it is no too smart, usually
> better option is to keep e.g. a list of all open connections and adding it
> to the list should automatically increase ref count.
>
> m.
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>



-- 
This electronic message may contain privileged and confidential information
intended only for the use of the addressees named above.  If you are not
the intended recipient of this email, we kindly ask you to delete this
message and any attachment. You are hereby notified that any use,
dissemination, distribution, reproduction of this email is prohibited.  If
you have received this email in error, please notify sender immediately.

Any document, image or any other form of electronic representation of any
work attached to this email, is suitable to be protected by copyright
enforcement by applicable law in your or sender's Country's and
International Legislation

Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Seg Fault when using printf function

[Daniel Espinosa]

Could you file a bug report in bugzilla in order to trace it up to fix it?

El 27/11/2017 1:25 a.m., "Steven Oliver"  escribió:

> Hello,
> I recently upgraded my OS to Ubuntu 17.10 from 16.04 and I think I've
> discovered a bug in Vala.
>
> This commit is now causing my application to crash:
> https://github.com/steveno/balistica/commit/061a28e98f3c4468b4465e580ada78
> f11eec4461?diff=unified
>
> I don't understand what changed in that commit that breaks the
> application with my version of Vala versus the one I had on 16.04, but
> I managed to trace it down to two lines (511 & 513) in
> src/balistica_application.vala (which aren't changed in the diff !!).
> If you comment out those two lines it will compile and produce the
> drag calculation as expected.
>
> I also figured out that if you change those two lines so that the
> printf functions don't format more than two entries, it will also
> compile and produce the expected output. With a third entry, though,
> it seg faults trying to print the calculation results.
>
> Will Seg Fault:
> txtViewDragResults.buffer.text += ("Initial Velocity: %.2f ft/s Zero
> Range: %.2f yards Shooting Angle: %.2f degrees\n").printf (lsln.getMv
> (), lsln.getZerorange (), lsln.getAngle ()) ;
>
> Will print as expected:
> txtViewDragResults.buffer.text += ("Initial Velocity: %.2f ft/s Zero
> Range: %.2f yards\n").printf (lsln.getMv (), lsln.getZerorange ()) ;
>
> I have attached the C code that is generated.
>
> Hopefully that wasn't to confusing. Anyone have any thoughts? Suggestions?
>
> Steven N. Oliver
>
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

[Vala] Fwd: yelp-xsl wip/html5 -> master

[Daniel Espinosa]

This is for valadoc developers.
-- Mensaje reenviado --
De: "Shaun McCance" 
Fecha: 23 may. 2017 10:15 a. m.
Asunto: yelp-xsl wip/html5 -> master
Para: 
Cc:

Finally, I have merged the wip/html5 branch of yelp-xsl to master.
> There will have to be updates to yelp and yelp-tools in this release
> cycle to match.
>
> If you have customizations on top of yelp-xsl (for example, that you
> pass to yelp-build or pintail), you will almost certainly need to
> change them. This is true even if you just changed some CSS. Here's an
> incomplete summary of some of the changes:
>
> * Various divs have been replaced with semantic HTML5 elements like
> article, section, and nav.
>
> * The main page layout uses two flexboxes for layout, the outer
> vertical and the inner horizontal.
>
> * In general, quite a few layouts have been switched to flexbox. For
> example, image tiles are now flexbox instead of inline-block.
>
> * Horizontal max-width and centering happens on more deeply nested
> elements, making it easier to do certain customizations.
>
> * There are no more external images. It's all inline SVG, stylable with
> CSS FTW.
>
> * jQuery has been removed.
>
> * Syntax highlighting has been switched to highlight.js (away from
> jQuery.Syntax). Colorizers are now included by default.
>
> * Speaking of colors, the themes color names are different and more
> extensive. Most of the colors can be computed automatically using color
> algorithms that probably never should have been written in XSLT.
>
>
> Please pass this information along to anybody you think might be
> affected by these changes.
>
> Thanks,
> Shaun
>
> ___
> gnome-doc-list mailing list
> gnome-doc-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-doc-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Roadmap for extending Vala's reach

[Daniel Espinosa]

I agree to move Vala to a modular design.

Vala now should be splitted into:

a) Core
b) Plugin System

*CORE*

Code Parser and AST. This is the one we can push first to a 1.0 release.

*PLUGIN SYSTEM*

Any thing able to use AST, like code generators, documentation generation,
language server for Syntax Highlighting, Code Navigation, Code Completion
an so on.

Some plugins already exists, just need to define a Plugin API and implement
it with existing modules.

This will open to create any CogeGenerator plugin. The already present
CCode is a GObject oriented, maybe to be renamed to GLibCode and splited to
add a GObjectCode and GIOCode all C code generators. This will open
oportunity to create other like PoxisCode and any other one like Rust code.
As pointed out enable using --pkg switches.

Current C Code generator should mature at its own pace, in order to reach a
1.0 in the future.

I really would like to see any other creating plugins for Vala to add Code
generators and Language Servers.




2017-05-19 14:01 GMT-05:00 Guillaume Poirier-Morency <
guillaumepoiriermore...@gmail.com>:

> Le dimanche 07 mai 2017 à 14:05 +1000, Michael Gratton a écrit :
> > Hey Guillaume,
> >
> > I think this is a generally good idea - didn't vala already have
> > some
> > notion of profiles already though?
>
> The notion of profiles has been dropped for maintainability. What I'm
> proposing here is not profiles per-se, but more a modular design with a
> core Vala compiler.
>
> It will also be the basis for general compiler plugins once the libvala
> API will be stabilized.
>
> >
> > In particular I like getting rid of the implicit "using GLib" -
> > explcit
> > is always better. It's especially annoying given every single symbol
> > from all of of GLib, GObject and GIO is crammed into that one
> > namespace.
>
> Same here, I always put "using GLib" to make things clearer.
>
> >
> > WRT --nostdpkg, I kind of wonder if it's a better idea to instead
> > simply bump the major version number and drop backwards compat, so
> > we
> > know that existing projects will continue to compile fine with the
> > old
> > 0.x series, at no additional development overhead cost. Once
> > projects
> > have migrated to having an explicit --pkg=glib-2.0 and "using GLib"
> > then they can just cut over to 1.x of the compiler.
>
> Personally, I think it would be more efficient to make thoses changes
> incrementally and release them continuously to get some solid feedback.
>
> I don't really want to have a pending wip/transform again for years and
> if we decide to make all those in the perspective of a 1.x, it will
> never release.
>
> Let's do what we can do now and make it usable with --nostdpkg and in a
> 1.x, we'll just drop explicit stuff.
>
> >
> > This would also be a good opportunity to split GLib, GObject and GIO
> > up
> > into separate namespaces, which would be more consistent with this
> > suggested approach of using --pkg to enable compiler-specific
> > features.
>
> I'm not so sure about all this. These three already use the same C
> namespace 'g_', so it's already consistent to have them under the same
> Vala namespace.
>
> >
> > //Mike
> >
> --
> Guillaume Poirier-Morency 
>
> Étudiant au baccalauréat en informatique à l'Université de Montréal
> Stagiaire de recherche à l'IRIC
>
> Mon blog: https://arteymix.github.io/
> Clé PGP: B1AD6EA5
>
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
>


-- 
This electronic message may contain privileged and confidential information
intended only for the use of the addressees named above.  If you are not
the intended recipient of this email, we kindly ask you to delete this
message and any attachment. You are hereby notified that any use,
dissemination, distribution, reproduction of this email is prohibited.  If
you have received this email in error, please notify sender immediately.

Any document, image or any other form of electronic representation of any
work attached to this email, is suitable to be protected by copyright
enforcement by applicable law in your or sender's Country's and
International Legislation

Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

[Vala] Fwd: Re: Vala bug management

[Daniel Espinosa]

We have different types of bugs, where users produce compilable code:

A) Incorrect GObject mechanisms applications, in any area related to
construct, signals,
 properties an so or programming errors (including Cush code
assumptions not directly
 supported in Vala yet). They can fixable by the user using code
practices, like code
 conventions and tips.

This kind of things can be documented, as a limitation, in order to
help users to avoid
 this kind of errors.

This bugs can be targeted to 1.2, I think, because Vala can help users
by emitting warnings
 or errors, when possible, but are not a barrier to use Vala in a safe way.

B) Valid Vala code and valid GObject features application, fixable only in Vala.

These should be fixed before 1.0.

These stuff is important, in order to advance and focus resources in
critical issues.

Vala 1.0 is not around the corner, then there is no hurry. Just is
important to clarify users how to use Vala with its limitations.

-- Forwarded message --
From: Rico Tzschichholz 
Date: 2017-02-23 9:37 GMT-06:00
Subject: Fwd: Re: Vala bug management
To: Al Thomas , "Dr. Michael Lauer" 
Cc: Daniel Espinosa 


Just forwarding this to Al and Michael.


 Weitergeleitete Nachricht 
Betreff:Re: Vala bug management
Datum:  Thu, 23 Feb 2017 06:52:59 -0600
Von:    Daniel Espinosa 
An: Rico Tzschichholz 



I really appreciate your time to discuss bug management in private
before to continue.

If you agree, we can stablish following policy:

1) If a bug produce invalid C code should be keep open until it is fixed

2) If bug produce valac segfault then it should be marked as
important-blocker.

3) If bug produce a segfault at runtime but it has a workaround it
should be marked as low-enhancement

4) If bug produce invalid C code but is a programming error derived from
miss understanding on how GObject works, this is, programmer should take
care to avoid, bug should be marked as low-enhancement

Bug reporter should know agreed politics in order to help in marking
their bugs, to reduce load and focus on important bugs.

I'm trying to explain workarounds in bug reports and reporter should do
the same if knowns, this will help others to find help to fix their code.



There are two issues:

A) People have miss understanding about Vala design and may forget to
study GObject before use it

B) Bugzilla have >600 bugs most of them have workarounds, keep noise on
Vala code generation quality

C) There are bugs on bindings but not in valac, they different beast.
May is time to create a repository for bindings and one for Vala

El 23 feb. 2017 12:24 a. m., "Rico Tzschichholz" mailto:ric...@t-online.de>> escribió:

Hello Daniel,

it is great to see your enthusiasm for cleaning up bugzilla!

Unfortunately closing valid bugs as resolved-notabug is not wanted.
Please add comments or request for more feedback or reproducers from the
reporter to fully understand the scope of a bug. Therefore if a provided
test-cases still causes faulty c-code or lets valac throwing errors then
please leave the bug open.

For example https://bugzilla.gnome.org/show_bug.cgi?id=604973
<https://bugzilla.gnome.org/show_bug.cgi?id=604973> -- if some
vala snippet causes the generation of invalid c-code then valac should
detect this and there is a chance to have it fixed.

Best regards,
Rico





-- 
This electronic message may contain privileged and confidential information
intended only for the use of the addressees named above.  If you are not
the intended recipient of this email, we kindly ask you to delete this
message and any attachment. You are hereby notified that any use,
dissemination, distribution, reproduction of this email is prohibited.  If
you have received this email in error, please notify sender immediately.

Any document, image or any other form of electronic representation of any
work attached to this email, is suitable to be protected by copyright
enforcement by applicable law in your or sender's Country's and
International Legislation

Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)


signature.asc
Description: PGP signature
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

[Vala] Vala Tips & Tricks

[Daniel Espinosa]

I've started a new Book on GitBook.com, in order to provide a set of
explanations about how C code is generated by Vala, how to avoid common
errors on classes, methods and interfaces. That will help to finish 1.0
release and leave some of that errors as enhancements in future version of
Vala.

-- 
This electronic message may contain privileged and confidential information
intended only for the use of the addressees named above.  If you are not
the intended recipient of this email, we kindly ask you to delete this
message and any attachment. You are hereby notified that any use,
dissemination, distribution, reproduction of this email is prohibited.  If
you have received this email in error, please notify sender immediately.

Any document, image or any other form of electronic representation of any
work attached to this email, is suitable to be protected by copyright
enforcement by applicable law in your or sender's Country's and
International Legislation

Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] GIO, GVfs, custom isolated URI handler

[Daniel Espinosa]

May you need

https://developer.gnome.org/gio/stable/GMount.html

And if you are planning multi platform development, use file:// Uri instead

El 19 jul. 2016 3:17 a. m., "mar...@saepia.net" 
escribió:

> Hello,
>
> isn't what you are planning an overkill? Are you sure you need a
> filesystem abstraction layer for something that is basically, calling
> stat() a few times?
>
> You may also think about using GResource for compiling all resources and
> linking statically with the app (that makes sense if they are not huge, of
> course).
>
> Marcin
>
> 2016-07-13 11:39 GMT+02:00 Aleksandr Palamar :
>
>> Hi, everyone.
>>
>> I'm kind of new to GLib in general, but already have some basic
>> understanding of how it works. I'm planning to make a game using Vala
>> (which means GLib, GObject and GIO). One of the first things is to make
>> isolated VFS with different mount points on file system, each of has it's
>> own priority while looking for an existing file. I saw that GIO has
>> something for mounting and it's own GVfs, so may I extend/set up them in
>> some way to achieve my goal or that is totally another opera and I would
>> have to reinvent my own bicycle?
>>
>> For example, while asking for file by URI resource://textures/blank.ktx it
>> will try to search for (sorted by priority):
>>
>> ~/.game/mod/textures/blank.ktx
>> ~/.game/base/textures/blank.ktx
>> /opt/game/mod/textures/blank.ktx
>> /opt/game/base/textures/blank.ktx
>> ___
>> vala-list mailing list
>> vala-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/vala-list
>>
>
>
> ___
> gtk-list mailing list
> gtk-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] error: Failed to execute child process (Exec format error)

[Daniel Espinosa]

It appears you have an invalid exe file, may you try to execute valac
--help to see if it valid exe.

Have you latest gib version installed? Because Vala is in line with a
specific GLib/GTK version.
El jun. 16, 2016 8:03 AM, "oyster"  escribió:

> My compiled valac says "error: Failed to execute child process (Exec
> format error)"
> any hints to trace what is the problem?
>
> 1. I have a pre-installed Mingw + msys on my win7 64 bits to compile
> 32bits applications, which can compile CPP/C program without problem.
> pkg-config is avaliable too. And I don't want to install yet another
> mingw+msys since I have installed many libs
>
> 2. Install old vala
> I downloaded vala-0.18.0-mingw32-bin.tar from
> http://linbox.free.fr/vala/, and decompressed it into
> /opt/windows_32/vala-my-build, then I add
> /opt/windows_32/vala-my-build into PATH
>
> 3. test old vala on hello.vala to prove vala-0.18 runs with my mingw+msys
> [I am hello.vala]
> void main()
> {print("hello\n");}
> [/I am hello.vala]
>
> [compile hello]
> $ valac hello.vala
> r:/hello.vala.c: In function 'main':
> r:/hello.vala.c:20:2: warning: 'g_type_init' is deprecated (declared at
> E:/msys/
> opt/windows_32/include/glib-2.0/gobject/gtype.h:681)
> [-Wdeprecated-declarations]
>
>   g_type_init ();
>   ^
> [compile hello]
>
> then run hello.exe
> [run hello.exe]
> $ hello.exe
> hello
> [/run hello.exe]
>
> 4. then download
> https://wiki.gnome.org/Projects/Vala/Release#Vala_0.32.0 and
> decompress it into /r/vala-0.32.0
>
> 5. compile Vala_0.32.0 and install into my mingw+msys
> [compile Vala_0.32.0 and install into my mingw+msys]
> $ cd /r/vala-0.32.0
> $ ./configure --prefix=/opt/windows_32/vala-my-build
> $ make
> $ make install
> [/compile Vala_0.32.0 and install into my mingw+msys]
>
> 6. testing new-compiled vala-0.32 on hello.vala failed
> [test new-compiled vala-0.32]
> $ valac hello.vala
> error: Failed to execute child process (Exec format error)
> error: Failed to execute child process (Exec format error)
> error: Failed to execute child process (Exec format error)
> Compilation failed: 3 error(s), 0 warning(s)
> [/test new-compiled vala-0.32]
>
> 7. in case you want this failed test. Of cause, it can not succeed
> since we have met the faliure in step 6
> [make test]
> $ make test
> cd tests && make  check
> make[1]: Entering directory `/r/vala-0.32.0/tests'
> make  check-am
> make[2]: Entering directory `/r/vala-0.32.0/tests'
> make  check-TESTS
> make[3]: Entering directory `/r/vala-0.32.0/tests'
> TEST: Building...  FAIL
> Compilation failed: 6 error(s), 0 warning(s)
> error: Failed to execute child process (Exec format error)
> error: Failed to execute child process (Exec format error)
> error: Failed to execute child process (Exec format error)
> error: Failed to execute child process (Exec format error)
> error: Failed to execute child process (Exec format error)
> error: Failed to execute child process (Exec format error)
> Makefile:2214: recipe for target `check-TESTS' failed
> make[3]: *** [check-TESTS] Error 1
> make[3]: Leaving directory `/r/vala-0.32.0/tests'
> Makefile:2088: recipe for target `check-am' failed
> make[2]: *** [check-am] Error 2
> make[2]: Leaving directory `/r/vala-0.32.0/tests'
> Makefile:2090: recipe for target `check' failed
> make[1]: *** [check] Error 2
> make[1]: Leaving directory `/r/vala-0.32.0/tests'
> Makefile:968: recipe for target `test' failed
> make: *** [test] Error 2
> [/make test]
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] why valac says "error: Failed to execute child process (Exec format error)"

[Daniel Espinosa]

May you should provide more information about your build environment and
how are you executing valac.

2016-06-15 10:42 GMT-05:00 oyster :

> I am using mingw + msys on win7 64bits. The gcc can compile to produce
> EXE file, and pkg-config can run no problem
>
> I can compile vala_0.32.0 without problem
>
> but when I try to use "valac -v hello.vala" to compile any vala source, I
> find
> [quote]
> Loaded package
> `E:\msys\opt\windows_32\vala-my-build\share/vala-0.32/vapi/glib-2.0.vapi'
> Loaded package
> `E:\msys\opt\windows_32\vala-my-build\share/vala-0.32/vapi/gobject-2.0.vapi'
> error: Failed to execute child process (Exec format error)
> ...
> Compilation failed: 3 error(s), 0 warning(s)
> [/quote]
>
> Any hints to find what is the problem? Thanks
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>



-- 
This electronic message may contain privileged and confidential information
intended only for the use of the addressees named above.  If you are not
the intended recipient of this email, we kindly ask you to delete this
message and any attachment. You are hereby notified that any use,
dissemination, distribution, reproduction of this email is prohibited.  If
you have received this email in error, please notify sender immediately.

Any document, image or any other form of electronic representation of any
work attached to this email, is suitable to be protected by copyright
enforcement by applicable law in your or sender's Country's and
International Legislation

Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] valadoc.org online again, but search not working

[Daniel Espinosa]

Is fairly new made with 0.26 and 0.32.

If valadoc uses vapi files why GIR then?

If you need GIR for C based projects for documentation then may adding a
meta information to avoid GIR for Vala based projects could be very helpful.

I need your to build just for VAPI, including for valadoc.org to get GXml
documentation I online.

Are this bugs in valadoc?
El jun. 6, 2016 5:39 PM, "Chris Daley"  escribió:

> Hi Daniel,
>
> I simply removed the GIR and Valadoc generated the docs from the vapi file
> instead. How old is the GIR file? I came across a few bug reports similar
> to this error for GIR files produced with a much earlier (+/- 0.16) version
> of Vala.
>
> I hope this helps
> Cheers
> Chris
>
> 2016-06-06 14:07 GMT-07:00 Daniel Espinosa :
>
>> Please tell me.
>>
>> Have you fixed my generated GIR and VAPI or fixed valadoc?
>>
>> If fixed valadoc, I should revert my local changes on GXml to API as it
>> was before to avoid breaks.
>>
>> 2016-06-06 13:35 GMT-05:00 Chris Daley :
>>
>>> Hi Daniel,
>>> I have added the GXml 0.10 packages to the valadoc.valadate.org mirror.
>>> You should be able to see them now, otherwise refresh the page.
>>> Cheers
>>> Chris D
>>>
>>> 2016-06-06 11:29 GMT-07:00 Daniel Espinosa :
>>>
>>>> Cheking at your errors, witch I can reproduce locally, but any way I
>>>> found:
>>>>
>>>>
>>>> `callback' in `class' error, means a delegate declared in a class
>>>> namespace, which is valid, but an error is raised.
>>>>
>>>> `field' in `namespace' error, means a globally declared variable make
>>>> public.
>>>>
>>>>
>>>> While in Vala both are Ok, GObject Introspection doesn't complaints
>>>> about them: Is this a valadoc bug?
>>>>
>>>>
>>>> I've made some changes in GXml to fix this, but one of it (hiding
>>>> global variable) requires an API changes, suitable to happen in next 0.12,
>>>> but not in 0.10. While may be this API change should be considered minor,
>>>> most users of GXml relays on legacy DOM support and if they are checking
>>>> errors by this global variable, we are in troubles.
>>>>
>>>> I really wants GXml 0.10 added to valadoc.org or alternate sites,
>>>> while I release 0.12 version. Please consider this questions and make me
>>>> know if is my fault.
>>>>
>>>>
>>>> 2016-06-06 10:40 GMT-05:00 Chris Daley :
>>>>
>>>>> Hi Daniel,
>>>>>
>>>>> This is the error I get when I try to build Valadoc with the
>>>>> GXml-0.10.gir:
>>>>>
>>>>> valadoc --target-glib 2.99 --driver "0.32" --importdir girs --doclet
>>>>> "." -o "tmp/gxml-0.10" "girs/vala/vapi/gxml-0.10.vapi" --vapidir
>>>>> "girs/vala/vapi" --girdir "girs/gir-1.0"  --importdir "girs/gir-1.0"
>>>>> --import GXml-0.10 --wiki documentation/gxml-0.10/wiki
>>>>>
>>>>> (valadoc:279): GLib-CRITICAL **: g_str_has_suffix: assertion 'str !=
>>>>> NULL' failed
>>>>>
>>>>> ** (valadoc:279): CRITICAL **:
>>>>> valadoc_importer_gir_documentation_importer_attach_comment: assertion
>>>>> 'cname != NULL' failed
>>>>> /home/valadoc/girs/gir-1.0/GXml-0.10.gir:5641.3-5641.78: error:
>>>>> unknown child element `callback' in `class'
>>>>> 
>>>>> ^
>>>>> /home/valadoc/girs/gir-1.0/GXml-0.10.gir:10483.2-10483.32: error:
>>>>> unknown child element `field' in `namespace'
>>>>> 
>>>>> ^
>>>>>
>>>>> Cheers
>>>>> Chris
>>>>>
>>>>>
>>>>> 2016-06-06 7:52 GMT-07:00 Daniel Espinosa :
>>>>>
>>>>>> Valadoc.org and its alternatives doesn't load GXml package, could
>>>>>> anyone
>>>>>> point how can help to fix it?
>>>>>> El jun. 6, 2016 9:34 AM, "Ben Iofel"  escribió:
>>>>>>
>>>>>> > For now you may use this mirror with working search:
>>>>>> > http://valadoc.valadate.org
>>>>>> >
>>>>>> > On Mo

Re: [Vala] valadoc.org online again, but search not working

[Daniel Espinosa]

Please tell me.

Have you fixed my generated GIR and VAPI or fixed valadoc?

If fixed valadoc, I should revert my local changes on GXml to API as it was
before to avoid breaks.

2016-06-06 13:35 GMT-05:00 Chris Daley :

> Hi Daniel,
> I have added the GXml 0.10 packages to the valadoc.valadate.org mirror.
> You should be able to see them now, otherwise refresh the page.
> Cheers
> Chris D
>
> 2016-06-06 11:29 GMT-07:00 Daniel Espinosa :
>
>> Cheking at your errors, witch I can reproduce locally, but any way I
>> found:
>>
>>
>> `callback' in `class' error, means a delegate declared in a class
>> namespace, which is valid, but an error is raised.
>>
>> `field' in `namespace' error, means a globally declared variable make
>> public.
>>
>>
>> While in Vala both are Ok, GObject Introspection doesn't complaints about
>> them: Is this a valadoc bug?
>>
>>
>> I've made some changes in GXml to fix this, but one of it (hiding global
>> variable) requires an API changes, suitable to happen in next 0.12, but not
>> in 0.10. While may be this API change should be considered minor, most
>> users of GXml relays on legacy DOM support and if they are checking errors
>> by this global variable, we are in troubles.
>>
>> I really wants GXml 0.10 added to valadoc.org or alternate sites, while
>> I release 0.12 version. Please consider this questions and make me know if
>> is my fault.
>>
>>
>> 2016-06-06 10:40 GMT-05:00 Chris Daley :
>>
>>> Hi Daniel,
>>>
>>> This is the error I get when I try to build Valadoc with the
>>> GXml-0.10.gir:
>>>
>>> valadoc --target-glib 2.99 --driver "0.32" --importdir girs --doclet "."
>>> -o "tmp/gxml-0.10" "girs/vala/vapi/gxml-0.10.vapi" --vapidir
>>> "girs/vala/vapi" --girdir "girs/gir-1.0"  --importdir "girs/gir-1.0"
>>> --import GXml-0.10 --wiki documentation/gxml-0.10/wiki
>>>
>>> (valadoc:279): GLib-CRITICAL **: g_str_has_suffix: assertion 'str !=
>>> NULL' failed
>>>
>>> ** (valadoc:279): CRITICAL **:
>>> valadoc_importer_gir_documentation_importer_attach_comment: assertion
>>> 'cname != NULL' failed
>>> /home/valadoc/girs/gir-1.0/GXml-0.10.gir:5641.3-5641.78: error: unknown
>>> child element `callback' in `class'
>>> 
>>> ^
>>> /home/valadoc/girs/gir-1.0/GXml-0.10.gir:10483.2-10483.32: error:
>>> unknown child element `field' in `namespace'
>>> 
>>> ^
>>>
>>> Cheers
>>> Chris
>>>
>>>
>>> 2016-06-06 7:52 GMT-07:00 Daniel Espinosa :
>>>
>>>> Valadoc.org and its alternatives doesn't load GXml package, could anyone
>>>> point how can help to fix it?
>>>> El jun. 6, 2016 9:34 AM, "Ben Iofel"  escribió:
>>>>
>>>> > For now you may use this mirror with working search:
>>>> > http://valadoc.valadate.org
>>>> >
>>>> > On Mon, Jun 6, 2016 at 6:08 AM Ulink  wrote:
>>>> >
>>>> > > Hi,
>>>> > >
>>>> > > valadoc.org seems online again, but if one type something into the
>>>> > > search field, it shows:
>>>> > >
>>>> > > 'Query failed: (0)s'
>>>> > >
>>>> > > Is someone able to fix this?
>>>> > >
>>>> > > --
>>>> > > Bernhard
>>>> > > ___
>>>> > > vala-list mailing list
>>>> > > vala-list@gnome.org
>>>> > > https://mail.gnome.org/mailman/listinfo/vala-list
>>>> > >
>>>> > ___
>>>> > vala-list mailing list
>>>> > vala-list@gnome.org
>>>> > https://mail.gnome.org/mailman/listinfo/vala-list
>>>> >
>>>> ___
>>>> vala-list mailing list
>>>> vala-list@gnome.org
>>>> https://mail.gnome.org/mailman/listinfo/vala-list
>>>>
>>>
>>>
>>>
>>> --
>>> Chris Daley
>>> Pacific Northwest
>>>
>>> e: chebiza...@gmail.com
>>> w: http://chrisdaley.biz
>>> m: +1-971-703-9251
&g

Re: [Vala] valadoc.org online again, but search not working

[Daniel Espinosa]

Cheking at your errors, witch I can reproduce locally, but any way I found:


`callback' in `class' error, means a delegate declared in a class
namespace, which is valid, but an error is raised.

`field' in `namespace' error, means a globally declared variable make
public.


While in Vala both are Ok, GObject Introspection doesn't complaints about
them: Is this a valadoc bug?


I've made some changes in GXml to fix this, but one of it (hiding global
variable) requires an API changes, suitable to happen in next 0.12, but not
in 0.10. While may be this API change should be considered minor, most
users of GXml relays on legacy DOM support and if they are checking errors
by this global variable, we are in troubles.

I really wants GXml 0.10 added to valadoc.org or alternate sites, while I
release 0.12 version. Please consider this questions and make me know if is
my fault.


2016-06-06 10:40 GMT-05:00 Chris Daley :

> Hi Daniel,
>
> This is the error I get when I try to build Valadoc with the GXml-0.10.gir:
>
> valadoc --target-glib 2.99 --driver "0.32" --importdir girs --doclet "."
> -o "tmp/gxml-0.10" "girs/vala/vapi/gxml-0.10.vapi" --vapidir
> "girs/vala/vapi" --girdir "girs/gir-1.0"  --importdir "girs/gir-1.0"
> --import GXml-0.10 --wiki documentation/gxml-0.10/wiki
>
> (valadoc:279): GLib-CRITICAL **: g_str_has_suffix: assertion 'str != NULL'
> failed
>
> ** (valadoc:279): CRITICAL **:
> valadoc_importer_gir_documentation_importer_attach_comment: assertion
> 'cname != NULL' failed
> /home/valadoc/girs/gir-1.0/GXml-0.10.gir:5641.3-5641.78: error: unknown
> child element `callback' in `class'
> 
> ^
> /home/valadoc/girs/gir-1.0/GXml-0.10.gir:10483.2-10483.32: error: unknown
> child element `field' in `namespace'
> 
> ^
>
> Cheers
> Chris
>
>
> 2016-06-06 7:52 GMT-07:00 Daniel Espinosa :
>
>> Valadoc.org and its alternatives doesn't load GXml package, could anyone
>> point how can help to fix it?
>> El jun. 6, 2016 9:34 AM, "Ben Iofel"  escribió:
>>
>> > For now you may use this mirror with working search:
>> > http://valadoc.valadate.org
>> >
>> > On Mon, Jun 6, 2016 at 6:08 AM Ulink  wrote:
>> >
>> > > Hi,
>> > >
>> > > valadoc.org seems online again, but if one type something into the
>> > > search field, it shows:
>> > >
>> > > 'Query failed: (0)s'
>> > >
>> > > Is someone able to fix this?
>> > >
>> > > --
>> > > Bernhard
>> > > ___
>> > > vala-list mailing list
>> > > vala-list@gnome.org
>> > > https://mail.gnome.org/mailman/listinfo/vala-list
>> > >
>> > ___
>> > vala-list mailing list
>> > vala-list@gnome.org
>> > https://mail.gnome.org/mailman/listinfo/vala-list
>> >
>> ___
>> vala-list mailing list
>> vala-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/vala-list
>>
>
>
>
> --
> Chris Daley
> Pacific Northwest
>
> e: chebiza...@gmail.com
> w: http://chrisdaley.biz
> m: +1-971-703-9251
> s: chebizarro
> tw: chebizarro
> tz: PDT
>
>


-- 
This electronic message may contain privileged and confidential information
intended only for the use of the addressees named above.  If you are not
the intended recipient of this email, we kindly ask you to delete this
message and any attachment. You are hereby notified that any use,
dissemination, distribution, reproduction of this email is prohibited.  If
you have received this email in error, please notify sender immediately.

Any document, image or any other form of electronic representation of any
work attached to this email, is suitable to be protected by copyright
enforcement by applicable law in your or sender's Country's and
International Legislation

Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] valadoc.org online again, but search not working

[Daniel Espinosa]

Valadoc.org and its alternatives doesn't load GXml package, could anyone
point how can help to fix it?
El jun. 6, 2016 9:34 AM, "Ben Iofel"  escribió:

> For now you may use this mirror with working search:
> http://valadoc.valadate.org
>
> On Mon, Jun 6, 2016 at 6:08 AM Ulink  wrote:
>
> > Hi,
> >
> > valadoc.org seems online again, but if one type something into the
> > search field, it shows:
> >
> > 'Query failed: (0)s'
> >
> > Is someone able to fix this?
> >
> > --
> > Bernhard
> > ___
> > vala-list mailing list
> > vala-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/vala-list
> >
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] GXml 0.10.0 Released

[Daniel Espinosa]

What version of GXml are you using? Witch version of libvala and valadoc do
you have?

For documentation I'm trying to push it to valadoc.org, but some thing is
missing. I've upload, I think, all filest they require to have GXml
documentation on line, but for some reason it is not and not feed back from
maintainers.

As you can see at:

https://github.com/esodan/valadoc-org/blob/master/documentation/packages.xml

and

https://github.com/nemequ/vala-girs/blob/master/gir-1.0/GXml-0.10.gir

But any way, may I can help you on build your own documentation.


2016-05-26 14:32 GMT-05:00 Günther Wutz :

> Is there somewhere a documentation for GXml? I tried to compile it
> myself but i am stuck with an error "failed to load driver". I tried
> the examples provided by GXml but they are outdated.
>
> new Document.from_gfile(f, can)
> should be
> Document.new_default_for_file(f);
>
> and doc.to_string(true, 8)
> should be
> doc.to_string();
>
> I was irritated by the Nodes "#text" without a value - is there a
> reason they exists?
>
>
>
> Am Donnerstag, den 14.04.2016, 11:16 -0500 schrieb Daniel Espinosa:
> > GXml provides a GObject API for manipulating XML and a Serializable
> > framework to XML.
> >
> > Currently, GXml provides the DOM Level 1 Core API, Basic HTML
> > support,
> > Serialization.
> >
> > Provides a set of interfaces to access XML equivalent files with
> > different
> > implementations, some of them based on libxml but able to use
> > different
> > backends.
> >
> > It is written in Vala, but provides C API, while it is available to
> > other
> > high level
> > languages, like Python or JavaScript, using GObject Introspection.
> >
> >
> > ChangeLog
> >
> >
> > ===
> > Version 0.10.0
> > ===
> >
> >
> > * New and updated translations:
> > Added zh_CN by Yating Kuang 
> > Updated Swedish by Anders Jonsson  > n.se>
> > Updated German  by Mario Blättermann  > l.com>
> > Updated Brazilian Portuguese by Enrico Nicoletto  > om>
> > Updated Czech   by Marek Černocký 
> > Updated Serbian by Марко М. Костић 
> > Updated Hungarian   by Balázs Meskó 
> > Updated Polish  by Piotr Drąg 
> >
> >
> > ===
> > Version 0.9.92
> > ===
> >
> > * New contructor methods for TDocument using custome ReadTypeFunc
> > * Bug fixes
> > * New and updated translations:
> > Updated Polish  by Piotr Drąg 
> > Updated Serbian by Мирослав Николић  > il.com>
> >
> > ==
> > Version 0.9.90 and 0.9.91
> > ==
> >
> > * New TDocument.from_stream(), .from_string and .from_uri() methods
> > * API change TwNode and derived classes renamed to TNode
> > * Added parse capabilities to TDocument
> > * Improved performance tests, pointing: GDocument has better memory
> > usage
> > and
> >   better performance than xDocument; TDocument has better performance
> > but
> > more
> >   memory usage than GDocument.
> > * Bug fixes
> > * New and updated translations:
> > Added Hungarian  by Matej Urbančič  > org>
> > Added Slovenian  by Matej Urbančič  > org>
> > Added Greek  by Γιάννης Κουτσούκος  > l.com>
> > Added Swedishby Anders Jonsson <
> > anders.jons...@norsjovallen.se>
> > Updated Czechby Marek Černocký 
> > Updated Brazilian Portuguese by Rafael Fontenelle  > .org>
> >
> >
> > ===
> > Version 0.9.2
> > ===
> >
> > * API change Serializable.deserialize now return a boolean
> >
> > * API change SerializableCollection: added new abstract methods for
> > post-deserialization
> >
> > * SerializableCollection: Implementations now support enable/disable
> > deserialization
> >   for post-deseralization using
> > SerializableCollection.deserialize_children() for initial
> >   document load time optimization
> >
> > * More memory optimizations: SerializableCollection implementations
> > don't
> > hold
> >   objects for unknown properties/nodes
> >
> >
> >
> > ===
> > Version 0.9.1
> > ===
> >
> > * Added GXml.Node.parent property
> > * Performance measuring: GDocument equivalent to xDocument
> > * 

Re: [Vala] Extended floating types

[Daniel Espinosa]

May this even better, by using a specialized math library written in C with
bindings for Vala.

We can wrap this library in GObject classes, then create Vala bindings and
GObject Introspection ones for other languages like Python.

If Vala bindings exists, we can create GObject wrappers written in Vala,
like we do at GXml for libxml2.
El may. 24, 2016 10:01 AM, "ben"  escribió:

> This does not work. The C code has: typedef float float128_t;
>
> You could map it to gcc's 128 bit floating point type (https://gcc.gnu.
> org/onlinedocs/gcc/Floating-Types.html) or use the 80-bit long double
> type (https://stackoverflow.com/questions/13516476/long-double-gcc-spec
> ific-and-float128)
>
> Neither of these options are standard. For arbitrary precision math in
> C I like to use https://gmplib.org/.
>
>
>
> On Mon, 2016-05-23 at 21:26 -0500, Guillaume Poirier-Morency wrote:
> > It's possible to declare these types if you need to use them.
> >
> > https://wiki.gnome.org/Projects/Vala/Manual/Attributes#FloatingType_A
> > tt
> > ribute
> >
> > [CCode (has_type_id = false)]
> > [FloatingType (decimal = false, rank = 12, width = 128]
> > struct float128_t {}
> >
> > Like Daniel said, Vala primitive types are mapped to GLib's type with
> > the GType system, so it's not really the language's fault if there is
> > no support for 128 bit floating points. It's not a common use case
> > either way.
> >
> > With 'has_type_id = false', the compiler knows that there's no type
> > information to retreive.
> >
> > Rank 12 does not really exist, but that would be the appropriate
> > value
> > since 10 and 11 are for signed and unsigned 64 bit types.
> >
> > It might be handy to have a VAPI for that in 'vala-extra-vapis'.
> >
> > Cheers and best luck,
> >
> > Le lundi 23 mai 2016 à 09:59 +0300, Vitaly V. Ch a écrit :
> > > Ok, Thanks.
> > >
> > > It clarifies the situation.
> > >
> > > With best regards,
> > >
> > > Vitaly Chernooky
> > >
> > > On Mon, May 23, 2016 at 4:51 AM, Daniel Espinosa 
> > > wrote:
> > >
> > > > May you should be able to create your own basic type.
> > > >
> > > > May should be a guide to do so.
> > > >
> > > > GLib should have this types too, before you are able to create
> > > > your
> > > > basic
> > > > types. This means you should define a GType for a basic type, in
> > > > this case
> > > > your long double.
> > > >
> > > > May we can create a library to define this math basic types, to
> > > > be
> > > > used in
> > > > other libraries. This is not a GLib interest, I think, because is
> > > > not a
> > > > primary Math library.
> > > >
> > > > I was working a little in that, but may you should ask to gtk-
> > > > list
> > > > for
> > > > help on defining this new types.
> > > >
> > > > In other ideas, is required to use that types or is possible to
> > > > use
> > > > some
> > > > structs holding your information in a way to be used in other
> > > > methods, that
> > > > may take that structs an do calculations using that types
> > > > internally,
> > > > written in C with Vala bindings [1], then return again that
> > > > structs.
> > > >
> > > > [] See git.gnome.org/browse/gxml it uses simple C methods and
> > > > Vala
> > > > bindings to be used in Vala code for xlibxml
> > > > El may. 22, 2016 3:23 PM, "Vitaly V. Ch" 
> > > > escribió:
> > > >
> > > > Hi All!
> > > >
> > > > Some time ago Vala has pulled my attention as a way to solve some
> > > > kind of
> > > > math problems. But some time later I realized that this cozy and
> > > > beautiful
> > > > staff does not have extended floating datatypes such as long
> > > > double
> > > > or
> > > > float128_t. This fact disappointed me and I'm interested in some
> > > > comments.
> > > >
> > > > With best regards,
> > > >
> > > > Vitaly Chernooky
> > > > ___
> > > > vala-list mailing list
> > > > vala-list@gnome.org
> > > > https://mail.gnome.org/mailman/listinfo/vala-list
> > > >
> > > >
> > > ___
> > > vala-list mailing list
> > > vala-list@gnome.org
> > > https://mail.gnome.org/mailman/listinfo/vala-list
> > ___
> > vala-list mailing list
> > vala-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/vala-list
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Extended floating types

[Daniel Espinosa]

Yes please, file a bug.

May discussion can continue on it.
El may. 24, 2016 6:55 AM, "Vitaly V. Ch" 
escribió:

> It will be good if I create a tiket in Bugzilla?
>
> With best regards,
>
> Vitaly
>
> On Tue, May 24, 2016 at 1:04 PM, Daniel Espinosa  wrote:
>
>> May we need to file a bug report against this issue, in order to help
>> others to use Vala in different applications when needed.
>> El may. 23, 2016 9:27 PM, "Guillaume Poirier-Morency" <
>> guillaumepoiriermore...@gmail.com> escribió:
>>
>> > It's possible to declare these types if you need to use them.
>> >
>> > https://wiki.gnome.org/Projects/Vala/Manual/Attributes#FloatingType_Att
>> > ribute
>> >
>> > [CCode (has_type_id = false)]
>> > [FloatingType (decimal = false, rank = 12, width = 128]
>> > struct float128_t {}
>> >
>> > Like Daniel said, Vala primitive types are mapped to GLib's type with
>> > the GType system, so it's not really the language's fault if there is
>> > no support for 128 bit floating points. It's not a common use case
>> > either way.
>> >
>> > With 'has_type_id = false', the compiler knows that there's no type
>> > information to retreive.
>> >
>> > Rank 12 does not really exist, but that would be the appropriate value
>> > since 10 and 11 are for signed and unsigned 64 bit types.
>> >
>> > It might be handy to have a VAPI for that in 'vala-extra-vapis'.
>> >
>> > Cheers and best luck,
>> >
>> > Le lundi 23 mai 2016 à 09:59 +0300, Vitaly V. Ch a écrit :
>> > > Ok, Thanks.
>> > >
>> > > It clarifies the situation.
>> > >
>> > > With best regards,
>> > >
>> > > Vitaly Chernooky
>> > >
>> > > On Mon, May 23, 2016 at 4:51 AM, Daniel Espinosa 
>> > > wrote:
>> > >
>> > > > May you should be able to create your own basic type.
>> > > >
>> > > > May should be a guide to do so.
>> > > >
>> > > > GLib should have this types too, before you are able to create your
>> > > > basic
>> > > > types. This means you should define a GType for a basic type, in
>> > > > this case
>> > > > your long double.
>> > > >
>> > > > May we can create a library to define this math basic types, to be
>> > > > used in
>> > > > other libraries. This is not a GLib interest, I think, because is
>> > > > not a
>> > > > primary Math library.
>> > > >
>> > > > I was working a little in that, but may you should ask to gtk-list
>> > > > for
>> > > > help on defining this new types.
>> > > >
>> > > > In other ideas, is required to use that types or is possible to use
>> > > > some
>> > > > structs holding your information in a way to be used in other
>> > > > methods, that
>> > > > may take that structs an do calculations using that types
>> > > > internally,
>> > > > written in C with Vala bindings [1], then return again that
>> > > > structs.
>> > > >
>> > > > [] See git.gnome.org/browse/gxml it uses simple C methods and Vala
>> > > > bindings to be used in Vala code for xlibxml
>> > > > El may. 22, 2016 3:23 PM, "Vitaly V. Ch" 
>> > > > escribió:
>> > > >
>> > > > Hi All!
>> > > >
>> > > > Some time ago Vala has pulled my attention as a way to solve some
>> > > > kind of
>> > > > math problems. But some time later I realized that this cozy and
>> > > > beautiful
>> > > > staff does not have extended floating datatypes such as long double
>> > > > or
>> > > > float128_t. This fact disappointed me and I'm interested in some
>> > > > comments.
>> > > >
>> > > > With best regards,
>> > > >
>> > > > Vitaly Chernooky
>> > > > ___
>> > > > vala-list mailing list
>> > > > vala-list@gnome.org
>> > > > https://mail.gnome.org/mailman/listinfo/vala-list
>> > > >
>> > > >
>> > > ___
>> > > vala-list mailing list
>> > > vala-list@gnome.org
>> > > https://mail.gnome.org/mailman/listinfo/vala-list
>> > --
>> > Guillaume Poirier-Morency 
>> >
>> > Étudiant au baccalauréat en Informatique à l'Université de Montréal
>> > Développeur d'application web
>> >
>> > Mon blog: https://arteymix.github.io/
>> > Mon projet de coopérative: https://pittoresque.github.io/
>> > Clé PGP: B1AD6EA5
>> > ___
>> > vala-list mailing list
>> > vala-list@gnome.org
>> > https://mail.gnome.org/mailman/listinfo/vala-list
>> >
>> >
>> ___
>> vala-list mailing list
>> vala-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/vala-list
>>
>
>
>
> --
> \\wbr Vitaly
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Extended floating types

[Daniel Espinosa]

May we need to file a bug report against this issue, in order to help
others to use Vala in different applications when needed.
El may. 23, 2016 9:27 PM, "Guillaume Poirier-Morency" <
guillaumepoiriermore...@gmail.com> escribió:

> It's possible to declare these types if you need to use them.
>
> https://wiki.gnome.org/Projects/Vala/Manual/Attributes#FloatingType_Att
> ribute
>
> [CCode (has_type_id = false)]
> [FloatingType (decimal = false, rank = 12, width = 128]
> struct float128_t {}
>
> Like Daniel said, Vala primitive types are mapped to GLib's type with
> the GType system, so it's not really the language's fault if there is
> no support for 128 bit floating points. It's not a common use case
> either way.
>
> With 'has_type_id = false', the compiler knows that there's no type
> information to retreive.
>
> Rank 12 does not really exist, but that would be the appropriate value
> since 10 and 11 are for signed and unsigned 64 bit types.
>
> It might be handy to have a VAPI for that in 'vala-extra-vapis'.
>
> Cheers and best luck,
>
> Le lundi 23 mai 2016 à 09:59 +0300, Vitaly V. Ch a écrit :
> > Ok, Thanks.
> >
> > It clarifies the situation.
> >
> > With best regards,
> >
> > Vitaly Chernooky
> >
> > On Mon, May 23, 2016 at 4:51 AM, Daniel Espinosa 
> > wrote:
> >
> > > May you should be able to create your own basic type.
> > >
> > > May should be a guide to do so.
> > >
> > > GLib should have this types too, before you are able to create your
> > > basic
> > > types. This means you should define a GType for a basic type, in
> > > this case
> > > your long double.
> > >
> > > May we can create a library to define this math basic types, to be
> > > used in
> > > other libraries. This is not a GLib interest, I think, because is
> > > not a
> > > primary Math library.
> > >
> > > I was working a little in that, but may you should ask to gtk-list
> > > for
> > > help on defining this new types.
> > >
> > > In other ideas, is required to use that types or is possible to use
> > > some
> > > structs holding your information in a way to be used in other
> > > methods, that
> > > may take that structs an do calculations using that types
> > > internally,
> > > written in C with Vala bindings [1], then return again that
> > > structs.
> > >
> > > [] See git.gnome.org/browse/gxml it uses simple C methods and Vala
> > > bindings to be used in Vala code for xlibxml
> > > El may. 22, 2016 3:23 PM, "Vitaly V. Ch" 
> > > escribió:
> > >
> > > Hi All!
> > >
> > > Some time ago Vala has pulled my attention as a way to solve some
> > > kind of
> > > math problems. But some time later I realized that this cozy and
> > > beautiful
> > > staff does not have extended floating datatypes such as long double
> > > or
> > > float128_t. This fact disappointed me and I'm interested in some
> > > comments.
> > >
> > > With best regards,
> > >
> > > Vitaly Chernooky
> > > ___
> > > vala-list mailing list
> > > vala-list@gnome.org
> > > https://mail.gnome.org/mailman/listinfo/vala-list
> > >
> > >
> > ___
> > vala-list mailing list
> > vala-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/vala-list
> --
> Guillaume Poirier-Morency 
>
> Étudiant au baccalauréat en Informatique à l'Université de Montréal
> Développeur d'application web
>
> Mon blog: https://arteymix.github.io/
> Mon projet de coopérative: https://pittoresque.github.io/
> Clé PGP: B1AD6EA5
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Extended floating types

[Daniel Espinosa]

May you should be able to create your own basic type.

May should be a guide to do so.

GLib should have this types too, before you are able to create your basic
types. This means you should define a GType for a basic type, in this case
your long double.

May we can create a library to define this math basic types, to be used in
other libraries. This is not a GLib interest, I think, because is not a
primary Math library.

I was working a little in that, but may you should ask to gtk-list for help
on defining this new types.

In other ideas, is required to use that types or is possible to use some
structs holding your information in a way to be used in other methods, that
may take that structs an do calculations using that types internally,
written in C with Vala bindings [1], then return again that structs.

[] See git.gnome.org/browse/gxml it uses simple C methods and Vala bindings
to be used in Vala code for xlibxml
El may. 22, 2016 3:23 PM, "Vitaly V. Ch"  escribió:

Hi All!

Some time ago Vala has pulled my attention as a way to solve some kind of
math problems. But some time later I realized that this cozy and beautiful
staff does not have extended floating datatypes such as long double or
float128_t. This fact disappointed me and I'm interested in some comments.

With best regards,

Vitaly Chernooky
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Is there any usable editor for Vala?

[Daniel Espinosa]

Just pointing out that you may want to use GNOME Builder 3.20.4, it is
stable enough and have basic autocompletion.

Check out at:

https://blogs.gnome.org/despinosa/2016/05/10/using-gnome-builder-for-vala-development/

2016-05-17 10:17 GMT-05:00 Ralph Plawetzki :

> Dear list,
>
> Am 14.02.2016 um 13:02 schrieb Andy Lees:
> > haven't tried it.  Make sure you set the ctags executable to use
> > anjuta-ctags (installed with Anjuta), which understands vala code and
> > generates suitable tags files.
>
> I am on Arch linux 64bit, so do have a current stack installed.
> In sublime 2 the CTags plugin is installed and configured with:
> // Path to ctags executable.
> ...
> "command": "/usr/bin/anjuta-tags",
>
> When I use Navigate to Definition via right click in a vala file of a
> cloned project, sublime allways comes back with Can't find any relevant
> tags file.
>
> How can this be solved - what else needs to be configured?
>
> Thanks,
> Ralph
>
>
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
>


-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] [PATCH] three small patches

[Daniel Espinosa]

May you should file a bug for each. They are sent to maintainers and
provides tools to discuss and review your patchs.
El may. 16, 2016 7:59 AM, "Matthias Berndt" 
escribió:

> Hey guys,
>
> Here are three patches I'd like to see in master.
> The first adds two missing cases in TokenType's to_string method.
>
> The second fixes a type checker bug that allows generic classes that are
> applied to the
> wrong number of type arguments to pass type checking. Example:
> class Foo {}
> void main(string[] args) {
>   Foo > foo = null;
> }
>
> The third sets the parent_node correctly for base types in a class
> declaration.
> I haven't found an actual bug caused by this, but it clearly seems like
> the right
> thing to do.
>
> Let me know what you think!
> Cheers,
> Matthias
>
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Getting all the symbols from my code

[Daniel Espinosa]

Yes is a great idea, let me know if I can help
El may. 8, 2016 7:01 AM, "Dmitry Golovin"  escribió:

> 07.05.2016, 15:35, "Al Thomas" :
> >>  From: Dmitry Golovin 
> >>  Sent: Saturday, 7 May 2016, 9:01
> >>  Subject: [Vala] Getting all the symbols from my code
> >>
> >>  I want to have a list of all the symbols from my code.
> >>
> >>  First I create a CodeContext, then I add all the external packages and
> source
> >>  files, then visit each file with a Parser.
> >>
> >>  I expect to get all the CodeNodes from my code, but I only get the
> top-level
> >
> >>  ones. Is it possible to get all the children of each CodeNode?
> >
> > You probably want to be looking at a CodeVisitor. So this file
> >
> > I think writes out Vala symbols for a VAPI:
> > https://git.gnome.org/browse/vala/tree/vala/valacodewriter.vala
> >
> > I understand other tools have done similar to what you are attempting:
> > https://git.gnome.org/browse/anjuta/tree/plugins/language-support-vala
> > https://git.gnome.org/browse/gnome-builder/tree/plugins/vala-pack
> >
> > Given a lot of IDE tools are re-implementing this there is probably
> > a case for a libvalaidetools that talks to libvala and provides a stable
> > API. That would be a signifiant project. I would suggest the Vala build
> > system also be switched to non-recursive make first so it is easier to
> > add any new code.
> >
> > Al
>
> Thanks for the code reference, Al! I will check it out.
>
> For now I created some kind of Type detection, but I'm not sure if it is
> done right. Here is my code (please excuse formatting, I think it is more
> readable this way if you use monotype font):
>
> foreach (var src in context.get_source_files()) {
> print("\n" + src.get_relative_filename() + ":\n");
> foreach (var node in src.get_nodes()) {
> print(node.to_string() + " -- ");
> if (node is Expression) {
>  print("Expression");
> } else if (node is Symbol) {print("Symbol
> ");
> if (node is Constant) {
>  print("Constant");
> } else if (node is Namespace) {
>  print("Namespace");
> } else if (node is Subroutine) {
> print("Subroutine ");
> if (node is Constructor) {
> print("Constructor");
> } else if (node is Destructor) {
> print("Destructor");
> } else if (node is Method) {
> print("Method");
> } else if (node is PropertyAccessor) {
> print("PropertyAccessor");
> } else {
> print("-"); }
> } else if (node is TypeSymbol) {
> print("TypeSymbol ");
> if (node is Delegate) {
>  print("Delegate");
> } else if (node is Enum) {
> print("Enum");
> } else if (node is ErrorCode) {
>  print("ErrorCode");
> } else if (node is ErrorDomain) {
>  print("ErrorDomain");
> } else if (node is ObjectTypeSymbol) {
> print("ObjectTypeSymbol ");
> if (node is Class) {
> print("Class");
> } else if (node is Interface) {
>  print("Interface");
> } else {
> print("-"); }
> } else if (node is Struct) {
> print("Struct");
> } else {
> print("-"); }
> } else if (node is Variable) {
> print("Variable ");
> if (node is Field) {
> print("Field");
> } else if (node is LocalVariable) {
>  print("LocalVariable");
> } else if (node is Vala.Parameter) {
> print("Parameter");
> } else {
> print("-"); }
> } else {
> print("-"); }
> } else {print("-"); }
> print("\n");
> }
> }
>
> The idea of having somehow standardized libvalaidetools is great. This can
> be simple API library providing completion, code navigation, dependency
> management, some standard vala-project file format, etc. So that anyone
> could turn his favorite text editor into full-featured Vala IDE using this
> library.
>
> Regards,
> Dmitry
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Autocomplete server

[Daniel Espinosa]

Yannick have started a vala-editor widget at:

https://github.com/inizan-yannick/vala-editor

But what we need at the end is:

An Object able to parse Vala documents and propose completion. MonoDevelop,
for C# can provide you options just related with the object you are trying
to access methods/properties.

A server providing parallel parsing and completion, could be an option, but
may not a server but a stable library, from Valencia for example, designed
in a way it can provide completion and error highlight to GEdit and Builder.

Actual Builder implementation is difficult to track, because is really
complex, see at Bug:

https://bugzilla.gnome.org/show_bug.cgi?id=764752






2016-04-21 14:55 GMT-05:00 Ben Iofel :

> libvala is probably the only way to do this
> I have generated valadoc for libvala on my website
> https://iofel.me/libvala/libvala/index.htm
>
> On Thu, Apr 21, 2016 at 3:53 PM Thiago Jedi  wrote:
>
> > Hey guys.
> >
> > First of all, Vala is awesome. I'm kinda new in the Vala world, but as
> > a C# developer, I found myself willing to invest my time learning the
> > language. I like the idea of a familiar syntax with powerfull
> > performance.
> >
> > I use the new Visual Studio Code IDE/Editor and decide to develope the
> > plugin for Vala [0]. I already have syntax highlight, I'm writing the
> > snippets, and I was wondering how much work it would take to bring
> > autocompletion to that editor.
> > I mean, I searched a little and found a lot of discontinued projects
> > (like libafrodite) and others tightly integrated with host editor.
> >
> > I think it'd be nice to have a language server which is independent
> > from editors. Something like the OmniSharp project for the C# language
> > [1].
> >
> > After my little research this last couple weeks, here's what I got:
> >
> > 1. The best autocomplete behavior I found (imho) was the Valencia
> > plugin for Gedit. But it had to rewrite all of the tokens that is
> > already on the libvala.
> >
> > 2. The autocomplete with the cleanest code was in Anjuta's Vala plugin,
> > which uses libvala extensivelly.
> >
> > I didn't want to reinvent the wheel, libvala seems to do all the
> > heavylifting, so I tried to mimic the Anjuta's behavior, but I got
> > stuck in some issues like the class base types returning null.
> >
> > Then I came here for help. Am I in the right track? Where can I find
> > documentation about libvala? Or is it just not worth it and I should
> > use another (existing) tool?
> >
> > Thank you for your attention.
> >
> > Thiago Abreu
> >
> > [0] - https://github.com/thiagoabreu/vala-code
> > [1] - http://www.omnisharp.net/
> > ___
> > vala-list mailing list
> > vala-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/vala-list
> >
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>



-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

[Vala] GXml 0.10.0 Released

[Daniel Espinosa]

GXml provides a GObject API for manipulating XML and a Serializable
framework to XML.

Currently, GXml provides the DOM Level 1 Core API, Basic HTML support,
Serialization.

Provides a set of interfaces to access XML equivalent files with different
implementations, some of them based on libxml but able to use different
backends.

It is written in Vala, but provides C API, while it is available to other
high level
languages, like Python or JavaScript, using GObject Introspection.


ChangeLog


===
Version 0.10.0
===


* New and updated translations:
Added zh_CN by Yating Kuang 
Updated Swedish by Anders Jonsson 
Updated German  by Mario Blättermann 
Updated Brazilian Portuguese by Enrico Nicoletto 
Updated Czech   by Marek Černocký 
Updated Serbian by Марко М. Костић 
Updated Hungarian   by Balázs Meskó 
Updated Polish  by Piotr Drąg 


===
Version 0.9.92
===

* New contructor methods for TDocument using custome ReadTypeFunc
* Bug fixes
* New and updated translations:
Updated Polish  by Piotr Drąg 
Updated Serbian by Мирослав Николић 

==
Version 0.9.90 and 0.9.91
==

* New TDocument.from_stream(), .from_string and .from_uri() methods
* API change TwNode and derived classes renamed to TNode
* Added parse capabilities to TDocument
* Improved performance tests, pointing: GDocument has better memory usage
and
  better performance than xDocument; TDocument has better performance but
more
  memory usage than GDocument.
* Bug fixes
* New and updated translations:
Added Hungarian  by Matej Urbančič 
Added Slovenian  by Matej Urbančič 
Added Greek  by Γιάννης Κουτσούκος 
Added Swedishby Anders Jonsson <
anders.jons...@norsjovallen.se>
Updated Czechby Marek Černocký 
Updated Brazilian Portuguese by Rafael Fontenelle 


===
Version 0.9.2
===

* API change Serializable.deserialize now return a boolean

* API change SerializableCollection: added new abstract methods for
post-deserialization

* SerializableCollection: Implementations now support enable/disable
deserialization
  for post-deseralization using
SerializableCollection.deserialize_children() for initial
  document load time optimization

* More memory optimizations: SerializableCollection implementations don't
hold
  objects for unknown properties/nodes



===
Version 0.9.1
===

* Added GXml.Node.parent property
* Performance measuring: GDocument equivalent to xDocument
* Memory usage: GDocument 42% less memory
* Memory for de/serialization using GDocument+TwDocument Vs.
  xDocument+TwDocument improved using 63% less memory


===
Version 0.9.0
===

API/ABI break

* API change: Removed GXml.SerializableJson and GXml.Serialization, due to
they
  have been unmaintained for a while now.

* API change: GXml.NodeList is now a Gee.ArrayList specialiced
class for better
  bindings support. The old class has been renamed to GXml.xNodeList.

* API change: Most interfaces now return owned properties in order to allow
implementations
  to handle its internals without expose/keep in memory some data, returning
  objects just on request.

* New libxml2 implementation called GNode and derivatives, expected to
replace
  old implementation. It is a creating objects on demand.

* New HtmlDocument for HTML handling

* Element interface removed finalize_attr (), due it is unsed

* Element added new get_ns_attr() for namespaced attributes

* Element implements set_ns_attr()

* xNode and derivatives enter to a maintenace status, in order
  to be deprecated in future, some tests haven't been added
  due to its internal complexity, like poor namespaces support. Is
  better to relay on GNode and derivatives. DOM API will be added
  in future versions to deprecate and remove xNode derivatives.

* Serializable tests now relay on GDocument

* Fixes on Unit Tests

* Added more stressful performance tests, to compare xDocument vs GDocument
with
  equivalent performance

-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Reflection : getting values in Gee.Collection

[Daniel Espinosa]

Another form is to subclass ArrayList, the resulting class can be
instantiated used simple Object.new() using your subclass' type. Then you
can call any method available for Gee.ArrayList or Gee.Collection by
casting to the object you need.

But defining a Serializable interface is good. In GXml, we need to
initialize all your Gee collections properties on creation, in order to
access them at run time, is not possible to create a Gee generic class at
runtime, if you want to do so in a generic, no hard coded, way.
El abr. 10, 2016 5:21 PM, "Felipe Lavratti"  escribió:

> ​Baptize Gelez,
>
> Here is an example how I'd do it:
>
> File 'vala_test.vala':
>
> using Gee;
>
> interface ISerializable : Object {
> public abstract string[] serializable_keys();
> public abstract string[] serializable_values();
> }
>
> class SerializableClass : ISerializable, Object {
>
> string prop1;
> ArrayList prop2;
>
> public SerializableClass (){
> prop1 = "bla!";
> prop2 = new ArrayList();
> prop2.add ("100");
> prop2.add ("10");
> prop2.add ("1");
> }
>
> public string[] serializable_keys () {
> var result = new GLib.Array();
> result.append_val ("prop1");
>
> for (int i = 0; i < prop2.size; i++)
> result.append_val (@"prop2[$i]");
>
> return result.data;
> }
>
> public string[] serializable_values () {
> var result = new GLib.Array();
> result.append_val (@"$prop1");
>
> for (int i = 0; i < prop2.size; i++)
> result.append_val (@"$(prop2[i])");
>
> return result.data;
> }
> }
>
> HashMap create_model(ISerializable serializable) {
> var result = new HashMap();
> var keys = serializable.serializable_keys();
> var values = serializable.serializable_values();
>
> for (int i = 0; i < keys.length; i++)
> result.@set(keys[i], values[i]);
>
> return result;
> }
>
>
> class Main {
>
> static void main() {
> var object_under_test = new SerializableClass();
> var model = create_model(object_under_test);
>
> var it = model.iterator ();
> for (var has_next = it.next (); has_next; has_next = it.next ()) {
> var key = it.get().key;
> var value = it.get().value;
> stdout.printf(@"$key -> $value\n");
> }
> }
> }
>
> $ valac vala_test.vala --pkg gee-0.8
> $ ./vala_test
> prop2[1] -> 10
> prop2[0] -> 100
> prop2[2] -> 1
> prop1 -> bla!
>
> ​
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Reflection : getting values in Gee.Collection

[Daniel Espinosa]

May you can use HashMap()

Value? Makes boxed any value supported by GLib.Value, almost any value,
from basic like int to GLib.Object, any any struct if it is properly boxed.
El abr. 9, 2016 12:11 PM, "Baptiste Gelez" 
escribió:

>
>
> Hello everyone !
>
> I would like to retrieve any property of an object. I presently use this
> code :
>
> HashMap result = new HashMap ();
>
> foreach (ParamSpec spec in obj.get_class ().list_properties ()) {
>  GLib.Value val = GLib.Value (typeof (string));
>  obj.get_property (spec.get_nick (), ref val);
>  result [spec.get_nick ()] = (string) val;
> }
>
> return result;
>
> There is no problem when I'm getting "simple" values like int, string,
> double, etc ... But I would like to be able to get all the elements of
> Gee.Collection. Have you got any idea of how to do that ?
>
> Thanks ! (And excuse me for possible English mistakes)
>
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala - webkit2gtk-4.0.vapi problem Debia Jessie

[Daniel Espinosa]

If you really need both, I don't know if that is possible or recommended,
but you can create a library with widgets you will use in your apps using
different PKG flags.
El abr. 5, 2016 7:51 PM, "Edwin De La Cruz"  escribió:

> Best regards. Again I come to you with a problem I have to use Debian
> webkti Vala with Jessie . When I compiled the following message :
>
> webkit2gtk-web-extension-4.0.vapi:2619.2-2619.38: error: `WebKit'
> already contains a definition for `URIRequest'
> public class URIRequest : GLib.Object {
> ^
> webkit2gtk-4.0.vapi:488.2-488.38: note: previous definition of
> `URIRequest' was here
> public class URIRequest : GLib.Object {
> ^
> webkit2gtk-web-extension-4.0.vapi:2628.2-2628.39: error: `WebKit'
> already contains a definition for `URIResponse'
> public class URIResponse : GLib.Object {
> ^^
> webkit2gtk-4.0.vapi:497.2-497.39: note: previous definition of
> `URIResponse' was here
> public class URIResponse : GLib.Object {
> ^^
> Compilation failed: 2 error(s), 0 warning(s)
>
>
> I have researched and according to some messages is not possible to
> use webkit2gtk -web -extension- 4.0 and webkit2gtk -4.0 at the same
> time :
>
> valac gtk + -3.0 --pkg --pkg webkit2gtk -4.0 --pkg webkit2gtk -web
> -extension- 4.0 wk.vala
>
> So what alternative I can use?
> Or as I use the library ?
>
> I hope I can lead.
> Thank you.
>
>
>
> Mis proyectos de software libre en:
> Github - edwinspire
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] [OT] Vala -> C#

[Daniel Espinosa]

C# is not just a language, is has a lot of libraries backed it, a few in
open source and most of them in closed .Net

But some things could change. Vala allows you to use virtually any C
library. Just need to create bindings for it. This is my first check when
want to do some thing.

Vala OO is really cool and powerful, it allows you to share your work with
other languages automatically through GObject Introspection, witch is
really great, you can reuse your library even in C#

Vala compiler requires some love, but it provides all you need now. Vala
does not provide libraries by it self, just most used bindings; but they
can (and should) be maintained out side Vala.

If you need a library to do some cool things, providing Vala, C and GObject
Introspection, then start writing it.

Some time ago I started to create a C/GObject wrapper of OpenSSL with Vala
bindings, but I lost my work. You can create structs and methods in C to
easy write Vala bindings, then access it in your code.

See at GXml project for missing libxml2 bindings, at vapi directory, for
examples.

Again, I agree too about documentation, good one will help to others write
Vala bindings and libraries.

Vala allows C to reach the frontiers it has now, because its boilerplate to
write then, specially when it requires OO.
El mar. 29, 2016 12:48 PM, "Edwin De La Cruz" 
escribió:

> 2016-03-29 12:16 GMT-05:00 mar...@saepia.net :
> > Excuse me but are you suggesting that Vala users should write a tool that
> > eases migration from Vala to C#? You are free to do it by yourself.
> >
> > I agree that documentation, and overall support is incomparable between
> Vala
> > and any other enterprise-backed language and it might be much better but
> > what you are suggesting is an overkill. Many open source projects lack
> this
> > "developer happines" aspect as they are mainly curated by nerds, not
> > "product owners" but what you can do here is use time you spend on
> > complaining on improving this. If you don't get that philosophy, you
> should
> > stay in the safe harbour of enterprise languages.
> >
> > Moreover, if speed of development was your primary need, it's your (or
> your
> > CTO if you have one) fault that you have chosen quite immature, niche
> > language for your work. There are shitloads of languages and frameworks
> that
> > are aimed at doing stuff fast, usually in exchange for performance,
> > resources consumption or low-level access to the bare metal.
> >
> > I also sometimes spend ages on debugging low level stuff in Vala. But I
> > don't complain because it's still the best choice for writing
> > GStreamer-backed, truly cross platform multimedia applications that won't
> > get accidental lock because of garbage collector. For this use case it's
> > close to perfection. Maybe your use case was just differentbut. I am not
> > sure if your disappointment is fault of Vala and tools for migrating to
> C#
> > would have sorted that issue out.
> >
> > Still, I agree that even within open source community there are examples
> of
> > better documentation/support/whatsoever but I consider this to be
> secondary
> > to your arguments.
> >
> > m.
> >
> > 2016-03-29 0:48 GMT+02:00 Edwin De La Cruz :
> >>
> >> 2016-03-28 16:19 GMT-05:00 Edwin De La Cruz :
> >> > 2016-03-26 9:59 GMT-05:00 Steven Oliver :
> >> >> If having an IDE is high on your list check out builder. It's support
> >> >> for
> >> >> Vala is getting better every release. They are also really good about
> >> >> taking
> >> >> new contributors.
> >> >>
> >> >> Thank you,
> >> >> Steven N. Oliver
> >> >>
> >> >>
> >> >>
> >> >> On Thu, Mar 24, 2016 at 7:49 PM -0700, "Edwin De La Cruz"
> >> >>  wrote:
> >> >>
> >> >>> Dear. I'm using valac for quite some time, although work has been
> left
> >> >>> aside, I'm starting to use c #, I find it more productive but I
> refuse
> >> >>> to use it and recognize it, but it is.
> >> >>>
> >> >>> Among the ideas that came to my mind, including _mono_, I thought
> ...
> >> >>> because someone does not develop something similar to c # but Vala,
> >> >>> who has the same name functions, classes, methods, etc so if I have
> >> >>> one codigo.cs simply change it by codigo.vala and compile directly.
> >> >>>
> >> >>> I know it's an idea a little crazy and not all libraries can be
> >> >>> imported, but whether it would be much easier and productive to have
> >> >>> such a code.
> >> >>>
> >> >>> I program in C # using their mimas classes, but at the time of
> >> >>> compiling all transforms Vala.
> >> >>>
> >> >>> It would be great as well.
> >> >>>
> >> >>> I have made the task of doing that only with the most basic
> functions,
> >> >>> just to prove, as a hobby.
> >> >>>
> >> >>> In the years that I go with Vala language seems very much potential,
> >> >>> but lacks an IDE, MonoDevelop no longer supports it, also lacks more
> >> >>> documentation, easier to use libraries as well as in c #.
> >> >>>
> >> >>> Sorry for the extension of this message and

Re: [Vala] Generating vapi for GOM failed.

[Daniel Espinosa]

You should use metadata to solve most issues on VAPI generation. This is
maybe a case you have two methods with same name.

You can:

A) Add GObject Introspection annotations to C code in order to rename a
function and avoid this conflicts, with the advantage to get a very similar
API for Vala and other languages

https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations

B) Use metadata to rename the conflicting function to some other

https://wiki.gnome.org/Projects/Vala/Manual/GIDL%20metadata%20format

El feb. 28, 2016 8:57 PM, "Andres Fernandez" <
and...@softwareperonista.com.ar> escribió:
>
> Hi,
>
> I was trying to get the Gnome Object Mapper library vapi, cause I
> couldn't find the bindings somewhere else. This is the first time that
> I try to make a vapi so I'm not sure if I'm doing it wel.
>
> I folowed [1] this wiki and when I run
>
> $ vapigen --library gom-1.0 /usr/share/gir-1.0/Gom-1.0.gir
>
> I get this teo error:
>
> Gom-1.0.gir:1200.7-1204.24: error: `Filter' already contains a
> definition for `sql'
> Gom-1.0.gir:1143.7-1143.58: note: previous definition of `sql' was here
>   
>
> and the generation failed.
>
> I'm not sure how to make it work, so if you can pointing me out
> something usefull I'll really appreciate it.
>
> Thanks in advance!
>
> Best regards,
>
> Andrés Fernández
>
> [1] https://wiki.gnome.org/Projects/Vala/Bindings
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Is there any way to access generic type from the interface?

[Daniel Espinosa]

If you want your interface to provide, not just default implementations,
but methods your classes should not need to implement they self, use
virtual methods, you can provide an implementation for this method your
derived classes don't need to implement but inherited. Static methods can
be used to be reused if you want.
El feb. 28, 2016 4:31 PM, "Felipe Lavratti"  escribió:

> Even better, try this main instead the previous:
>
> int main () {
>
> IMixinInterface fooer = new NothingSpecialFooer();
> fooer.foo();
>
> fooer = new TheSpecialFooer();
> fooer.foo();
>
> return 0;
> }
>
> Here we use the interface as the type of the object to show
> polymorphism with mixin happening.
>
> It prints:
>
> $ ./test
> ** Message: test.vala:5: fooed defaulty!
> ** Message: test.vala:13: dummy string
> ** Message: test.vala:22: fooed specially!
>
>
>
> On Sun, Feb 28, 2016 at 7:24 PM, Felipe Lavratti 
> wrote:
> > Right, I see what u are asking now.
> >
> > Well, if you want to do Mixins in Vala, you'll have to do the "static"
> > workaround, since it doesn't support by default:
> >
> https://wiki.gnome.org/Projects/Vala/Tutorial#Mixins_and_Multiple_Inheritanae
> >
> > Now you want to do Mixing with Generics? Ok, add the generic argument to
> > each  Mixin method of your interface:
> >
> > public interface IMixinInterface : Object {
> > public abstract void foo();
> >
> > public static T default_fooing(T arg) {
> > GLib.message("fooed defaulty!");
> > return arg;
> > }
> > }
> >
> > public abstract class BaseFooer : Object, IMixinInterface {
> > public virtual void foo() {
> > var dummy_string = IMixinInterface.default_fooing("dummy
> > string");
> > GLib.message(dummy_string);
> > }
> > }
> >
> > public class NothingSpecialFooer : BaseFooer {
> > }
> >
> > public class TheSpecialFooer : BaseFooer {
> > public override void foo() {
> > GLib.message("fooed specially!");
> > }
> > }
> >
> > int main () {
> >
> > var fooer = new NothingSpecialFooer();
> > fooer.foo();
> >
> > var fooer2 = new TheSpecialFooer();
> > fooer2.foo();
> >
> > return 0;
> > }
> >
> >
> > This example doesn't cover BaseFooer taking a generic argument, if the
> > example is not enough, please provide me more details about how is the
> > generic argument used in BaseFooer.
> >
> > - Fanl
> >
> >
>
>
>
> --
> Skype: felipeanl
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Is there any way to access generic type from the interface?

[Daniel Espinosa]

Is not valid code. Interfaces should "derive" from Object. Interfaces list
dependencies, the first one should be Object, then other interfaces depends
on, the order matters, because if other interfaces depends on same, they
should be added first.

For your question, use typeof(G)
El feb. 27, 2016 1:26 PM, "Felipe Lavratti"  escribió:

> I don't know if your code is valid Vala. MyInterface should not inherit
> MyClass.
>
> On Sat, Feb 27, 2016 at 10:59 mar...@saepia.net  wrote:
>
> > Hello,
> >
> > I am planning to use interfaces as in vspec as they are nice syntax sugar
> > for my purpose.
> >
> > However, in order to make it working properly, I need to access type
> > defined as generic in the parent class implementing interface. Something
> > like
> >
> > public interface MyIface : MyClass {
> >   public MyGenericType something() {
> > ...
> >   }
> > }
> >
> >
> > public abstract class MyClass : MyIface {
> >
> > }
> >
> >
> > Is it possible in any way?
> >
> > m.
> > ___
> > vala-list mailing list
> > vala-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/vala-list
> >
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Fwd: Possible bug of seg fault when array returned

[Daniel Espinosa]

In your code you just initialize objects at 4 and 6, then when try iterates
over first ones you access to uninitialized objects.

Try to create an empty array {} then use += to add objects to it. This way
you should create smallest array with all its members initialized.
El feb. 24, 2016 8:21 AM, "Megh Parikh"  escribió:

> When returning an array of objects from a method (static in my case),
> trying  to access the objects gives segfault. This may be a bug as I
> think the objects are freed before the code ends but I dont know for
> sure so I am posting in mailing list instead of Bugzilla
>
> Dummy code (25 line)  :
> https://gist.github.com/meghprkh/0147641f7b57466def19
>
> Regards,
> Megh Parikh
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Is there any usable editor for Vala?

[Daniel Espinosa]

It appears valencia is unmaintained now. May I can merge some WIP to master
to help others to use it and attract some patches to release a 3.14 and get
some help from others trying to provide Vala support.

I was thinking to try to reuse some work from Builder and others to provide
a simple jet stable Vala plugin. Point here is to have some thing simple
but useful, while Builder comes more stable.

What are your expectations?

https://plus.google.com/110617990354745814227/posts/THkq7jWLzmD
Hi Matthias, hi Jonathan,

here's a version of valencia-0.8 that I applied the patches for gedit
>=3.12 on [1].
I got the patches from here [2].

The only additional change I applied to the code, is to make the jump-forth
and jump-back feature work with the Alt_R-key (Alt_Gr+Left, Alt_Gr+Right).
Before that it was mapped to Alt (MOD1_MASK), which seems to be reserved in
the current versions of gedit by now.

Note that you might need to update the following line in the Makefile to
match your current Vala version:

LIBVALA=libvala-0.32

..where libvala-0.32 stands for the current Vala version 0.31.1 .



I haven't found any portion of the valencia-code that would try to access
any "enable-delete" member in an obvious way. However, given the fact that
my version of valencia works with gedit-3.14, there might be a chance for
you to have it work with gedit-3.18, too.

Hope that helps.

Best,

gilzad

[1] http://gilzad.de/linux-stuff/valencia_0.8_post_gtk3.12.zip
[2] https://bugzilla.gnome.org/show_bug.cgi?id=724173


> Gesendet: Freitag, 19. Februar 2016 um 21:34 Uhr
> Von: "Jonathan Moerman" 
> An: "Matthias Berndt" , vala-list@gnome.org
> Betreff: Re: [Vala] Is there any usable editor for Vala?
>
> Valencia isn't limited to vala 0.24 (I've only used it with >= 0.28), you
> can build it for 0.30 by running "LIBVALA=libvala-0.30 make" (or by
> modifying the Makefile).
> That error probably isn't related to Valencia, I mentioned that I'm using
> Gedit 3.10 because I simply don't know if it will compile and run with
> newer versions of Gedit.
> I never meant that you should install 3.10, I should have been more clear.
>
>  Jonathan Moerman
>
> 2016-02-19 21:15 GMT+01:00 Matthias Berndt :
>
> >
> > I don't know what version of gedit you're using, but
> >>> https://github.com/JMoerman/valencia-1 works for me. (I'm using gedit
> >>> 3.10)
> >>>
> >>
> >> I'll second this.  Gedit + Valencia have worked very nicely for me.
It's
> >> true that there hasn't been much development of Valencia recently, but
I've
> >> found it does everything I want it to.
> >>
> >> Unfortunately I can't reproduce that. After going through the trouble
of
> > installing gedit 3.10 and vala 0.24 (Fedora comes with gedit 3.18 and
vala
> > 0.30) and getting Valencia to compile, it crashes gedit on startup.
> > $ gedit
> >
> > (gedit:23465): GLib-GIO-ERROR **: Settings schema
> > 'org.gnome.nautilus.preferences' does not contain a key named
> > 'enable-delete'
> > Trace/Breakpoint ausgelöst (Speicherabzug geschrieben)
> >
> > Cheers, Matthias
> >
> >
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Problem with programmatic generic object instantiation

[Daniel Espinosa]

I run in the same issue for GXml and SerializableListArray<>, for example.

The way I resolve, in my case, I've defined a new Interface called
SerializableCollection, with a init() function. This function is called by
Serializable.deserialize() method in order to help implementators to
initialize its generic containers by calling MyObjectCollection.new()
providing any information it needs like the Generic Type it should work on.

In my other project, I've just initialize any public property as

MyProperty prop { get; set; default = new MyProperty(); }

or inside construct {}

The point is to call MyProperty.new() not Object.new() on generic classes.


2016-02-16 16:59 GMT-06:00 Andy Lees :

> Yes, the problem is that for types derived from generics (and for the
> generic constructor itself), the type information is not set in the
> construct function, so very little can be done.
>
> On Wed, Feb 17, 2016 at 9:53 AM, Daniel Espinosa  wrote:
>
>> If you want to execute code on Object creation using Object.new(), you
>> should use
>>
>> construct {
>>   // Your code here
>> }
>>
>> When define code at MyObject.new(), you execute the code in this method
>> not Object.new(), then use the above should help.
>>
>>
>> 2016-02-16 15:58 GMT-06:00 Andy Lees :
>>
>>> The problem with Object.new is that it doesn't call the object
>>> constructor so far as I can tell, just calling g_object_new without any of
>>> the Vala object construction code.
>>>
>>> My Serializable is an interface.  I'm trying to make use of the Json
>>> serialization framework, and for the most part it's working.  The problem
>>> I'm having is with the construction of instances of array types - there
>>> appears to be no factory framework for object creation in Vala, and so far
>>> the only workaround I've come up with is very clunky.
>>>
>>> Is there an object factory somewhere that someone could point me towards?
>>>
>>> On Wed, Feb 17, 2016 at 1:49 AM, Daniel Espinosa 
>>> wrote:
>>>
>>>> Try use Object.new(typeof(IntArr))
>>>>
>>>> Try to rename type() to any other, to avoid conflics with Object.type()
>>>>
>>>> You are trying to implement Gee.ArrayList<>, may you:
>>>>
>>>> A) wrap Gee.ArrayList in your class
>>>>
>>>> B) Derive directly from Gee.Arraylist then convert your base class
>>>> Serializable as an interface with all required methods implemented as
>>>> virtual, then you have two bases.
>>>>
>>>> You may want to check at GXml.Serializable interface and its
>>>> GXml.SerializableArrayList implementation based on Gee.
>>>> El feb. 16, 2016 7:10 AM, "Andy Lees"  escribió:
>>>>
>>>>> I would have expected the generic type to be obtained from the type id
>>>>> of the derived type (generic instantiation), which is obtained fresh each
>>>>> execution, but it seems not.  Is the generic type a hidden property of the
>>>>> class derived from the generic class, and if so, what would its name be so
>>>>> that it can be set in the new call?
>>>>>
>>>>> Alternatively, is there a way to call an object constructor given the
>>>>> type id?
>>>>>
>>>>> On Tue, Feb 16, 2016 at 11:16 PM, Daniel Espinosa 
>>>>> wrote:
>>>>>
>>>>>> Take in account that Type system is dynamically created, then a type
>>>>>> number will change with each execution.
>>>>>>
>>>>>> Use
>>>>>>
>>>>>> YourCreatedObject is typeof (Object)
>>>>>>
>>>>>> to check if the created object is of type you need, like a derived
>>>>>> object.
>>>>>>
>>>>>> You can use
>>>>>>
>>>>>> obj.get_type().is_a(typeof (Object))
>>>>>>
>>>>>> And consider that your example is exactly the way to create an object
>>>>>> of Generic class, because you have set tje object type. Create a generic
>>>>>> instance with Object.new you should provide the object type.
>>>>>> El feb. 16, 2016 5:14 AM, "Andy Lees" 
>>>>>> escribió:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have a generic array implementation like so:
>>>>>&g

Re: [Vala] Construction of generic instantiations

[Daniel Espinosa]

Have you considered to use construct properties:

https://wiki.gnome.org/Projects/Vala/PropertiesSample

They should be set at construction time as for:

Object (construct_only_prop: a, construct_get_set_prop: b);

But you should know Generic type before construct.


2016-02-16 16:51 GMT-06:00 Andy Lees :

> Hi,
>
> I seems that the setting of the hidden type variable in generic
> instantiations occurs in the new operation, rather than in the constructor,
> so if I have a class:
>
> public class Makeable :  GLib.Object {
>
>   construct {
> x = (int)typeof (T);
> message ("Makeable in Construction, T = %ld", (long)typeof (T));
>   }
>   public int x;
>   public Makeable() {
> message ("In new x = %d T = %ld", x, (long)typeof (T));
>   }
>
>   public Type typ() {
> return typeof (T);
>   }
>
> }
>
> then I get:
> ** Message: test5.vala:18: Makeable in Construction, T = 4
> ** Message: test5.vala:22: In new x = 4 T = 24
> when I construct via new ...
> and only:
> ** Message: test5.vala:18: Makeable in Construction, T = 4
> when I construct with Object.new.
>
> This means that generic instances cannot be properly constructed via
> Object.new, which appears to be a significant issue.
>
> Is there any reason why the setting of the hidden type variable ( and any
> other generic instance initialisations) cannot be done in the construct
> function prior to user code? Then generic instances could be made via
> Object.new like other objects.
>
> Regards,
>
> Andrew Lees
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>



-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Problem with programmatic generic object instantiation

[Daniel Espinosa]

If you want to execute code on Object creation using Object.new(), you
should use

construct {
  // Your code here
}

When define code at MyObject.new(), you execute the code in this method not
Object.new(), then use the above should help.


2016-02-16 15:58 GMT-06:00 Andy Lees :

> The problem with Object.new is that it doesn't call the object constructor
> so far as I can tell, just calling g_object_new without any of the Vala
> object construction code.
>
> My Serializable is an interface.  I'm trying to make use of the Json
> serialization framework, and for the most part it's working.  The problem
> I'm having is with the construction of instances of array types - there
> appears to be no factory framework for object creation in Vala, and so far
> the only workaround I've come up with is very clunky.
>
> Is there an object factory somewhere that someone could point me towards?
>
> On Wed, Feb 17, 2016 at 1:49 AM, Daniel Espinosa  wrote:
>
>> Try use Object.new(typeof(IntArr))
>>
>> Try to rename type() to any other, to avoid conflics with Object.type()
>>
>> You are trying to implement Gee.ArrayList<>, may you:
>>
>> A) wrap Gee.ArrayList in your class
>>
>> B) Derive directly from Gee.Arraylist then convert your base class
>> Serializable as an interface with all required methods implemented as
>> virtual, then you have two bases.
>>
>> You may want to check at GXml.Serializable interface and its
>> GXml.SerializableArrayList implementation based on Gee.
>> El feb. 16, 2016 7:10 AM, "Andy Lees"  escribió:
>>
>>> I would have expected the generic type to be obtained from the type id
>>> of the derived type (generic instantiation), which is obtained fresh each
>>> execution, but it seems not.  Is the generic type a hidden property of the
>>> class derived from the generic class, and if so, what would its name be so
>>> that it can be set in the new call?
>>>
>>> Alternatively, is there a way to call an object constructor given the
>>> type id?
>>>
>>> On Tue, Feb 16, 2016 at 11:16 PM, Daniel Espinosa 
>>> wrote:
>>>
>>>> Take in account that Type system is dynamically created, then a type
>>>> number will change with each execution.
>>>>
>>>> Use
>>>>
>>>> YourCreatedObject is typeof (Object)
>>>>
>>>> to check if the created object is of type you need, like a derived
>>>> object.
>>>>
>>>> You can use
>>>>
>>>> obj.get_type().is_a(typeof (Object))
>>>>
>>>> And consider that your example is exactly the way to create an object
>>>> of Generic class, because you have set tje object type. Create a generic
>>>> instance with Object.new you should provide the object type.
>>>> El feb. 16, 2016 5:14 AM, "Andy Lees"  escribió:
>>>>
>>>>> Hi,
>>>>>
>>>>> I have a generic array implementation like so:
>>>>>
>>>>> public class GArrSerializable : Serializable, Object  {
>>>>>   public T[] data;
>>>>>   public int length;
>>>>>   public GArrSerializable(int size = 0) {
>>>>> data = new T[size];
>>>>>   }
>>>>>
>>>>>   public Type type () { return typeof (T); }
>>>>>
>>>>> ...etc
>>>>>
>>>>> and a derived type:
>>>>>
>>>>> public class IntArr : GArrSerializable {
>>>>>
>>>>>   public IntArr(int size = 0) {
>>>>> base (size);
>>>>>   }
>>>>> }
>>>>>
>>>>> If I create an instance of the type, then instance.type () returns 24
>>>>> as
>>>>> expected.
>>>>> If I create an instance like so:
>>>>> var ia = Object.@new (type) as IntArr;
>>>>> var t = ia.type ();
>>>>>
>>>>> Then t is 4 rather than 24.  As it is in the instance when it tries to
>>>>> deserialize.
>>>>>
>>>>> Can you tell me why this is so, and how I can programmatically create
>>>>> objects derived from a parameterised type?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Andrew Lees
>>>>> ___
>>>>> vala-list mailing list
>>>>> vala-list@gnome.org
>>>>> https://mail.gnome.org/mailman/listinfo/vala-list
>>>>>
>>>>
>>>
>


-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Problem with programmatic generic object instantiation

[Daniel Espinosa]

Try use Object.new(typeof(IntArr))

Try to rename type() to any other, to avoid conflics with Object.type()

You are trying to implement Gee.ArrayList<>, may you:

A) wrap Gee.ArrayList in your class

B) Derive directly from Gee.Arraylist then convert your base class
Serializable as an interface with all required methods implemented as
virtual, then you have two bases.

You may want to check at GXml.Serializable interface and its
GXml.SerializableArrayList implementation based on Gee.
El feb. 16, 2016 7:10 AM, "Andy Lees"  escribió:

> I would have expected the generic type to be obtained from the type id of
> the derived type (generic instantiation), which is obtained fresh each
> execution, but it seems not.  Is the generic type a hidden property of the
> class derived from the generic class, and if so, what would its name be so
> that it can be set in the new call?
>
> Alternatively, is there a way to call an object constructor given the type
> id?
>
> On Tue, Feb 16, 2016 at 11:16 PM, Daniel Espinosa 
> wrote:
>
>> Take in account that Type system is dynamically created, then a type
>> number will change with each execution.
>>
>> Use
>>
>> YourCreatedObject is typeof (Object)
>>
>> to check if the created object is of type you need, like a derived object.
>>
>> You can use
>>
>> obj.get_type().is_a(typeof (Object))
>>
>> And consider that your example is exactly the way to create an object of
>> Generic class, because you have set tje object type. Create a generic
>> instance with Object.new you should provide the object type.
>> El feb. 16, 2016 5:14 AM, "Andy Lees"  escribió:
>>
>>> Hi,
>>>
>>> I have a generic array implementation like so:
>>>
>>> public class GArrSerializable : Serializable, Object  {
>>>   public T[] data;
>>>   public int length;
>>>   public GArrSerializable(int size = 0) {
>>> data = new T[size];
>>>   }
>>>
>>>   public Type type () { return typeof (T); }
>>>
>>> ...etc
>>>
>>> and a derived type:
>>>
>>> public class IntArr : GArrSerializable {
>>>
>>>   public IntArr(int size = 0) {
>>> base (size);
>>>   }
>>> }
>>>
>>> If I create an instance of the type, then instance.type () returns 24 as
>>> expected.
>>> If I create an instance like so:
>>> var ia = Object.@new (type) as IntArr;
>>> var t = ia.type ();
>>>
>>> Then t is 4 rather than 24.  As it is in the instance when it tries to
>>> deserialize.
>>>
>>> Can you tell me why this is so, and how I can programmatically create
>>> objects derived from a parameterised type?
>>>
>>> Thanks
>>>
>>> Andrew Lees
>>> ___
>>> vala-list mailing list
>>> vala-list@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/vala-list
>>>
>>
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Problem with programmatic generic object instantiation

[Daniel Espinosa]

Take in account that Type system is dynamically created, then a type number
will change with each execution.

Use

YourCreatedObject is typeof (Object)

to check if the created object is of type you need, like a derived object.

You can use

obj.get_type().is_a(typeof (Object))

And consider that your example is exactly the way to create an object of
Generic class, because you have set tje object type. Create a generic
instance with Object.new you should provide the object type.
El feb. 16, 2016 5:14 AM, "Andy Lees"  escribió:

> Hi,
>
> I have a generic array implementation like so:
>
> public class GArrSerializable : Serializable, Object  {
>   public T[] data;
>   public int length;
>   public GArrSerializable(int size = 0) {
> data = new T[size];
>   }
>
>   public Type type () { return typeof (T); }
>
> ...etc
>
> and a derived type:
>
> public class IntArr : GArrSerializable {
>
>   public IntArr(int size = 0) {
> base (size);
>   }
> }
>
> If I create an instance of the type, then instance.type () returns 24 as
> expected.
> If I create an instance like so:
> var ia = Object.@new (type) as IntArr;
> var t = ia.type ();
>
> Then t is 4 rather than 24.  As it is in the instance when it tries to
> deserialize.
>
> Can you tell me why this is so, and how I can programmatically create
> objects derived from a parameterised type?
>
> Thanks
>
> Andrew Lees
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Using TestCase class: assert (this is Object) fails in method, but not in constructor

[Daniel Espinosa]

GXml have a test suite may you want to check. I has more than 50 tests
cases.
El feb. 4, 2016 3:04 PM, "Al Thomas"  escribió:

>
>
> - Original Message -
> > From: Felipe Lavratti 
> > Sent: Thursday, 4 February 2016, 20:18
> > Subject: [Vala] Using TestCase class: assert (this is Object) fails in
> method, but not in constructor
> >
> > Have a look at this code:
> >
> > public class Tests : Object {
> >
> > public Tests () {
> > assert (this is Object); // THIS ASSERTION PASSES
> > ts = new TestSuite ("dot_cap_dimmer") ;
> > ts.add (new TestCase ("construction", (TestFixtureFunc)
> > setup, (TestFixtureFunc) test_construction, (TestFixtureFunc)
> > teardown)) ;
> > TestSuite.get_root ().add_suite (ts) ;
> > }
> >
> > void setup(void * fixture) {
> > assert (this is Object);  // THIS ASSERTION FAILS
> > this.cut = new DotCapDimmer () ;
> > this.cut.on_change.connect (slot) ;
> > this.called = false ;
> > }
> > ...
> >  }
> >
> > Would anyone know what happens to the `this` variable when called
> > from the TestCase ? How came it is no longer an Object anymore ?
>
>
> You need to instantiate your fixture so it has `this` to act upon.
> Your fixture should be a separate object to the test.
> As an outline;
>
>
> void main( string[] args ) {
>
>   Test.init(ref args);
>   TestSuite suite = new TestSuite( "DotCapDimmer" );
>   TestSuite.get_root ().add_suite (suite);
>
>   MyTestFixture fixture = new MyTestFixture();
>   suite.add( new TestCase ( "MyFirstTestCase", fixture.set_up,
> (TestFixtureFunc)test_my_first_test, fixture.tear_down ));
>   Test.run();
> }
>
> void test_my_first_test( MyTestFixture fixture ) {
> // do testing
>
> }
>
>
>
> I put the test in a namespace like
> UnitTest.ModuleDirectory.FilenameOfClassToBeTested
>
> There is also g_test_add_data_func_full () instead, but I haven't used
> that yet.
>
> Al
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] glib-2.0 - glib-2.0.vapi mismatch bug: TestFixtureFunc vs TestFunc

[Daniel Espinosa]

If fall in this case, as in GLib.Thread, first check if GLib C
documentation state the API is deprecated. If so, you need to use

*--**target-glib**=**MAJOR*.*MINOR*

to be sure you'll generate code for the GLib version you use or target,
this ensure too, using latest API an avoid valac to generate code
compatible with old glib versions.
El feb. 3, 2016 5:25 PM, "Felipe Lavratti"  escribió:

> Hello, using the glib-2.0 `GLib.TestCase` constructor triggers the
> following warning:
>
> warning: passing argument 4 of ‘g_test_create_case’ from incompatible
> pointer type
>  ts.add(new TestCase("context", (TestFunc)setup,
> (TestFunc)test_context, (TestFunc)teardown));
>
> It means, the `g_test_create_case` arguments of type TestFixtureFunc
> which has been depecrated in the glib-2.0.vapi, note the following
> lines of the /usr/share/vala-0.30/glib-2.0.vapi file:
>
> #if GLIB_2_26
> [CCode (has_target = false)]
> public delegate void TestFunc ();
> public delegate void TestDataFunc ();
> public delegate void TestFixtureFunc (void* fixture);
> #else
> public delegate void TestFunc (void* fixture);
> public delegate void TestDataFunc ();
> #endif
>
> The keyword `TestFixtureFunc` has been removed since version 2_26, but
> it is still used in the glib-2.0 header
> /usr/include/glib-2.0/glib/gtestutils.h:
>
> /* semi-internal API */
> GLIB_AVAILABLE_IN_ALL
> GTestCase*g_test_create_case(const char   *test_name,
>  gsize data_size,
>  gconstpointer test_data,
>  GTestFixtureFunc  data_setup,
>  GTestFixtureFunc  data_test,
>  GTestFixtureFunc  data_teardown);
>
>
> --
> Skype: felipeanl
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] GLib.Object.get_type() static?

[Daniel Espinosa]

This method returns an object type but if it is not registered, by
convention, it does. Just check C generated for a GObject.

For libraries, some times, you need to register objects in the type system
before call some method, just check libgda's gda_init() at line 152:

https://git.gnome.org/browse/libgda/tree/libgda/gda-init.c

For C you call a macro, it calls object_get_type(), what is the effect of
call in Vala

typeof(ObjectName)?

May this is where you can have registered a type, because it should call
get type() behind scens.
El ene. 24, 2016 1:16 AM, "Ben"  escribió:

> Object.get_type () gets the type of an instance. It doesn't make sense to
> make it static.
>
> On Sat, Jan 23, 2016 at 6:59 AM, Daniel Espinosa  wrote:
>
> Why in gobject-2.0.vapi GLib.Object.get_type () is an instant method? This
> method should be declared as static, because some times a library requires
> to register a type on initialization to aviod errors at runtime.
> ___ vala-list mailing list
> vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
>
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

[Vala] GLib.Object.get_type() static?

[Daniel Espinosa]

Why in gobject-2.0.vapi GLib.Object.get_type () is an instant method?

This method should be declared as static, because some times a library
requires to register a type on initialization to aviod errors at runtime.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Why valac is always called even if conditional automake clause is false?

[Daniel Espinosa]

Well your conditionals seem to be Ok.

You may try to put all code in same directory or keep in subdirs, using
conditionals avoiding build them, as a libraries to specific platform if
they are implementation of your interfaces, install per platform and use in
your code, witch I think is using, not defined in your Makefile, -D
directives to valac in order to create platform specific objects
implementing your interfaces.
El ene. 16, 2016 9:00 AM, "mar...@saepia.net"  escribió:

> Here are definitons of my conditionals:
> https://gist.github.com/mspanc/2e1432ff23f7dfb7bb20
>
> These C files are not C files generated by vala, it's a different code.
>
> The whole thing is that I want to avoid having them in the same file and
> using conditionals because that makes code really big & unreadable. If
> that's the only solution I can make it but the whole point was to keep the
> platform-specific code in separate, conditionally compiled files.
>
> m.
>
> 2016-01-16 14:51 GMT+01:00 Daniel Espinosa :
>
>> May be if you post your configure.ac conditionals  could help.
>>
>> General comments:
>>
>> * you are including some subdir sources, I not sure, but may you should
>> rename your source files to include them in same directory.
>>
>> * you include some C files that will be generated by Vala, may you need
>> to avoid that.
>>
>> * you have interfaces files with the same name, may be an extension per
>> platform? If so may is better to add conditionals to VALAFLAGS per
>> platform, using -D, and keep all code in the same file.
>> El ene. 15, 2016 12:22 PM, "mar...@saepia.net" 
>> escribió:
>>
>>> Hello,
>>>
>>> I have the following makefile that is responsible for conditional
>>> compilation of one subdir of my project depending on the platform used:
>>> https://gist.github.com/mspanc/5b31758b966fa6eab959
>>>
>>> I am using automake's AM_CONDITIONAL to pass information about operating
>>> system to further scripts.
>>>
>>> It works (almost) well, the code compiles, but I've noticed that when I
>>> call make in this subdir, it calls valac for all source files, even these
>>> not matched by current condition:
>>>
>>> $ make
>>> rm -f libwhatever_common_media_audio_la_vala.stamp && echo stamp >
>>> libwhatever_common_media_audio_la_vala.stamp-t
>>> CDPATH="${ZSH_VERSION+.}:" && cd . && /usr/local/bin/valac --library
>>> libwhatever-common-1.0-media-audio --vapi
>>> libwhatever-common-1.0-media-audio.vapi -H media-audio.h
>>> --enable-experimental --enable-experimental-non-null  -D PLATFORM_DARWIN
>>> -C lifecycle.vala base_interface_monitor.vala
>>> base_polling_interface_monitor.vala interface_monitor.vala
>>> windows/lifecycle.vapi windows/interface_list.vapi
>>> windows/interface_monitor.vala darwin/interface_list.vapi
>>> darwin/interface_monitor.vala linux/interface_monitor.vala
>>>
>>> (here should exclude windows/ and linux/ subdir as it was called on mac)
>>>
>>> VALAFLAGS are set correctly, so conditionals are working fine for other
>>> cases.
>>>
>>> How to prevent this?
>>>
>>> Is it a bug in automake's vala extensions or am I doing something wrong?
>>>
>>> Thanks,
>>>
>>> Marcin
>>> ___
>>> vala-list mailing list
>>> vala-list@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/vala-list
>>>
>>
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Why valac is always called even if conditional automake clause is false?

[Daniel Espinosa]

May be if you post your configure.ac conditionals  could help.

General comments:

* you are including some subdir sources, I not sure, but may you should
rename your source files to include them in same directory.

* you include some C files that will be generated by Vala, may you need to
avoid that.

* you have interfaces files with the same name, may be an extension per
platform? If so may is better to add conditionals to VALAFLAGS per
platform, using -D, and keep all code in the same file.
El ene. 15, 2016 12:22 PM, "mar...@saepia.net"  escribió:

> Hello,
>
> I have the following makefile that is responsible for conditional
> compilation of one subdir of my project depending on the platform used:
> https://gist.github.com/mspanc/5b31758b966fa6eab959
>
> I am using automake's AM_CONDITIONAL to pass information about operating
> system to further scripts.
>
> It works (almost) well, the code compiles, but I've noticed that when I
> call make in this subdir, it calls valac for all source files, even these
> not matched by current condition:
>
> $ make
> rm -f libwhatever_common_media_audio_la_vala.stamp && echo stamp >
> libwhatever_common_media_audio_la_vala.stamp-t
> CDPATH="${ZSH_VERSION+.}:" && cd . && /usr/local/bin/valac --library
> libwhatever-common-1.0-media-audio --vapi
> libwhatever-common-1.0-media-audio.vapi -H media-audio.h
> --enable-experimental --enable-experimental-non-null  -D PLATFORM_DARWIN
> -C lifecycle.vala base_interface_monitor.vala
> base_polling_interface_monitor.vala interface_monitor.vala
> windows/lifecycle.vapi windows/interface_list.vapi
> windows/interface_monitor.vala darwin/interface_list.vapi
> darwin/interface_monitor.vala linux/interface_monitor.vala
>
> (here should exclude windows/ and linux/ subdir as it was called on mac)
>
> VALAFLAGS are set correctly, so conditionals are working fine for other
> cases.
>
> How to prevent this?
>
> Is it a bug in automake's vala extensions or am I doing something wrong?
>
> Thanks,
>
> Marcin
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] How to get the base class name with out the spacename?

[Daniel Espinosa]

From LibreSCL source, at

https://github.com/powerwaremediacore/librescl/blob/master/librescl/Serializable.vala

You always know your class prefix because the name space, in your case
PlatformX, Then just use:

nname = get_type ().name ();

  if ("Lsclt" in nname)

nname = nname.replace ("Lsclt","");

this is, from the type name get a string and replace the prefix (name
space) with nothing, and you'll get your class name.
El nov. 15, 2015 8:04 PM, "Matrix"  escribió:

> i'm implementing a simple ORM model,  which will crate the table refer
> to the class name
>
>
> namespace PlatformX {
> public class User () {
> .// with create a database table named user or users
> }
> }
>
>
>
> 在 2015年11月16日 02:24, Al Thomas 写道:
> >> From: Matrix 
> >> Sent: Sunday, 15 November 2015, 14:45
> >> Subject: [Vala] How to get the base class name with out the spacename?
> >>
> >> Hi :
> >>
> >> i want to get the base class name with out the spacename
> >>
> >> for example :
> >>
> >> namespace PlatformX {
> >> public class User () {
> >> this.get_type().name();
> >> }
> >> }
> >>
> >> the name is PlatformXUser not User .
> >>
> >> any methods to query this ?
> >
> > Why would you want to do that?
> >
> > Class names should be for programming, not presenting nicely formatted
> strings.
> > It makes sense to prepend the namespace. This avoids any name conflict
> with another
> > class of the same name, but in a different namespace.
> >
> > If you are looking to create multiple classes of the same name, but each
> doing
> > things in a different way, then you want to be using interfaces. That
> way each
> > class has a unique class name, but the interface it implements is the
> same name.
> > This is how you achieve polymorphism in Vala. There is then nothing
> stopping you
> > from using the interface name as the type in a methods parameters. This
> allows
> > you to pass different classes of object to the method, so long as they
> implement
> > the common interface.
> >
> > Hope that makes sense,
> >
> > Al
>
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

[Vala] Fwd: Re: GenericArray problem

[Daniel Espinosa]

-- Mensaje reenviado --
De: "Daniel Espinosa" 
Fecha: oct. 17, 2015 7:58 AM
Asunto: Re: [Vala] GenericArray problem
Para: "Andy Lees" 
Cc:

In LibreSCL (www.librescl.org) I just declare an empty class derived from a
generic one, this makes to call

var a = new Intclass ();

Just works.

If you want a binding friendly class definition you should define your own
get/set methods returning the actual value type not a generic, as in:

https://github.com/powerwaremediacore/librescl/blob/master/librescl/tDA.vala

I plan to add iterator methods to collections, this will allow bindings to
use them on loops. Because we relay on Gee, its iterators are generic
making hard/impossible to use on GObject Introspection bindings.
El oct. 16, 2015 6:22 PM, "Andy Lees"  escribió:

> Hi,
>
> If I declare a derived class of GenericArray, like so:
>
> public class IntArray : GenericArray {
>   public IntArray() {
>   }
> }
>
> I get a gcc error, like so:
> /tmp/a.vala.AH856X.c: In function ‘int_array_new’:
> /tmp/a.vala.AH856X.c:66:2: error: too few arguments to function
> ‘g_ptr_array_new_with_free_func’
>   self = (IntArray*) g_ptr_array_new_with_free_func ();
>
> whereas with Array (for example) it just works.
>
> Is there something I'm doing wrong, or is this a bug?
>
> Using Vala 0.30.0
>
> Regards,
>
> Andrew Lees
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Json.Searializable implementation troubles

[Daniel Espinosa]

2015-08-10 0:48 GMT-05:00 Luc Chante :

> Hi,
>
> I don't clearly understand what you want. You are looking for maintainers
> for GXml ?
>

No really.



> But, why should I use GXml for JSON serialization ?
>
>
>
May you want to study GXml.Serializable implementation called
SerializableObjectModel, in order to check how:

a) access GObject properties
b) "ignore" some of them when they should not be serialized
c) manage "unknown" nodes (representing properties, values and so), in
order to not fail but get all "know" values into your GObject instance
d) use Gee collections on Serializable objects

GXml have a SerializableJson implementation, it is not really JSON, but it
is called that way. It have not maintener and should be removed from GXml
soon, unless you want to re-implement it to use GLib.Json.

May you want to implement GXml.Serializable, for your own in your project.

Point here, you can simply study GXml.Serializable or step up to implement
a new JSON in GXml. In both cases, I could help you if you want.

Cheers.



> Le sam. 8 août 2015 à 13:06, Daniel Espinosa  a écrit :
>
>> In GXml [1] we access to GObject properties, serialize /deserialize,
>> 'select' witch property to avoid in serialization, use a concept of Node
>> and more, may you can review.
>>
>> GXml is for xml documents, but it has an implementation it is not for
>> Json, even if it is not really Json string representation. May you want to
>> improve that to use GLib Json, implementing GXml.Serializable interface and
>> learn how to access properties by studying the ObjectModel implementation
>> (is a .Net like xml serialization to map GObject to xml). If you, or any
>> other don't take GXml's Json maintenance I will have to remove it, because
>> it needs to be rewritten. Even though I can help you any time.
>>
>> [1] git.gnome.org/browse/gxml
>> El ago. 8, 2015 3:16 AM, "Abderrahim Kitouni" 
>> escribió:
>>
>>> Hello Luc,
>>>
>>> Le 8 août 2015 06:39, "Luc Chante"  a écrit :
>>> >
>>> > Hi,
>>> >
>>> > I'm trying to implement Json.Serializable interface.
>>> > For the moment, I've just made a lazy implementation (see the attached
>>> > file), which mocks default behavior of Glib.Object serialization.
>>> >
>>> > To test :
>>> [...]
>>> >
>>> > There is 2 issues :
>>> >
>>> > The 'list_properties' is never called (it doesn't override the base
>>> one).
>>>
>>> You are using the "new" keyword, which means it's a new method (unrelated
>>> to any method with the same name in a base class or interface). For
>>> implementing an abstract method, you don't need any modifier; for
>>> overriding a virtual method, use "override"
>>>
>>> I'm not sure about the rest, I never used it.
>>>
>>> HTH,
>>> Abderrahim
>>>
>> ___
>>> vala-list mailing list
>>> vala-list@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/vala-list
>>>
>>


-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Json.Searializable implementation troubles

[Daniel Espinosa]

In GXml [1] we access to GObject properties, serialize /deserialize,
'select' witch property to avoid in serialization, use a concept of Node
and more, may you can review.

GXml is for xml documents, but it has an implementation it is not for Json,
even if it is not really Json string representation. May you want to
improve that to use GLib Json, implementing GXml.Serializable interface and
learn how to access properties by studying the ObjectModel implementation
(is a .Net like xml serialization to map GObject to xml). If you, or any
other don't take GXml's Json maintenance I will have to remove it, because
it needs to be rewritten. Even though I can help you any time.

[1] git.gnome.org/browse/gxml
El ago. 8, 2015 3:16 AM, "Abderrahim Kitouni" 
escribió:

> Hello Luc,
>
> Le 8 août 2015 06:39, "Luc Chante"  a écrit :
> >
> > Hi,
> >
> > I'm trying to implement Json.Serializable interface.
> > For the moment, I've just made a lazy implementation (see the attached
> > file), which mocks default behavior of Glib.Object serialization.
> >
> > To test :
> [...]
> >
> > There is 2 issues :
> >
> > The 'list_properties' is never called (it doesn't override the base one).
>
> You are using the "new" keyword, which means it's a new method (unrelated
> to any method with the same name in a base class or interface). For
> implementing an abstract method, you don't need any modifier; for
> overriding a virtual method, use "override"
>
> I'm not sure about the rest, I never used it.
>
> HTH,
> Abderrahim
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

[Vala] GXml 0.6.0 Released

[Daniel Espinosa]

GXml library to provide XML parsing and manipulation capabilities. It is
written in Vala and provides:

* DOM API implementing at least W3C DOM Level 1 Core
* Serialization framework to XML, using existing implementations or create
custome   ones.
* A pure Vala XML tree generator classes
* A Gee/GObject based API for easy access objects in XML tree

Its functionality is obtained by wrapping libxml2 library, for tree parsing
or storage.

This new version is API/ABI incompatible with 0.4 series.

Most work has been on simplifying API for Vala programmers users, using
interfaces and Gee classes, allowing to create new backends based or
different from libxml2. This work allowed to re-implement existing classes
without radically modify API for existing applications and makes room to
improve performance and memory usage.

News and changes are as follow:


* Added new interfaces to simplify implementing new backends for XML
reading/writing, containers are Gee ones.

* Renamed GXml 0.4 DOM classes to prefixing a "x", to avoid conflicts with
new interfaces

* GXml DOM classes, now implement new interfaces

* GXml DOM classes now implement Gee interfaces to access directly to
libxml2 structures,
  reducing extra processing and memory consumption when they are referenced
from permanent
  on memory GObject classes. Re-implementing most other DOM classes to
implement Gee classes
  in on roadmap, to reduce memory and possibly increase performance on
parsing.

* Improved XML namespaces handling

* Added new TwDocument class, as pure Vala XML tree container
implementation of
  new interfaces

* Implemented a 3-5 times faster XML writer using TwDocument and libxml2
xmlTextWriter.
  A new TwDocument and xmlTextReader is on roadmap, to improve parsing
performance.

* Serializable framework ported to new interfaces, allowing to use different
  backends when serialize/deserialize GObjects.

* Serializable and its implementations, has gained serialization
performance improvements
  using TwDocument and better namespace handling.

* Improved documentation

* Added --enable-performance-tests, just to reduce the time required to run
all
  unit tests.

New interfaces makes room to convert any GObject as a GXml.Node, making
de/serialization more transparent and possibly better performance and
memory usage reduction, by avoiding intermediate XML trees using libxml2 or
TwDocument. Another plan includes, GObject mapping to XSD.

You can get source code from:

https://download.gnome.org/sources/gxml/0.6/gxml-0.6.0.tar.xz

or from its repository at:

https://git.gnome.org/browse/gxml

-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Generating JSON in Vala

[Daniel Espinosa]

For Gee containers as properties, at GXml[1] Serializable framework it use
a method in a interface implemented by the class having them, where you
initialize all your Gee classes, because they can't be created on generic
code due to its generic nature.

[1] git.gnome. org/browse/gxml
El jul. 1, 2015 6:30 AM, "Nick Watts"  escribió:

> Thanks heaps Guillaume for the tip on Json.gobject_serialize(), that made
> it super-simple to add GObjects as a possible input type.  I've just
> finished adding support for booleans, arrays and objects to EasyJSON, it's
> now pretty much feature-complete (demo on the github page at
> https://github.com/unyieldinggrace/EasyJSON).
>
> One issue that I bumped into was that I couldn't find any one-liner syntax
> to create a Gee.ArrayList?  I'm sure I'm just being a n00b, but It appears
> that Gee.ArrayList.wrap() is deprecated?
>
> Anyone know of a more concise way to create an ArrayList than calling
> list.add() for each item?
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Flowgraphs for Gtk in Vala

[Daniel Espinosa]

I've finished to port.

I've added all benefits of GXml has like: your project is able to build for
Windows, i18n and could packaged to Debian easy.

If you accept my pull, is trivial to add it to Mingw packages and available
to Windows users.

You can continue using CMake if you want, just make sure provide equivalent
features, because some others would like to use it for fast compile and
other goodness it has, I really don't know.
El may 21, 2015 1:13 PM, "Daniel Brendle"  escribió:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 05/21/2015 07:19 PM, Daniel Espinosa wrote:
> > Thanks to be open for other build systems.
> >
> > I've ported GXml [1] from CMake to Autotools and used the last in
> > all my Vala projects, then I think I can do the job :-)
> >
> > I'll fork your repository and make a pull request for it.
> >
>
> Awesome. I am thrilled to see the results.
>
> But, as this is loosely related to Vala in general i'll ask right here:
>
> Where do you see the benefits of autotools over cmake in a
> vala-project? I know that the GNOME project requires its official
> sub-projects to use autotools als buildsystem and i know that debian
> packages is most simple when the source tarball uses autotools because
> one can leave the debian/rules-file as is. But does this really
> compensate for the time-costs of learning and using the (in my
> personal view) highly unintuitive autotools? Is there any technical
> aspect i am missing here?
>
> Yours, Grindhold.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJVXiBlAAoJEBuqgJs6izSEP1QP/32Ouzg6o2BmvkvMPrXYoXkL
> cigGLBkTse1OyYTBTLN3Tl6UhoMDhhpIP0/NCtE/rQaT/Fjx/kxF+qL5owOwgEfs
> DJh9h6z6MFrsROn3LNeyDx6pZJn7WZcQXzgdEn0IVrYuN0BwjZ/slI1Tv3Ei84fR
> msTrGudAMWyAmvy40c44eopVF2LxX4FIB/aGD0ymm3xhsTW0Vflh8HVv4mjGZFqL
> da5bUNGzgPVSaZgfuFpVYbsdO/UqUBrQlQVbiCw7IyNwj1tR9rUpKuiAT/wFUGC6
> si83r//aloKVwxcmXFDuHYyngpoOfB3pny/m9oad9QuR+H/V1tXmuNPe/wHAYx47
> MNbH9uH3M2AwGsu6lxGv5lCX/IDJt34JkZSU1NU8cjCRKtV8uyobfryGJBUJpPvP
> +MSxYEzj0UxQnK2TqNQniuIv8A+8DlIeTwJ4ozCX/aHWprOkbYp0PxPts4RKACex
> Oa7Uq2Wzmpf8TJ8cjDbu1sTyZpFXjhPSbUGvSTw1FNe8a4xz4zPQMLqWowBsqhy9
> 9NQs5BAz7QfapqiWOT5V5kwaJrSB7rTAkLKdLeUfdYGbUrCZurfUglUzkGuDU9O2
> ePXj6fgP58b6qpw9qdBbWeq06pF2EwjDHlR0AesaDOeVt/i0a4QE5vBUlpauwsmh
> kg8zrRv6cRySRV+gumo9
> =pmM3
> -END PGP SIGNATURE-
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Flowgraphs for Gtk in Vala

[Daniel Espinosa]

Thanks to be open for other build systems.

I've ported GXml [1] from CMake to Autotools and used the last in all my
Vala projects, then I think I can do the job :-)

I'll fork your repository and make a pull request for it.

[1] http://git.gnome.org/browse/gxml

2015-05-21 10:59 GMT-05:00 Daniel Brendle :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 05/21/2015 01:32 PM, Daniel Espinosa wrote:
> > Is it possible to be used to create Logic diagrams?
> >
> > Why cmake?
> >
> > Is it possible to port it to autotools? (Do you need help?)
>
>
> If you mean logic digarams as in "i have nodes that emit logical ONEs
> and ZEROs, i have nodes that represent logic gates like AND OR XOR NOT
> e.t.c and i have nodes that output the results", then yes. of course
> you can write logic diagrams with it. Of course you have to implement
> your own Nodes for this, but this is no problem at all since you can
> inherit from GtkFlow.Node as baseclass and implement your logic on top
> of it. See the example calculator.py in the examples folder.
>
> Using cmake has a simple reason: I spend two days trying to use
> autotools in one of my vala projects and gave up frustratedly with no
> mentionable result. Then i tried cmake and got a vala project up and
> running in one night. I am very happy with it and continued to use it
> for other projects.
> Currently I see no necessity to switch, but if you want to do it and
> maintain it, please do and send a pull request.
> To be honest, i am a bit curious what i did wrong and to see a correct
> solution how to build such a project with autotools.
>
> If you try the port, please be aware that I created some cmake logic
> to detect if a system has the libgee-1.0 or libgee-0.8-package
> installed and sets the compilerflags accordingly. This is necessary
> because of the unlucky decision of the gee-developers to do a
> backwards version-number-change from 1.0 to 0.8. On debian jessie
> there are still libgee-1.0-packages around. Without that logic it
> would be impossible to build on debian older than stretch (testing).
>
> Yours, Grindhold
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJVXgDbAAoJEBuqgJs6izSEqJAP/2XV2VhkNH/0BCWG5ufMlXDh
> cnoMweeuL2Z5eL+OyX/2zEuhfPqxfg8th/6rim5yMpQ6sdRAk38zZKRe5cj/sUUc
> dsH4DE/aTv11g9qVLj2rinRMgAKeN0U+b4jub1oXGfHtM1vSTUqCjoDEn+EiwfRH
> h7JvmFJWL3muiSaow+pAb/+aUWFsgdcjZTLqc/minprqrewh1iZWa2VUabqXOGDY
> GJYfOUgniguZWR2JWWjwGWgYe1O7N051UChMxGQAhMqjlvXko7pRya6NEZtqQnhT
> GLyeihmses+YYRzS5r6Qf7Lresj7mvNifdO3Nt5btZjzWusWp0IwbACRNm+C2/gn
> snMLRcOl7DjD9v/o99O2dGo/Efucm0q6V2IaVSepkbh9mcfvoKGb10hYsbs66Hmh
> cIZfZa1aHBP6QXHnm6jljC/Y0TH3c6WtmVb2qrATCUTemuDoipYs91V3/MonJLBy
> 4BrmCjKkq6pbyB8vcyw6+EvtSmsnK78AFwUOV8RzVTjes3oF+eV9SWydQDLpSxeq
> BHYXw8A9NY8KNh/Mpme2GfF5G/lgM28nc2v41wDmL2Bq9EdTGZBcpcSTDvRscCly
> ECHcjmH4Q1g0vCG2B9h0VqaTbhCvsaZW3no3OPFybAj16CvGRCZpfTSo7x7TLHN5
> 7njNczaHk1Vuv7HChXOW
> =gsmy
> -END PGP SIGNATURE-
>



-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Flowgraphs for Gtk in Vala

[Daniel Espinosa]

Is it possible to be used to create Logic diagrams?

Why cmake?

Is it possible to port it to autotools? (Do you need help?)
El may 20, 2015 10:04 PM, "Daniel Brendle" 
escribió:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi there!
>
> I wanted to introduce you to a project that has been on my
> "to-do"-stack for a long time. Now it grew to be somewhat presentable.
> Meet our very own Blender-Node-Editor-like flowgraph library for Gtk3:
>
> https://github.com/grindhold/libgtkflow
>
> GtkFlow gives you a new Widget, the GtkFlow.NodeView you can add nodes
> to this view that have inputs and outputs (so called sinks and sources
> respectively). These Nodes and the connections between them can be
> arranged by the user by dragging and dropping.
> It provides an easy way for users to communicate to a program how
> things interact and how things are connected.
>
> If you develop UI (especially for GNOME-related stuff), please let
> yourself be inspired how Flowgraphs could enhance your UI-concept.
> Some usecases i thought about are:
>   - A GUI for GStreamer that you can build and export your GStreamer
> pipelines from/to
>   - UI Replacement for GNURadio's Flowgraph implementation
>   - Video Compositing for PiTiVi
>
> I am eager to hear about your thoughts of possible usecases and
> especially for feedback about the library itself.
>
> If anyone can use it, i'd also be happy about helpers that engage in
> pushing the project further.
>
>
> Yours, Grindhold
>
> [I posted the same email to gtk-l...@gnome.org . If this is not
> acceptable, please tell me. I won't do it again]
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJVXUtWAAoJEBuqgJs6izSEvncP+QFalVHLB/IxT6/DowGMQyMU
> 04RPuCkFgIGztgJRAJh2M8AHN5LL9IeBM8fyGJTbF2CLhmf+mY7LU7BCd8GZkFBX
> +XsrDS7FNyPRCsfiyja5vY3jvn0pKyVURB03fauI/RSiessyJN1L71nfBo9fNbgm
> 5NRRCnVOs85EVlVNKT3dibJpatt3l9SNqdiHn80/dRBSoCV59BkemTMdk9Nd4SP/
> RcQxgFXL6gLMwuFXP3PEHFSZqYFhCBlTectNuqrkZ7Bw6boYcwC/f1Ro20s9YFTQ
> 8pmL9TTTy9IkSR15QATibHGkEemJDb2murY3YLdUZ5DRVtGNyn2wC6+llUu367PQ
> YKc2GX4puyavj/UmeXkhu6TvZlHzs8MCPLQD0JFI+0Gq5USWFlZvrBBqZsyYUAgI
> vpRXRT2IK3nG0fIQSTmLhzRJLzLE+omNmT1UuOfNHZVq3yw5OZQeNTO1cwQmB0eW
> Ef4OPzJq53Jd3HXz1mY4AktBi/WC7LRp3qvL2FGU52J/MCd8kRD4KrwoJK5pNcJb
> QIBCpXiCZvLVrFoiwbRB5+oXgEC3NaBfKXzJTA4ql23uk2pNpUqvp33JvrLqIxFj
> aKX9NoOq4HEHNpOia4r+SdW2Ao0sikosV6TMIEhMOYry+86AuEvNDHXcbSiW3RNS
> R8gv2HFMp/rom08IHmCr
> =vvRh
> -END PGP SIGNATURE-
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] libsoup vapi

[Daniel Espinosa]

Hey!

I've finally found the problem and solved it.

I've added metadata from Vala repository and merged to libsoup's one, and
now with attached patch, you can generate VAPI files API equivalent from
libsoup source code and the one ditributed with Vala.

With this patch, no VAPI break exists between both repositories, with the
advantage that VAPI files will be generated automatically for all new API
added to libsoup.

Please review, compile and make a diff between both VAPI files and if you
approve it I could push upstream.

2015-02-12 16:14 GMT-06:00 Zeeshan Ali (Khattak) :

> The issue is mentioned in the reverting commit log I provided URL for.
> Please diff your vapi against vala provided one and coordinate with both
> maintainers to ensure a smooth transition for all apps. I think we'd want
> to remove vapi from vala when we add it to libsoup. Thanks for your work on
> this.
> On 12 Feb 2015 18:22, "Daniel Espinosa"  wrote:
>
>> Ok. Thanks.
>>
>> I would like to know your issues, in order to take them in account when
>> adding VAPI generation support for this or other projects.
>>
>> 2015-02-12 11:46 GMT-06:00 Zeeshan Ali (Khattak) :
>>
>>> Hi Daniel,
>>>
>>> As much as I love the idea of upstream libraries providing VAPI, I had
>>> to revert your patch for now. I looked for some obvious way to fix the
>>> issues it caused but I couldn't find any and I got a lot of things to
>>> do before the week ends.
>>>
>>>
>>> https://git.gnome.org/browse/libsoup/commit/?id=7fa8478ef8d9e00b30519df149330ce581fb2632
>>>
>>> --
>>> Regards,
>>>
>>> Zeeshan Ali (Khattak)
>>> 
>>> Befriend GNOME: http://www.gnome.org/friends/
>>>
>>
>>
>>
>> --
>> Trabajar, la mejor arma para tu superación
>> "de grano en grano, se hace la arena" (R) (en trámite, pero para los
>> cuates: LIBRE)
>>
>


-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
diff --git a/configure.ac b/configure.ac
index 5808f84..7c6f4b9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -162,6 +162,10 @@ dnl *** gobject-introspection ***
 dnl *
 GOBJECT_INTROSPECTION_CHECK([0.9.5])
 
+if test "x$found_introspection" = "xyes"; then
+  VAPIGEN_CHECK()
+fi
+
 AC_MSG_CHECKING([for glib-networking (glib TLS implementation)])
 save_CFLAGS="$CFLAGS"
 save_LIBS="$LIBS"
diff --git a/libsoup/Makefile.am b/libsoup/Makefile.am
index 1c71dd2..2337045 100644
--- a/libsoup/Makefile.am
+++ b/libsoup/Makefile.am
@@ -1,6 +1,8 @@
 ## Process this file with automake to produce Makefile.in
 
 EXTRA_DIST =
+CLEANFILES =
+
 
 include $(GLIB_MAKEFILE)
 
@@ -273,6 +275,15 @@ Soup_2_4_gir_FILES = \
 
 INTROSPECTION_GIRS += Soup-2.4.gir
 
+if ENABLE_VAPIGEN
+libsoup-2.4.vapi: Soup-2.4.gir Soup-2.4.metadata Soup-2.4-custom.vala
+	$(VAPIGEN) --metadatadir=$(top_srcdir)/libsoup --pkg gio-2.0 --library=libsoup-2.4 $^
+
+vapidir=$(VAPIDIR)
+vapi_DATA=libsoup-2.4.vapi
+CLEANFILES += $(vapi_DATA)
+endif
+
 if BUILD_LIBSOUP_GNOME
 
 # GNOME extensions
@@ -300,7 +311,7 @@ gir_DATA = $(INTROSPECTION_GIRS)
 typelibdir = $(libdir)/girepository-1.0
 typelib_DATA = $(INTROSPECTION_GIRS:.gir=.typelib)
 
-CLEANFILES = $(gir_DATA) $(typelib_DATA) $(BUILT_SOURCES)
+CLEANFILES+= $(gir_DATA) $(typelib_DATA) $(BUILT_SOURCES)
 
 endif
 
diff --git a/libsoup/Soup-2.4-custom.vala b/libsoup/Soup-2.4-custom.vala
new file mode 100644
index 000..35449e9
--- /dev/null
+++ b/libsoup/Soup-2.4-custom.vala
@@ -0,0 +1,168 @@
+namespace Soup {
+	[CCode (type_id = "soup_auth_domain_basic_get_type ()", cheader_filename = "libsoup/soup.h")]
+	public class AuthDomainBasic : Soup.AuthDomain {
+		public static void set_auth_callback (Soup.AuthDomain domain, owned Soup.AuthDomainBasicAuthCallback callback);
+	}
+
+	[CCode (type_id = "soup_auth_domain_digest_get_type ()", cheader_filename = "libsoup/soup.h")]
+	public class AuthDomainDigest : Soup.AuthDomain {
+		public static void set_auth_callback (Soup.AuthDomain domain, owned Soup.AuthDomainDigestAuthCallback callback);
+	}
+
+	[Compact]
+	[CCode (copy_function = "g_boxed_copy", free_function = "g_boxed_free", type_id = "soup_buffer_get_type ()", cheader_filename = "libsoup/soup.h")]
+	public class Buffer {
+		[CCode (has_construct_function = false)]
+		public Buffer.subbuffer (Soup.Buffer parent, size_t offset, size_t length);
+	}
+
+	[Deprecated (replacement = "Soup.ProxyURIResolver")]
+	[CCode (cheader_filename = "libsoup/soup.h", type_cname = 

Re: [Vala] Research project on the Vala compiler

[Daniel Espinosa]

You could add two projects in your list:

GXml:  git.gnome.org/browse/gxml
LibreSCL: github.com/pwmediaconsulting/librescl

Both are written in Vala and generate C code to compile binaries.

I'm the maintener  of both then I can help you and of course I'm one of the
most interested.

Both are LGPL and I've found lot of memory leaks and I start to investigate
generated C source code.
El abr 3, 2015 1:10 PM, "Guillaume Poirier-Morency" <
guillaumepoiriermore...@gmail.com> escribió:

> Hi everyone!
>
> I am conducting a small research project on the Vala compiler that
> would principally study how it affects different quality metrics
> (size, complexity, etc...) during the implementation step of the
> development.
>
> My goal is to confirm the relevance of metrics measured in the
> generated C code to evaluate the quality of the sources. This is
> important considering the impressive amount of tools that have been
> developed to measure the quality of C/C++ sources.
>
> By the same time, I also want to provide an empirical model that would
> allow transformations of the measured metrics into significative
> measures for the sources. For example we could be interested into
> knowing the relationship between the size of input and output of valac
> or the impact on the cyclomatic complexity.
>
> Therefore, I am interested in projects of all size written in Vala
> that generates C code during the build process. It would also be great
> to have indications on how the sources are structured and how I can
> extract them.
>
> Ex. cloc $(find src -name '*.vala') $(find build -name '*.c')
>
> Yet, I have these projects in mind:
>
>   * vala 30 KLOC
>   * valadoc 23.5 KLOC
>   * gnome-pomodoro 4.6 KLOC
>
> I plan to use it as an empirical justification to setup a set of
> measurements to control the quality of Valum, a web micro-framework I
> will work on this summer.
>
> The results will be all released under a Creative Commons license.
>
> Thanks in advance :)
>
> --
> Guillaume Poirier-Morency 
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Base64 encode/decode

[Daniel Espinosa]

I've used this for encode/decode strings in a GTK app, is it necessary to
call GLib.Intl.setlocale at app start?

And if it is a GLIB library,  should I call setlocale to initialize it?

El mar 10, 2015 8:14 PM, "Evan Nemerson"  escribió:
>
> It decodes fine.  The same thing happens when you try to print t instead
> of s2.  You forgot to call setlocale:
>
> GLib.Intl.setlocale (GLib.LocaleCategory.ALL, "");
>
> Or, if you're using 0.28, just GLib.Intl.setlocale(); will work.
>
>
> On Tue, 2015-03-10 at 16:43 -0600, Daniel Espinosa wrote:
> > I would like to know how Vala Base64 encode/decode UTF-8 strings.
> >
> > If my string have no special characters, Base64 encode/decode works
> > flawlessly.
> >
> > But if it has a character like "á" it fails to decode, well when try to
> > cast to string fails.
> >
> > Code:
> >
> > public class App : Object
> > {
> > public static void main ()
> > {
> > var app = new App ();
> > var t = "á";
> > var s = GLib.Base64.encode (t.data);
> > var s2 = GLib.Base64.decode (s);
> > GLib.message ("TEXT: "+(string)s2);
> > }
> > }
> >
> > Text printed is:
> >
> >  ** Message: string.vala:10: TEXT: ?
> >
> > Expected message should be:
> >
> > ** Message: string.vala:10: TEXT: á
> >
> > Please help me.
> >
>
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

[Vala] Base64 encode/decode

[Daniel Espinosa]

I would like to know how Vala Base64 encode/decode UTF-8 strings.

If my string have no special characters, Base64 encode/decode works
flawlessly.

But if it has a character like "á" it fails to decode, well when try to
cast to string fails.

Code:

public class App : Object
{
public static void main ()
{
var app = new App ();
var t = "á";
var s = GLib.Base64.encode (t.data);
var s2 = GLib.Base64.decode (s);
GLib.message ("TEXT: "+(string)s2);
}
}

Text printed is:

 ** Message: string.vala:10: TEXT: ?

Expected message should be:

** Message: string.vala:10: TEXT: á

Please help me.

-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] RELEASED: GXml 0.4.0

[Daniel Espinosa]

New fast track 0.4.1 release for GXml.

This version fixes compilation with Vala 0.26.

Many thanks to Jürg Billeter, for his comments and advise about this
problems.

2014-09-23 14:47 GMT-05:00 Daniel Espinosa :

> I'm pleased to announce immediately availability of new version of GXml.
>
> =
> Version 0.4.0
> =
> - Added Examples (Richard Schwarting)
> - Improved Build system (Daniel Espinosa)
> - Windows crosscopilation support (Daniel Espinosa)
> - Added/Improved Serialization Framework (Richard Schwarting, Daniel
> Espinosa)
> - Added missing License (Richard Schwarting)
> - Renamed DomNode to Node (Richard Schwarting)
> - Added Unit Tests (Richard Schwarting, Daniel Espinosa)
>
> Known issues include:
>
> - Requires Vala 0.20
>
>
> About GXml:
>
> GXml provides a GObject API for manipulating XML.  Most functionality is
> provided through libxml2.  Currently, GXml  provides the DOM Level 1 Core
> API.
>
> Home page:
> https://wiki.gnome.org/GXml
>
> Mailing list:
> gxml-l...@gnome.org
>
> Download source code:
> https://download.gnome.org/sources/gxml/0.4/
>
>
> Git repository at:
> https://git.gnome.org/browse/gxml
>
> --
> Trabajar, la mejor arma para tu superación
> "de grano en grano, se hace la arena" (R) (en trámite, pero para los
> cuates: LIBRE)
>



-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

[Vala] RELEASED: GXml 0.4.0

[Daniel Espinosa]

I'm pleased to announce immediately availability of new version of GXml.

=
Version 0.4.0
=
- Added Examples (Richard Schwarting)
- Improved Build system (Daniel Espinosa)
- Windows crosscopilation support (Daniel Espinosa)
- Added/Improved Serialization Framework (Richard Schwarting, Daniel
Espinosa)
- Added missing License (Richard Schwarting)
- Renamed DomNode to Node (Richard Schwarting)
- Added Unit Tests (Richard Schwarting, Daniel Espinosa)

Known issues include:

- Requires Vala 0.20


About GXml:

GXml provides a GObject API for manipulating XML.  Most functionality is
provided through libxml2.  Currently, GXml  provides the DOM Level 1 Core
API.

Home page:
https://wiki.gnome.org/GXml

Mailing list:
gxml-l...@gnome.org

Download source code:
https://download.gnome.org/sources/gxml/0.4/


Git repository at:
https://git.gnome.org/browse/gxml

-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] [Genie] Build for windows under linux. Using minwg.

[Daniel Espinosa]

Please forgive me for my errors on writing, I'm on my phone.

My instructions are for Cross compile on Linux to Windows. Just don't
forget to use -mwindows to avoid terminal when execute your code on
windows. If use valac use -X before to pass it to the mingw-w64 compiler.
El sep 14, 2014 1:22 PM, "Daniel Espinosa"  escribió:

> I can help you. You can see at GXml project in git.gnome.org. I've
> managed to build it under windows with no problems.
>
> Just download GTK+ for windows bundle and use see to change prefix
> variable I'm all PC files to point to the Dir you uncompress this bundle.
> You must install mingw-w64 on your distribution.
>
> Then on terminal set PKG_CONFIG_PATH to pont the directory you uncompress
> gtk+ bundle and add to the path lib/pkgconfig directory; this is very
> important, if you don't set correctly, pkg-config will find PC files from
> your Linux Installation and you compilation will fail with lot errors on
> headers.
>
> When configure your software, use --host= to the platform you want to use,
> 32 or 64 bits. On Ubuntu you must use x86_64-w64-mingw32 for 64 bits and
> i686-w64-mingw32, if you get lot of errors from included  headers then the
> above host targets are wrong.
>
> If most module use gobject introspection, you must disable because bundle
> doesn't include it.
>
> As you can see on GXml, I've use valac to get C code then use the
> mingw-w64 compiler to compile it to get exe and DLLs.
>
> C code must depend on a rule that use valac to get it. But be this is not
> required, may you want to use valac directly, in theory it must use
> mingw-w64 compiler because the host setting.
> El sep 14, 2014 8:29 AM, "Gontzal Uriarte" 
> escribió:
>
>> Hi!!
>>
>> I have finished a "Katamotz Ejercicios" new application for reading
>> learning and teaching. Is a Genie application and it uses gtk-3, pango,
>> cogl, clutter, clutter-gtk and gstreamer. No problems for building under
>> linux for linux, but how do it for Windows. I have seen some tutorials
>> from
>> Tarnyko and others but... there is anyone for help me?
>>
>> Thanks. Txasatonga.
>> ___
>> vala-list mailing list
>> vala-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/vala-list
>>
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] [Genie] Build for windows under linux. Using minwg.

[Daniel Espinosa]

I can help you. You can see at GXml project in git.gnome.org. I've managed
to build it under windows with no problems.

Just download GTK+ for windows bundle and use see to change prefix variable
I'm all PC files to point to the Dir you uncompress this bundle. You must
install mingw-w64 on your distribution.

Then on terminal set PKG_CONFIG_PATH to pont the directory you uncompress
gtk+ bundle and add to the path lib/pkgconfig directory; this is very
important, if you don't set correctly, pkg-config will find PC files from
your Linux Installation and you compilation will fail with lot errors on
headers.

When configure your software, use --host= to the platform you want to use,
32 or 64 bits. On Ubuntu you must use x86_64-w64-mingw32 for 64 bits and
i686-w64-mingw32, if you get lot of errors from included  headers then the
above host targets are wrong.

If most module use gobject introspection, you must disable because bundle
doesn't include it.

As you can see on GXml, I've use valac to get C code then use the mingw-w64
compiler to compile it to get exe and DLLs.

C code must depend on a rule that use valac to get it. But be this is not
required, may you want to use valac directly, in theory it must use
mingw-w64 compiler because the host setting.
El sep 14, 2014 8:29 AM, "Gontzal Uriarte"  escribió:

> Hi!!
>
> I have finished a "Katamotz Ejercicios" new application for reading
> learning and teaching. Is a Genie application and it uses gtk-3, pango,
> cogl, clutter, clutter-gtk and gstreamer. No problems for building under
> linux for linux, but how do it for Windows. I have seen some tutorials from
> Tarnyko and others but... there is anyone for help me?
>
> Thanks. Txasatonga.
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] [ANNOUNCE] Portable Windows version (MonoDevelop 5.1.4, vala 0.25.1, mingw64 4.9.1)

[Daniel Espinosa]

For OpenGL may you want to look at:

https://developer.gnome.org/cogl-2.0-experimental/stable/
El ago 30, 2014 11:36 AM, "Marek Gibek"  escribió:

> Hi All!
>
> I saw that many Windows users think that Vala is usable only under
> Linux. This is of course not true. I think it has enormous
> multiplatform potential. For me it lacks OpenGL based, MVVM (like WPF)
> mutliplatform UI framework, but that can be done...
>
> To make Vala more popular on Windows platform I created portable
> bundle ready to play with the language. It is based on
> MonoDevelop/XamarinStudio 5.1.4.
>
> You can download it there:
> 
> https://sites.google.com/site/gibekm/programming/vala/windowsportable
>
> Screenshot:
> 
>
> https://sites.google.com/site/gibekm/_/rsrc/1406733880544/programming/vala/windowsportable/screenshot.png
>
>
> My changes:
> 
>
> There was obsolete MonoDovelop plugin for Vala. I updated it to
> version 5. I also rewritten code that handles project references.
>
> It behaves more like in C# and Visual Studio now:
> - paths to other projects in solution are now relative (so you can
> easily move solution folder)
> - output from referenced projects/libraries is copied to application
> output folder (it is much easier to deploy final application) -  it
> takes this info from .pc files (copy_to_output variable)
> - project references are pointing to .mdproj not output binary and are
> configuration (release/debug) aware now
> - fixed: compiler flags can be specified per configuration now
>
> It lacks code completion and debugger support. This can be added later
> (code completion was a part of previous version - the code needs to be
> converter to newer one).
>
> I haven't tested it under Linux, but it should be easy to port (if
> required) Vala plugin there, too.
>
> Regards,
> Marek Gibek
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Thread Support

[Daniel Espinosa]

2014-08-13 18:08 GMT-05:00 Jim Nelson :

> On Wed, Aug 13, 2014 at 1:13 PM, Daniel Espinosa  wrote:
>
> read_async.begin();
>>
>
> For the comment above, I think this form must be deprecated to add clear
> meaning in Vala code for async functions, even the compiler must rise an
> error when yield is used in unasync function.
>
>
> It's not about readability, they are different ways of invoking the same
> method.  The first (with "yield") can only be used within an async method.
>  It means what it looks like, the caller will yield control to read_async()
> until the call returns.  The second (with ".begin") can be called from any
> method.  It initiates read_async() but returns immediately; you might think
> of it as scheduling the call in the background and not waiting for it to
> complete.  (You can pass a completion callback with .begin that is called
> when finished.)
>
> Then this is a bug in glib-2.0.vapi, because it seds:
>
> [Deprecated (since = "2.32", replacement = "new Thread ()")]
> [CCode (simple_generics = true)]
> public static unowned Thread create (ThreadFunc func, bool
> joinable) throws ThreadError;
>
>
> I'm not sure what you're seeing there.  If you're using Vala 0.20, I would
> recommend upgrading to at least the latest stable version (0.24).
>
>
These annotations makes to rise warning messages, suggesting to change your
code, but no prevent developer how to proceed.

Adding some more descriptions like add " and valac's --target-glib=2.32
flag"text to replacement attribute, in order to help developer how to
proceed. Is this description correct? developer must use --target-glib in
order to enable new features?


> Warning from compiler must suggest to use this instead to just warn about
> use implicit .begin is deprecated. Message could be:
>
> "async functions should use attribute .begin or 'yield' modifier when it
> is called"
>
>
> You might try filing a ticket or, better yet, a patch.
>
> -- Jim
>



-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Thread Support

[Daniel Espinosa]

Thanks for your comments and suggestions.


2014-08-13 14:02 GMT-05:00 Jim Nelson :

>
> On Wed, Aug 13, 2014 at 10:55 AM, Daniel Espinosa 
> wrote:
>
> I have an async function called directly in my code. When compiles I get
> this: XXX: warning: implicit .begin is deprecated
>
>
> That means you called the async method with neither a yield keyword nor
> with the begin modifier.  You need to do either this:
>
> yield read_async();
>
>
This form is not documented in Vala Manual. I'll add it. This seems to be
more convenient for reading, the second could be read as "an object
read_async have a method called begin() and it is called", but the first
means: "you call a function read_async() and yields it up to finish it".
I'll use the first form in my code.



> or this:
>
> read_async.begin();
>

For the comment above, I think this form must be deprecated to add clear
meaning in Vala code for async functions, even the compiler must rise an
error when yield is used in unasync function.


>
> Vala used to support:
>
> read_async()
>
> as being equivalent to using .begin(), but that form was deprecated, hence
> the message you're seeing.
>
> Thread th = new Thread.try ("loading scl", () => {
> async_function (); /*Asinc function */ return null; }); th.join (); Error
> message is: X: error: The name `try' does not exist in the context of
> `GLib.Thread' I've checked glib-2.0.vapi, for both vala-0.20 and 0.22, that
> function is present just for GLIB_2_32, checking my installed version I
> have a 2.40 on a GNOME Ubuntu 14.04 box.
>
>
> Add this flag to valac:
>
> --target-glib=2.40
>
> or:
>
> --target-glib=2.32
>
> Be aware by doing this you're making your app incompatible with earlier
> versions of glib.
>

Then this is a bug in glib-2.0.vapi, because it seds:

[Deprecated (since = "2.32", replacement = "new Thread ()")]
[CCode (simple_generics = true)]
public static unowned Thread create (ThreadFunc func, bool
joinable) throws ThreadError;

Then this makes compiler to throws a warning each time you don't use
--target-glib=2.32 or some thing, and this is a mistake because you are
using "generic" code, if I use Thread.try I'm making back incompatible
code.

If I follow compiler warning to replace deprecated code, I found the
problem above, then defining GLIB_2_32 must be present by default or even
better modify to glib-2.0.vapi to help the developer how to proceed:

[Deprecated (since = "2.32", replacement = "new Thread () and valac's
--target-glib=2.32 flag")]
[CCode (simple_generics = true)]
public static unowned Thread create (ThreadFunc func, bool
joinable) throws ThreadError;



>
> Regarding your code itself, there's a few more problems.  First, you can't
> use  as a type parameter, you must give an actual type that
> represents storage.  "void *" is probably the best way to go if you truly
> have nothing to pass to your threads.
>

Your explanation is a good point to be added to Vala's Manual.


>
> Second, you're calling an async method within the background thread.
>  There's nothing technically wrong with this, but I suspect that's not what
> you really want.  The usual pattern of use is to call the async method from
> your main ("foreground") thread.  The async call might use background
> threads as an implementation strategy (to do the work without blocking the
> foreground thread).
>
> -- Jim
>

You're right, I've changed to

async_function.begin ()

and I've removed Thread, but now I'll use

yield async_function().

for better understanding.

Warning from compiler must suggest to use this instead to just warn about
use implicit .begin is deprecated. Message could be:

"async functions should use attribute .begin or 'yield' modifier when it is
called"

-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

[Vala] Thread Support

[Daniel Espinosa]

I'm using Vala 0.20.

I have an async function called directly in my code. When compiles I get
this:

XXX: warning: implicit .begin is deprecated

But when try this code:

Thread th = new Thread.try ("loading scl", () => {
async_function (); /*Asinc function */
return null;
  });
th.join ();

Error message is:

X: error: The name `try' does not exist in the context of `GLib.Thread'

I've checked glib-2.0.vapi, for both vala-0.20 and 0.22, that function is
present just for GLIB_2_32, checking my installed version I have a 2.40 on
a GNOME Ubuntu 14.04 box.

Then I don't find why this function is not present for the compiler, and
get warnings when try to use Thread.create function.

Tutorials at Vala documentation is not too useful. If found usable your
comments, I can update that documenation for GLib 2.32 and above. Please
help me to improve that documentation.

-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

[Vala] What is the better way to write documentation

[Daniel Espinosa]

I've worked on GXml's Serialization framework for a while. I've added some
classes with a few documentation using valadoc.

Valadoc seems not to release a new stable version soon. Considering use
valadoc from git repository (failed in the past) I would like to add your
code examples.

Is valadoc the way to go?

How can I use DevHelp yo show C documentation or, much better, Gala
documentation?

Is mallard for tutorials an option?

developer.gnome.org points you to gtk-doc and old technology. Is It
outdated?
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] location of generated vala source under autotools

[Daniel Espinosa]

You must read autotools dicumentation. You must read about VPATH building.

You must use special variables $^ and $@ on your Makefile.am in order to
add prefix to sources files to locale them in source directory not build
one.

You can check my work on GXml in git.gnome.org

For GXml I'm adding support to build a Vala library on Windows and use
VPATH.
El abr 30, 2014 9:52 a.m., "Luca Bruno"  escribió:

> On 30/04/2014 16:39, Andy Tai wrote:
>
>> Hi, when using Vala with GNU autotools, if building from somewhere outside
>> the source directory, as commonly with something like
>>
>> (from the top of source tree)
>> cd ../
>> mkdir build
>> cd build
>> ../src/configure && make
>>
>> the intermediate C sources generated from Vala are placed in the source
>> tree instead of the build tree.  This seems to work, but is it the correct
>> behavior in terms of the build behavior?
>>
>>
>>  Vala is known to not be able to build out of tree. There's a bug which
> should fix this: https://bugzilla.gnome.org/show_bug.cgi?id=725497 .
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Planet Vala

[Daniel Espinosa]

I'm interested on blogging about Vala, please let me know more details.

You mean I need to login in GitHub and make a pull request at your
repository?

Could you add a login like system on Planet Vala with a "Request an
account" like option in order to help on manage potential bloggers on the
process or add a link to a wiki help page on the process.
El mar 21, 2014 1:22 a.m., "Evan Nemerson"  escribió:

> I've gone ahead and launched a blog aggregator for Vala at
>  (thanks to Jürg for letting me use the
> subdomain), as discussed here a few days ago.
>
> Currently there are only a few blogs included, but I would really like
> to add more soon, especially (though not exclusively) of people who
> aren't already on planet.gnome.org.  The content doesn't have to be
> completely, or even mostly, about Vala.
>
> I've put the Venus configuration information on GitHub
> (), so please feel free to file
> issues or pull requests for whatever you would like to see.
>
>
> -Evan
>
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] [ANNOUNCE] Libgee 0.13.91 - GObject collection library

[Daniel Espinosa]

Still don't see any reference about this version is API/ABI compatible with
0.8. Is it?
El mar 3, 2014 1:20 p.m., "Maciej Piechotka" 
escribió:

> We are very pleased to announce version 0.13.91 of Libgee, the GObject
> collection library.
>
> Libgee 0.13.91 is now available for download at:
> http://download.gnome.org/sources/libgee/0.13/
>
>
> 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.13.91
> --
>   * Fix HazardPointer bugs
>   * Fix List test
>
> Libgee is a collection library providing GObject-based interfaces and
> classes for commonly used data structures.
>
> Libgee provides the following interfaces:
>
>  * Traversable
>o Iterable
>  + Collection
># List
>  * BidirList
># Set
>  * SortedSet
>  o BidirSortedSet
># MultiSet
># Queue
>  * Deque
>  + Map
># SortedMap
>  * BidirSortedMap
>o Iterator
>  + BidirIterator
># BidirListIterator
>  + ListIterator
># BidirListIterator
>  * MultiMap
>  * Future
>
> The ArrayList, ArrauQueue, ConcurrentLinkedList, ConcurrentSet,
> HashSet, HashMap, HashMultiSet, HashMultiMap, LinkedList,
> PriorityQueue, Promise, 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
>
> Maciej Marcin Piechotka
>
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Compiling under Windows

[Daniel Espinosa]

Please file a bug pointing this, where you can attach your scripts or even
better prepare a patch against Vala master repository.

If you need help to create the patch, file the bug, attach your scrips and
some one else could help you to create it. If I can, I'll do it for you
following your documentation (in Spanish or English).

For your wiki documentation, may you want to create an account on
live.gnome.org, where you write them on Spanish and then, some other (may
be me), can translate to English.
El ene 21, 2014 10:51 a.m., "Dev_NIX"  escribió:

> I was thinking about that. Compilation on Windows lacks of documentation,
> and there are problems (like compiling GLib on MSYS) more or less resolved,
> but it's almost impossible find how to do it. After several weeks
> investigating in my free time, I've found the problems and their solutions,
> and I'm a complete autotools n00b.
>
> Right now I'm recreating the proccess from scratch inside a clean  Windows
> 8.1 installation, and documenting it in blog format in Spanish, with the
> intention of translate it later to English. If, in the proccess, I write a
> bash/bat script to automate part of the work, I'll publish it too.
>
> If you find it useful and want to collaborate, you are free to write to me
> (in fact, I will love you with all my heart). I will post updates if I get
> a complete English guide. Cheers!
>
>
>
> 2014/1/21 Daniel Espinosa 
>
>> May is a good idea to add NSIS script directly in Vala repository. It
>> could be redistributed with Vala source code or have a way to automatically
>> create Windows installer with the new versions.
>> El ene 20, 2014 3:33 p.m., "Tarnyko"  escribió:
>>
>> Hi Dev_NIX,
>>> Dev_NIX writes:
>>>
>>>> To solve that on MSYS you have to install the msys-libtool package on
>>>> MinGW
>>>> Installation Manager. I've used Cygwin before.
>>>> I've been able to compile (after a good time investigating) GLib inside
>>>> MSYS, and after some tweakings, I've successfully compiled Vala 0.22.1
>>>> on
>>>> Windows.
>>>> Does anyone some experience or documentation to package it to an
>>>> installer
>>>> like vala 0.12 and what files and bins are needed on the directory
>>>> structure inside the installation?
>>>>
>>>
>>> The Vala 0.12 installer (which, I suppose, you found on code.google.com)
>>> is packaged using NSIS. I wrote a similar NSIS script which, I suppose, I
>>> could share somewhere on the Internet. The particularity is that the .vapi
>>> files are not located in "\share" but in "\ProgramData\vala-0.XX",
>>> which is done by tweaking the configure file.
>>> I used to package former versions of Vala, but have less free time to do
>>> so. I'd be happy to help you if you come to IRC, irc.gimp.org, #gtk+ or
>>> #vala channel.
>>>
>>>>
>>>> 2014/1/19 Maciej Piechotka 
>>>>
>>>>> On Sun, 2014-01-19 at 17:22 +0100, Dev_NIX wrote:
>>>>> > Hi all!
>>>>> >
>>>>> > I'm starting some Vala experiments on Windows, and I'm using the last
>>>>> > version compiled by Tarnyko (which is 0.20.1)
>>>>> >
>>>>> > Right now I'm trying to compile by myself the latest build (0.23.1)
>>>>> on
>>>>> > cygwin, but I get stucked running autogen.sh with the following
>>>>> message:
>>>>> >
>>>>> > Can't locate Autom4te/ChannelDefs.pm in @INC
>>>>> > (
>>>>> > @INC contains:
>>>>> > E:/PROGRA~1/GnuWin32/autoconf/share/autoconf
>>>>> >  /usr/lib/perl5/site_perl/5.14/x86_64-cygwin-threads
>>>>> > /usr/lib/perl5/site_perl/5.14
>>>>> > /usr/lib/perl5/vendor_perl/5.14/x86_64-cygwin-threads
>>>>> >  /usr/lib/perl5/vendor_perl/5.14
>>>>> > /usr/lib/perl5/5.14/x86_64-cygwin-threads
>>>>> > /usr/lib/perl5/5.14 .
>>>>> > )
>>>>> > at /cygdrive/e/Program Files (x86)/GnuWin32/bin/autoreconf line 42.
>>>>> > BEGIN failed--compilation aborted at /cygdrive/e/Program Files
>>>>> > (x86)/GnuWin32/bin/autoreconf line 42.
>>>>> >
>>>>> > Do you have any idea of what's going on, guys? D:
>>>>> A random guess - you have mixed cygwin perl (as dented by paths) and
>>>>> non-cygwin perl (e:\Program Files (x86)\GnuWin32) which breaks things
>>>>> (namely autoconf - part of Vala build system).
>>>>> Setting the perl paths straight should fix the problem (I have no idea
>>>>> what they are - I'd try perl IRC channel) to use cygwin perl.
>>>>> ___
>>>>> vala-list mailing list
>>>>> vala-list@gnome.org
>>>>> https://mail.gnome.org/mailman/listinfo/vala-list
>>>>>
>>>>>  ___
>>>> vala-list mailing list
>>>> vala-list@gnome.org
>>>> https://mail.gnome.org/mailman/listinfo/vala-list
>>>>
>>>
>>> Regards,
>>> Tarnyko
>>> ___
>>> vala-list mailing list
>>> vala-list@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/vala-list
>>>
>>
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Compiling under Windows

[Daniel Espinosa]

May is a good idea to add NSIS script directly in Vala repository. It could
be redistributed with Vala source code or have a way to automatically
create Windows installer with the new versions.
El ene 20, 2014 3:33 p.m., "Tarnyko"  escribió:

> Hi Dev_NIX,
> Dev_NIX writes:
>
>> To solve that on MSYS you have to install the msys-libtool package on
>> MinGW
>> Installation Manager. I've used Cygwin before.
>> I've been able to compile (after a good time investigating) GLib inside
>> MSYS, and after some tweakings, I've successfully compiled Vala 0.22.1 on
>> Windows.
>> Does anyone some experience or documentation to package it to an installer
>> like vala 0.12 and what files and bins are needed on the directory
>> structure inside the installation?
>>
>
> The Vala 0.12 installer (which, I suppose, you found on code.google.com)
> is packaged using NSIS. I wrote a similar NSIS script which, I suppose, I
> could share somewhere on the Internet. The particularity is that the .vapi
> files are not located in "\share" but in "\ProgramData\vala-0.XX",
> which is done by tweaking the configure file.
> I used to package former versions of Vala, but have less free time to do
> so. I'd be happy to help you if you come to IRC, irc.gimp.org, #gtk+ or
> #vala channel.
>
>>
>> 2014/1/19 Maciej Piechotka 
>>
>>> On Sun, 2014-01-19 at 17:22 +0100, Dev_NIX wrote:
>>> > Hi all!
>>> >
>>> > I'm starting some Vala experiments on Windows, and I'm using the last
>>> > version compiled by Tarnyko (which is 0.20.1)
>>> >
>>> > Right now I'm trying to compile by myself the latest build (0.23.1) on
>>> > cygwin, but I get stucked running autogen.sh with the following
>>> message:
>>> >
>>> > Can't locate Autom4te/ChannelDefs.pm in @INC
>>> > (
>>> > @INC contains:
>>> > E:/PROGRA~1/GnuWin32/autoconf/share/autoconf
>>> >  /usr/lib/perl5/site_perl/5.14/x86_64-cygwin-threads
>>> > /usr/lib/perl5/site_perl/5.14
>>> > /usr/lib/perl5/vendor_perl/5.14/x86_64-cygwin-threads
>>> >  /usr/lib/perl5/vendor_perl/5.14
>>> > /usr/lib/perl5/5.14/x86_64-cygwin-threads
>>> > /usr/lib/perl5/5.14 .
>>> > )
>>> > at /cygdrive/e/Program Files (x86)/GnuWin32/bin/autoreconf line 42.
>>> > BEGIN failed--compilation aborted at /cygdrive/e/Program Files
>>> > (x86)/GnuWin32/bin/autoreconf line 42.
>>> >
>>> > Do you have any idea of what's going on, guys? D:
>>> A random guess - you have mixed cygwin perl (as dented by paths) and
>>> non-cygwin perl (e:\Program Files (x86)\GnuWin32) which breaks things
>>> (namely autoconf - part of Vala build system).
>>> Setting the perl paths straight should fix the problem (I have no idea
>>> what they are - I'd try perl IRC channel) to use cygwin perl.
>>> ___
>>> vala-list mailing list
>>> vala-list@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/vala-list
>>>
>>>  ___
>> vala-list mailing list
>> vala-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/vala-list
>>
>
> Regards,
> Tarnyko
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] [ANNOUNCE] Libgee 0.13.4 - GObject collection library

[Daniel Espinosa]

I can see this version is incremental (point release like) over 0.8, and
packaged as 0.8.

Could you add that information in order to others know that 0.10, 0.12 and
upcomming 0.14 will be API/ABI compatible with 0.8 series?

As I can see you've take care about API and more importantly ABI, at C
level, stability on 0.8 to 0.12. Could you point that in your release
information?

I think this is very importantly in order to know Libgee stability and
avoid fear about depend on this library, contrary with other Vala libraries
like Personas, that may be don't know how to maintain API and ABI stability
across different Vala versions.

May is very important to add your recommendations on API/ABI stability on
Vala wiki, or link from Libgee wiki.

I'm trying to fix a bug on GXml/Serialization and want to use Libgee to
avoid most iteration/containers/collection bugs.

Many thanks.



2013/12/16 Maciej Piechotka 

>
> We are very pleased to announce version 0.13.0 of Libgee, the GObject
> collection library.
>
> Libgee 0.13.4 is now available for download at:
> http://download.gnome.org/sources/libgee/0.13/
>
>
> 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.13.4
> -
>   * The collection cloning no longer leaks memory
>   * Various warning fixes
>   * Various fixes to build system
>
> Libgee is a collection library providing GObject-based interfaces and
> classes for commonly used data structures.
>
> Libgee provides the following interfaces:
>
>  * Traversable
>o Iterable
>  + Collection
># List
>  * BidirList
># Set
>  * SortedSet
>  o BidirSortedSet
># MultiSet
># Queue
>  * Deque
>  + Map
># SortedMap
>  * BidirSortedMap
>o Iterator
>  + BidirIterator
># BidirListIterator
>  + ListIterator
># BidirListIterator
>  * MultiMap
>  * Future
>
> The ArrayList, ArrauQueue, ConcurrentLinkedList, ConcurrentSet,
> HashSet, HashMap, HashMultiSet, HashMultiMap, LinkedList,
> PriorityQueue, Promise, 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
>
> Maciej Marcin Piechotka
>
>
>
> ___
> libgee-list mailing list
> libgee-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/libgee-list
>



-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

[Vala] Fwd: vala libgda LINQ

[Daniel Espinosa]

Please CC to list.


-- Forwarded message --
From: Abderrahim Kitouni 
Date: 2013/12/4
Subject: Re: [Vala] vala libgda LINQ
To: Daniel Espinosa 



Daniel Espinosa  a écrit :
>2013/12/4 Luca Bruno 
>
>> LINQ is just some kind of syntax for some functional programming
>aspects.
>> It's about to be a 1:1 mapping with filter-map, also fold and scan..
>>
>> For example:
>> select field1,field2 from collection where field3==value
>> can be written as:
>> collection.filter((r) => r.field3==value).map((r) => {r.field1,
>r.field2});
>> Obviously, LINQ is not only that, but that's a good approximation.
>>
>>
>Vala has provide nice/sexy syntax for GObject/C programing. Have added
>lot
>of new features, witch have been possible to write in C but with lot of
>lines of code. I love Vala because allows me to be more productive,
>even
>Genie allows more simplification on Vala's syntax.
>
>I think that former syntax are more productive and easy to read than
>the
>last. Could allow to work with-in Vala's code with lot of data from a
>DataBase or any other data source. GdaData objects and interfaces
>allows to
>access that data using just GObjects and Vala code, abstracting most of
>internal operations and mapping to properties and methods, and allow to
>use
>Gee collections to make more easy to access to data using by code; but
>could reach a next level by adding some syntax support on Vala for SQL
>like
>queries.
>
>I know that adding syntax support may is not easy or is far from Vala
>principles.
>
>Then I would like to see a way to allows Vala compiler with a mechanism
>of
>PLUG-INS for syntax support. Then GdaData could add its own plug-in for
>SQL
>syntax when it is installed.
>
>The above allows not to distract Vala from its principles, but allows
>to
>others add syntax for specific task that makes more easy/productive and
>clear way to do the same.
>
>Less code and clear syntax, allows more productive less errors.
>
>
>> That said, implement filter, map and fold in your collections library
>and
>> you can avoid the LINQ syntax :-)
>> Consider libgee has filter, map, fold and scan with which you can
>> implement a large subset of LINQ, including aggregate operators.
>> ___
>> vala-list mailing list
>> vala-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/vala-list
>>
>
>
>
>--
>Trabajar, la mejor arma para tu superación
>"de grano en grano, se hace la arena" (R) (en trámite, pero para los
>cuates: LIBRE)
>___
>vala-list mailing list
>vala-list@gnome.org
>https://mail.gnome.org/mailman/listinfo/vala-list

Hi,

I think it might be a good idea to have something like Scala's for
comprehensions that would work for all collections (and maybe more).

I don't have an example right now though
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.



-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] vala libgda LINQ

[Daniel Espinosa]

2013/12/4 Luca Bruno 

> On 04/12/2013 16:52, Daniel Espinosa wrote:
>
>>
>> Vala has provide nice/sexy syntax for GObject/C programing. Have added
>> lot of new features, witch have been possible to write in C but with lot of
>> lines of code. I love Vala because allows me to be more productive, even
>> Genie allows more simplification on Vala's syntax.
>>
>> I think that former syntax are more productive and easy to read than the
>> last. Could allow to work with-in Vala's code with lot of data from a
>> DataBase or any other data source. GdaData objects and interfaces allows to
>> access that data using just GObjects and Vala code, abstracting most of
>> internal operations and mapping to properties and methods, and allow to use
>> Gee collections to make more easy to access to data using by code; but
>> could reach a next level by adding some syntax support on Vala for SQL like
>> queries.
>>
>> I know that adding syntax support may is not easy or is far from Vala
>> principles.
>>
>> Then I would like to see a way to allows Vala compiler with a mechanism
>> of PLUG-INS for syntax support. Then GdaData could add its own plug-in for
>> SQL syntax when it is installed.
>>
>> The above allows not to distract Vala from its principles, but allows to
>> others add syntax for specific task that makes more easy/productive and
>> clear way to do the same.
>>
>> Less code and clear syntax, allows more productive less errors.
>>
> Plugins are planned, but not for changing the syntax. Plugins will be able
> to transform the ast into other ast, but neither semantics nor syntax are
> allowed to change.
>
> Consider this alternative, doable with such plugins:
> select(Class.foo, Class.bar).from(collection).where(equal(some_field,
> "some value")).
>
>
This could be possible using GDA and GdaData infrastructure. Just require
to create some classes and interfaces. Of course this don't need a Vala
plug-in just install GDA and enable GdaData :-)


> Collection may be anything from an array to a gee collection to anything.
> The plugin in this case can generate the relevant code by doing the
> necessary magic, and it has all the information about the collection from
> the ast.
>
>
GdaData already do this. You have mapped tables, records, fields to Gee
collections and implements some interfaces to allow any other to be a data
provider not just databases that actually use GDA as back-end.


> However, such plugins will not be there anytime soon, there's first a huge
> experimental branch to be merged (yet to be completed).
>
>
After that merge, are there any plan for plug-in support and include syntax
support too? Are we need to go the Genie way?

If Genie way is recommended, then we need to fix missings in GdaData to
allow basic programically query execution and then think about to create
Vala/Genie syntax.

-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] vala libgda LINQ

[Daniel Espinosa]

ntensive applications. Some things could add
> flexibility to language itself.
>
> Other features of LINQ to  Entities:
>
> a) Lazy loading
>
> public class Person
> {
> string name { get; set; }
> Address address { get; set; }
> }
>
> // get a record from Person table
> Person friend =
> from f in db.Persons
> where f.Name = "Luca"
> select f;
>
> // Get a record from address table
> print(friend.address.street);
>
> b) Inheritance
>
> public class Customer : Person { ... }
>
>
>
> [1]
> http://stackoverflow.com/questions/7192040/linq-to-entities-vs-linq-to-objects-are-they-the-same
> [2]
> http://maanshah.wordpress.com/2012/03/02/linq-to-sql-vs-linq-to-objects-vs-linq-to-entities/
>
>
>
>> 2013/12/4 Daniel Espinosa 
>>
>>>
>>>
>>>
>>> 2013/12/3 Juarez Rudsatz 
>>>
>>>> I checked the samples and some parts of the code.
>>>> Nice work. :-)
>>>>
>>>> Regarding language support, it seems to remain a good amount of work to
>>>> be done yet.
>>>>
>>> Do you mean Vala features right?
>>>
>>>>  I'm counting the language features that will be necessary:
>>>> - Object serialization
>>>>
>>> Are you mean write some where. For XML serialization we have Vala's GXml
>>> project[1]. On GXml's serialization branch, you'll find my work on GObject
>>> serialization to XML, comparable with .NET but, I think more flexible[2].
>>>
>>>> - Anonymous types
>>>>
>>> - Expression and type introspection
>>>> - Type aliasing...
>>>> - Syntax changes
>>>>
>>>>
>>>> At the end a Collection have objects with a set of properties, a SELECT
>>> expression is a filter of that set of objects and a set of properties. They
>>> could be stored in a DbRecord (as for libgda's GdaData [3] ) to save memory
>>> and adding something like "Methods_With_Syntax_Support" [4] , Vala compiler
>>> could transform:
>>>
>>>  var selection = select name, salary from employees where id = "123";
>>>  stdout.printf (@"$(selection.name) / $(selection.salary)");
>>>
>>> to:
>>>var _tmp_ = new ArrayList ();
>>>_tmp_.add_all ( ((Traversable) employees).filter(
>>>   (g)=>{ return id.equals (g) true : false;
>>> });
>>>var selection = ((Selectable) _tmp_).get_fields ("name",
>>> "salary");
>>>if (selection.size != 1)
>>>   throw new SelectableError.MULTIPLE_VALUES_TO_SINGLE ("...");
>>>var _tmp2_ = selection[0].get_field("name");
>>>var _tmp3_ = selection[0].get_field("salary");
>>>stdout.printf (@"$(_tmp2_) / $(_tmp3_)");
>>>
>>>> What level of support you are planning?
>>>>
>>> Because I haven't used LINQ before, I don't know most of its features.
>>> Just think about to allow:
>>>
>>> a) Use a SQL like syntax to filter objects and properties, by adding
>>> support to Vala compiler to generate corresponding Vala or C code
>>> b) Object collection must implement at least Gee.Collection and its
>>> items must be Gee.Comparable and Selectable
>>> c) Add a Selectable interface to Gee to allow introspect objects
>>> properties and create a Collection with desired DbRecord set of values.
>>>
>>> I don't think mimic LINQ is correct. May we can do better, but is
>>> necessary to define use cases.
>>>
>>> The only one I have in mind is:
>>>
>>> a) select {list-of-fields} from {collection-object} where {condition}
>>>
>>> For this simple expression Vala's compiler should generate required code
>>> to:
>>>
>>> a) Check for collection-object is a GObject implementing Gee.Collection
>>> and its elements must be Gee.Comparable and Selectable
>>> b) Check for list-of-fields are public properties in collection-object
>>> c) Check for condition is using collection-object 's public properties
>>> d) Generate a Predicate delegate function to find object required
>>> objects
>>> e) Fill a Gee.Collection with filtered objects
>>> f) Generate a Gee.Collection from Selectable, that produce rows and
>>> values/columns (with name=properties' name)
>>>
>>&

Re: [Vala] vala libgda LINQ

[Daniel Espinosa]

2013/12/4 Luca Bruno 

> LINQ is just some kind of syntax for some functional programming aspects.
> It's about to be a 1:1 mapping with filter-map, also fold and scan..
>
> For example:
> select field1,field2 from collection where field3==value
> can be written as:
> collection.filter((r) => r.field3==value).map((r) => {r.field1, r.field2});
> Obviously, LINQ is not only that, but that's a good approximation.
>
>
Vala has provide nice/sexy syntax for GObject/C programing. Have added lot
of new features, witch have been possible to write in C but with lot of
lines of code. I love Vala because allows me to be more productive, even
Genie allows more simplification on Vala's syntax.

I think that former syntax are more productive and easy to read than the
last. Could allow to work with-in Vala's code with lot of data from a
DataBase or any other data source. GdaData objects and interfaces allows to
access that data using just GObjects and Vala code, abstracting most of
internal operations and mapping to properties and methods, and allow to use
Gee collections to make more easy to access to data using by code; but
could reach a next level by adding some syntax support on Vala for SQL like
queries.

I know that adding syntax support may is not easy or is far from Vala
principles.

Then I would like to see a way to allows Vala compiler with a mechanism of
PLUG-INS for syntax support. Then GdaData could add its own plug-in for SQL
syntax when it is installed.

The above allows not to distract Vala from its principles, but allows to
others add syntax for specific task that makes more easy/productive and
clear way to do the same.

Less code and clear syntax, allows more productive less errors.


> That said, implement filter, map and fold in your collections library and
> you can avoid the LINQ syntax :-)
> Consider libgee has filter, map, fold and scan with which you can
> implement a large subset of LINQ, including aggregate operators.
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>



-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] vala libgda LINQ

[Daniel Espinosa]

2013/12/3 Juarez Rudsatz 

> I checked the samples and some parts of the code.
> Nice work. :-)
>
> Regarding language support, it seems to remain a good amount of work to be
> done yet.
>
Do you mean Vala features right?

> I'm counting the language features that will be necessary:
> - Object serialization
>
Are you mean write some where. For XML serialization we have Vala's GXml
project[1]. On GXml's serialization branch, you'll find my work on GObject
serialization to XML, comparable with .NET but, I think more flexible[2].

> - Anonymous types
>
- Expression and type introspection
> - Type aliasing...
> - Syntax changes
>
>
> At the end a Collection have objects with a set of properties, a SELECT
expression is a filter of that set of objects and a set of properties. They
could be stored in a DbRecord (as for libgda's GdaData [3] ) to save memory
and adding something like "Methods_With_Syntax_Support" [4] , Vala compiler
could transform:

 var selection = select name, salary from employees where id = "123";
 stdout.printf (@"$(selection.name) / $(selection.salary)");

to:
   var _tmp_ = new ArrayList ();
   _tmp_.add_all ( ((Traversable) employees).filter(
  (g)=>{ return id.equals (g) true : false; });
   var selection = ((Selectable) _tmp_).get_fields ("name", "salary");
   if (selection.size != 1)
  throw new SelectableError.MULTIPLE_VALUES_TO_SINGLE ("...");
   var _tmp2_ = selection[0].get_field("name");
   var _tmp3_ = selection[0].get_field("salary");
   stdout.printf (@"$(_tmp2_) / $(_tmp3_)");

> What level of support you are planning?
>
Because I haven't used LINQ before, I don't know most of its features. Just
think about to allow:

a) Use a SQL like syntax to filter objects and properties, by adding
support to Vala compiler to generate corresponding Vala or C code
b) Object collection must implement at least Gee.Collection and its items
must be Gee.Comparable and Selectable
c) Add a Selectable interface to Gee to allow introspect objects properties
and create a Collection with desired DbRecord set of values.

I don't think mimic LINQ is correct. May we can do better, but is necessary
to define use cases.

The only one I have in mind is:

a) select {list-of-fields} from {collection-object} where {condition}

For this simple expression Vala's compiler should generate required code to:

a) Check for collection-object is a GObject implementing Gee.Collection and
its elements must be Gee.Comparable and Selectable
b) Check for list-of-fields are public properties in collection-object
c) Check for condition is using collection-object 's public properties
d) Generate a Predicate delegate function to find object required objects
e) Fill a Gee.Collection with filtered objects
f) Generate a Gee.Collection from Selectable, that produce rows and
values/columns (with name=properties' name)

> It would be well received by upstream developers?
>
Really don't know. I'm CC to Vala and Gee lists to hear them about this
idea.

> I'm planning a new architecture for ouro next applications and considering
> vala. But the type safety and language support are the strengths of linq we
> really appreciate.
>
> I'm planning to help someway, but I have a long way yet to be produtive.
>
> Regards
>
> Juarez
>
[1] https://git.gnome.org/browse/gxml
[2] https://git.gnome.org/browse/gxml/log/?h=serialization
[3] https://git.gnome.org/browse/libgda/tree/libgda/data
[4]
https://wiki.gnome.org/Projects/Vala/Tutorial#Methods_With_Syntax_Support



>  Em 03/12/2013 16:35, "Daniel Espinosa"  escreveu:
>
> You can see a preview of my work on current stable libgda.
>>
>> I've finished interfaces and implementations under GdaData name space.
>>
>> I've added some documentation just use --enable-vala-extensions --gtk-doc
>> (some other switches are required) to see it installed.
>>
>> Missed Selectable interface or implementation.
>>
>> I would like to add syntax support on Vala compiler in order to have LINQ
>> like one.
>>
>> For now is very easy to access to data using GdaData objects, see unit
>> tests for more examples.
>> El dic 3, 2013 10:03 a.m., "Juarez Rudsatz"  escribió:
>>
>>> Hi,
>>>
>>> I found that you have been working in a possible implementation of LINQ
>>> in vala [1].
>>> I see that you have made good progress regarding this support.
>>> I want to know what is the current status.
>>> What's missing yet? How is the work for getting basic support ?
>>>
>>> Regards
>>>
>>> Juarez
>>>
>>> [1]
>>> https://mail.gnome.org/archives/vala-list/2011-December/msg00140.html
>>>
>>


-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Default enum's values' nick

[Daniel Espinosa]

I've read that article, some time ago. Is very useful for some tasks; but I
need some thing more easy when you have lot of enums and want to serialize
them to XML.

I working in a serialization branch in GXml project and added some
convenient functions to get exactly the same result with a simple method
call.

Check the code at:

https://git.gnome.org/browse/gxml/commit/?h=serialization&id=6abcfbb98ed53ada56616181f92b820fff4b685d

These resolve most cases and they could be added to Vala enums by default
to extra functionality. Some one can point me how?

But as you can see in the patch, the automatic generation of EnumClass for
each enum to register it as a valid GLib.Type adds some extra field called
'value_nick', my tests shows up that by default nick is set to lower case
canonical string representation of a given enum's value, then for a:

enum Cat {
BIG_SIZE,
BIGGEST
}

BIG_SIZE's default nick, from EnumClass and its EnumValue, is 'big-size'
while for BIGGEST is 'biggest'.

A call to GXml.Enumeration. get_nick_camelcase() returns 'BigSize' and
'Biggest' respectively.

My problem is when I need some nicks like 'givenTime' for GIVEN_TIME or
'CASTtool' for CAST_TOOL enums values. For them using a simple:

[Description (nick="CASTtool")]
CAST_TOOL

Is better and allow any others to get great control over enums in Vala.
El nov 8, 2013 12:01 a.m., "Donn"  escribió:

> On 08/11/2013 02:43, Daniel Espinosa wrote:
>
>  Do you know how can I change default nick?
>>
>
> I'm not sure - haven't had a chance to try this yet - but have a look at
> this link:
> http://blog.yorba.org/jim/2011/05/a-few-of-my-favorite-
> vala-things-enums.html
>
> \d
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

[Vala] Default enum's values' nick

[Daniel Espinosa]

I found in Vala 0.20, that I can't use Description attributes to change an
enumeration member's default nick name.

Do you know how can I change default nick?

Could this be added to Vala?
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Port of the Porter stemmer to Vala

[Daniel Espinosa]

Could you provide some description about Porter stemmer or a Link to a
place to read about it?
El sep 17, 2013 3:48 a.m., "Serge Hulne"  escribió:

> Hi,
>
> Here is a port of the Poter stemmer to Vala
>
> Serge Hulne
>
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] MIT to LGPL from Mono source

[Daniel Espinosa]

I'm sorry I've sent message to FSF to get some feed back because could be
or not a license issue if you copy the code but adapt it to Vala
conventions, is it an original work or derived one?
El ago 15, 2013 3:16 p.m., "Simon Kågedal Reimer" 
escribió:
>
> Hi Daniel,
>
> I don't think this question of licensing belongs on vala-list since it
> really is unrelated to Vala, but briefly: no, we can't remove or
> change a license on someone else's copyrighted code unless explictly
> allowed in the license, which is not the case with MIT/X11, but it is
> compatible with (and less restrictive than) GPL/LGPL so such code can
> easily be included with an otherwise LGPL:ed library. I don't think
> this is an issue. Anyway, no code is written/ported yet :)

Your right. But any way just asking to FSF.

>
> While we have vala-list's attention, I'd be curious to hear if anyone
> knows of any succesful ports of C# to Vala. Are there maybe even some
> kind of tool out there that aids with boring, automatable tasks such
> as naming conventions..?
>

This question was asked before, and because no such tool exists jet, and
requires hand made changes, like to use GLib for most operations I think.
> Regards, Simon
>
> On Thu, Aug 15, 2013 at 7:04 PM, Daniel Espinosa  wrote:
> > This is a question to relicense re-written or ported code from Mono
Project
> > source in C# to Vala.
> >
> > Is it possible to copy that code port it to Vala and release it using
LGPL?
> >
> > Vala [1] is very similar to C#, but relays on GObject and translate to
C.
> >
> > El ago 15, 2013 6:18 a.m., "Simon Kågedal Reimer" 
> > escribió:
> >
> > On Tue, Aug 13, 2013 at 5:58 PM, Daniel Espinosa 
wrote:
> >>
> >> Don't worry all here are volunteers. I would like to see your work in a
> >> branch of GXml, it almost compile in master (if not please tell me and
can
> >> fix it for you).
> >
> > Ok, I hope to have a go at this during the weekend. It does make
> > sense, as you say, to do this earlier rather than later. There is only
> > really one overlapping type, the enum GXml.NodeType [1] vs.
> > Acme.XmlNodeType [2].
> >
> > A note on a comment in [1]:
> >
> >// TODO: want a method to convert NodeType to a string
> >
> > Vala provides this automatically! For example,
> > GXml.NodeType.ATTRIBUTE.to_string () will give "ATTRIBUTE". If one
> > wants a nicer representation, perhaps "Attribute" instead, one can
> > manually override to_string(); see this blog post: [3]
> >
> > I've also used this technique in Acme.XmlNodeType for a method that
> > checks if a node of type X can be a parent of a node of type Y, useful
> > for sanity assertions. I assume that the same rules apply in the DOM
> > as when reading?!
> >
> > I think that the values for this enum should be explicitly given, as
> > they have to correspond with the same values in libxml2. This also
> > makes the Vala bug mentioned in a comment in [1] not relevant.
> >
> > [3]
> >
http://blog.yorba.org/jim/2011/05/a-few-of-my-favorite-vala-things-enums.html
> >
> >>> I've also considered not using libxml2 for at least some parts. The
> >>> XmlWriter would not be too difficult to rewrite in Vala. This would
> >>> make things a little more manageable. I've also peeked in the Mono
> >>> sources, they have an implementation of this that one could try
> >>> porting from C# to Vala.
> >>>
> >>
> >> This is a great idea! Just we need to check license issues.
> >
> > The license shouldn't be a problem, the Mono classes are released
> > under the MIT license. What could conceivably be a problem is the
> > scare of Microsoft patents. The core XmlReader/XmlWriter stuff is part
> > of the ECMA-335 [4] standard, so that isn't a problem, but Mono also
> > implements additions from Microsofts .NET classes. I don't think this
> > is a problem either, but others might disagree.
> >
> >> Richard have the idea to rewrite libxml in Vala any way, may be most of
> >> your
> >> work will be reused by DOM.
> >>
> >> I think use Xml.TextReader behind is really good to parse XML
documents.
> >
> > Yes, I agree it makes sense to have Xml.TextReader as the core parsing
> > module. This is also what Mono/.NET does. libxml2 is kind of the other
> > way around, the TextReader built on top of SAX and DOM. For efficiency
> > it could be beneficial to reimplement/port TextReader as a straight

[Vala] MIT to LGPL from Mono source

[Daniel Espinosa]

This is a question to relicense re-written or ported code from Mono Project
source in C# to Vala.

Is it possible to copy that code port it to Vala and release it using LGPL?

Vala [1] is very similar to C#, but relays on GObject and translate to C.
El ago 15, 2013 6:18 a.m., "Simon Kågedal Reimer" 
escribió:

On Tue, Aug 13, 2013 at 5:58 PM, Daniel Espinosa  wrote:
>
> Don't worry all here are volunteers. I would like to see your work in a
> branch of GXml, it almost compile in master (if not please tell me and can
> fix it for you).

Ok, I hope to have a go at this during the weekend. It does make
sense, as you say, to do this earlier rather than later. There is only
really one overlapping type, the enum GXml.NodeType [1] vs.
Acme.XmlNodeType [2].

A note on a comment in [1]:

   // TODO: want a method to convert NodeType to a string

Vala provides this automatically! For example,
GXml.NodeType.ATTRIBUTE.to_string () will give "ATTRIBUTE". If one
wants a nicer representation, perhaps "Attribute" instead, one can
manually override to_string(); see this blog post: [3]

I've also used this technique in Acme.XmlNodeType for a method that
checks if a node of type X can be a parent of a node of type Y, useful
for sanity assertions. I assume that the same rules apply in the DOM
as when reading?!

I think that the values for this enum should be explicitly given, as
they have to correspond with the same values in libxml2. This also
makes the Vala bug mentioned in a comment in [1] not relevant.

[3]
http://blog.yorba.org/jim/2011/05/a-few-of-my-favorite-vala-things-enums.html

>> I've also considered not using libxml2 for at least some parts. The
>> XmlWriter would not be too difficult to rewrite in Vala. This would
>> make things a little more manageable. I've also peeked in the Mono
>> sources, they have an implementation of this that one could try
>> porting from C# to Vala.
>>
>
> This is a great idea! Just we need to check license issues.

The license shouldn't be a problem, the Mono classes are released
under the MIT license. What could conceivably be a problem is the
scare of Microsoft patents. The core XmlReader/XmlWriter stuff is part
of the ECMA-335 [4] standard, so that isn't a problem, but Mono also
implements additions from Microsofts .NET classes. I don't think this
is a problem either, but others might disagree.

> Richard have the idea to rewrite libxml in Vala any way, may be most of
your
> work will be reused by DOM.
>
> I think use Xml.TextReader behind is really good to parse XML documents.

Yes, I agree it makes sense to have Xml.TextReader as the core parsing
module. This is also what Mono/.NET does. libxml2 is kind of the other
way around, the TextReader built on top of SAX and DOM. For efficiency
it could be beneficial to reimplement/port TextReader as a straight
forward-only non-caching pull parser. However, it would be unwise to
prematurely throw out libxml2 since it provides lots of useful
features, DTD validation, XML Schema validation, RELAX-NG
validation etc. There's an impressive effort behind it, even if
the API and documentation is a bit messy.

One idea would be to have XmlReader as a proxy class that uses
different implementation classes under the hood. If no validation or
other other features are requested, we could use our own parser. If
needed, we use libxml2 (but hide it's complexity, i.e. we don't let
the user specify all kinds of parser options that libxml2 exposes).
(We wouldn't use our own parser unless/until it provably has benefits,
such as performance or features that might be hard to implement using
libxml2 such as an async TextReader.) But this is just thoughts on
possible directions in the future.

Of great importance here is of course conformance testing. I've begun
work on testing Acme.XmlReader/XmlWriter with W3C's XML Test Suite
[5].

> Just Richard have created. These are the firsts messages.
>
> And need to suscribe I think.

Ah, I had subscribed, just missed the "confirmation needed" mail. :)
Now I'm properly subscribed.

Regards, Simon

[1] https://git.gnome.org/browse/gxml/tree/gxml/NodeType.vala
[2]
https://gitorious.org/fido/acme-xml/blobs/master/acme-xml/acme-xmlnodetype.vala
[3]
http://blog.yorba.org/jim/2011/05/a-few-of-my-favorite-vala-things-enums.html
[4] http://www.ecma-international.org/publications/standards/Ecma-335.htm
[5] http://www.w3.org/XML/Test/
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Announce: Acme.Xml 0.1.0, wrapper for libxml2's xmlTextReader/xmlTextWriter API

[Daniel Espinosa]

I think this is a great opportunity to work together, I mean GXml and Acme.

First all I think this work should use same namespace than GXml.

Second I would like to use your work on Serialization, my actual work on
that is located in serialization branch at GXml repository, but use DOM and
I started to think that is better to use xmlTextReader and Writer for
better performane on large documents.

I need to know if I can share my work to you to test the concept.
Hello,

I started working on a wrapper for libxml's xmlTextReader and
xmlTextWriter API:s for simple "pull"-style reading and writing of
XML. Benifits against using libxml directly include, if/when things
are working correctly:

 - Memory-managed GObject based classes
 - Reading and writing with GIO streams
 - Error reporting through GError
 - Slightly more similar to the ECMA .NET API;s on which this is based
 - Readable documentation

Regarding the last point - I've copied some documentation from the
DotGNU project, which I think comes directly from the ECMA spec. As
far as I can understand it is freely usable. A big TODO point remains
in checking that the behavior and the doc actually correspond...

Anyway, I just wanted to get this out since I would love to hear some
thoughts on the API and also the implementation, if anyone is
interested. I'm aware there is another project that wraps libxml in
Vala/GObject, GXml - that works at the DOM level so they are really
differrent things for different use cases, I think (although it would
be great if they worked well together).

Links for downloading, documentation and git repository here:

   http://helgo.net/simon/projects/acme-xml/

Regards,
Simon Kågedal Reimer
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] [OT] Software for community alarms.

[Daniel Espinosa]

May you want to test LIBGDA's Vala bindins and its Vala Extensions. I've
contributed to, in order to bring Django equivalent to Vala, using LIBGDA
and bring it to other languages using GObject Introspection.
El jun 13, 2013 10:25 p.m., "Edwin De La Cruz" 
escribió:

> Best regards to all.
> I am developing a software for community alarms with sms notifications,
> fully automatic, PostgreSQL database, web GUI using a micro HTTP server
> (which I have also developed), HTML, Dojo, Ajax, OpenStreetMap and Vala
> programming language.
>
> Years ago I had conceived the idea but written in C # and running on
> Windows, but abandoned the project.
> Now that I am a follower of Vala since I met him I have returned to
> recreate the project from 0 to the characteristics I mentioned earlier.
>
> I would like to share the project and give me their opinion or point of
> view is very important to me your opinion as professionals and users.
>
> Software testing I have done on Debian 7 without any problem.
>
> Opensource software, it can download and install on the following page:
> http://usaga-software.**edwinspire.com/
>
> or
>
> https://github.com/edwinspire/**usaga
>
> A preliminary video software
> http://youtu.be/dB5ulneLIvQ
>
> All opinions are welcome.
>
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

[Vala] GLib.Rex Pattern

[Daniel Espinosa]

I want to set a static string to a class with a GRex pattern.

Is this supported by Vala?

I'm using:

class Ip : Object  {
public static string PATTERN="(([0-2]?[0-5]{1,2})|([0-1]\d\d)|(\d
\d))\.(([0-2]?[0-5]{1,2})|([0-1]\d\d)|(\d
\d))\.[0-2]?[0-5]{1,2}\.(([0-2]?[0-5]{1,2})|([0-1]\d\d)|(\d\d))"
}

On compile I get error for invalid scape sequence.
-- 
Daniel Espinosa 

___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] LDAP-Access with vala

[Daniel Espinosa]

There are Vala bindings for GDA, autogenerated at build time you can use.

GDA is a C library with support to GObject Introspection that allows to use
it directly from Python, javaScript and Vala.

You can use GDA's LDAP provider to get connection to it, construct queries
and access its records. Check at samples/LdapBrowser directory for a C
example, you can translate very easy to Vala; if you need some help on it
or find any bug in Vala bindings please send an e-mail to
gnome-db-l...@gnome.org or file a bug at
https://bugzilla.gnome.org/enter_bug.cgi?product=libgda


2013/3/21 Evan Nemerson 

> On Thu, 2013-03-21 at 20:26 +0100, Richard Wiedenhöft wrote:
> > Hi,
> >
> > I searched valadoc and google and I found absolutely nothing usable.
> >
> > How can one bind to an LDAP-Server with Vala and read the entries.
>
> Unfortunately I don't think anyone has created bindings for an LDAP
> library yet.  If you understand C it should be possible to do
> so--OpenLDAP does have a C API
> (http://www.openldap.org/software/man.cgi?query=ldap).
>
> If you decide to create a binding and need some help stop by #vala on
> irc.gnome.org.
>
>
> -Evan
>
>
>
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>



-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] What is "traversable" and how to use it !!! [since libgee 0.7]

[Daniel Espinosa]

Travesable is an interfase and a requisite for Iterable interface witch you
must implement.

Is not the best but you can open the files at Gee's source code to know the
methods to implement. Gee 0.8 adds lot of default implementations and have
abstract classes to make more easy to implement new collections as for
LIBGDA's vala extensions.

I'm implementing a new GLib.List class as a Gee collection, hope it will be
approbed into Gee classes.
El sep 27, 2012 3:24 a.m.,  escribió:

> Hello,
>
> I've compiled Libgee 0.8 (as usual with MingW under Windows ;)) and now
> when I try to compile my project, I've got an error... =___= (greeeaat)
>
> >objects.vala:257.1-257.55: error: cObjectsMap: some prerequisites
> (`Gee.Traversable') are not met
> >public class cObject : Object, Iterable {
> >^^^
>
> Do you have a sample of code for this ? Because, due of lack of
> documentation, I didn't understand exactly why now I need to use
> "traversable".
>
> Thanks :)
>
> Raum
>
> ps: to compile libgee, If you followed my previous messages
> export GLIB_CFLAGS='-I /mingw/lib/glib-2.0/include -I
> /mingw/include/glib-2.0 -I /mingw/include/glib-2.0/gobject '
> export GLIB_LIBS='-lglib-2.0 -llibgobject-2.0'
>
>
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

[Vala] Bug 679876 - GObject Introspection has no support for Vala's classes and interfaces

[Daniel Espinosa]

Could any one check this bug?

I think this is a problems in GLib/GObjectIntrospection, but maybe a
problem in C code generated by Vala.

-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

[Vala] How to add Vala generics to PyGObject

[Daniel Espinosa]

I have filed a bug #677960 with the following description:

PyGObject support GLib.List and GLib.Hash, but what about Vala/Gee
generics?

How can I create a GLib.List in Python and how can I do the same
for Vala/Gee generics?

May be defining a C API that defines functions that can handle generics and
Python could define the type to use.

Gee's GIR defines lot of interfaces and most of them are Generics.
Particulary when I use:

>> from gi.repository import Gee

works correctly but when try to use the interfaces or just to check it
exists as type I wrote:

>> Gee.List

I get the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/gi/module.py", line 243, in
__getattr__
return getattr(self._introspection_module, name)
  File "/usr/lib/python2.7/dist-packages/gi/module.py", line 180, in
__getattr__
wrapper = metaclass(name, bases, dict_)
  File "/usr/lib/python2.7/dist-packages/gi/types.py", line 232, in __init__
register_interface_info(cls.__info__.get_g_type())
TypeError: must be an interface


By inspecting Gee's tree I found that most classes implement and interfaces
have as prerequisite Gee.Traversable, but it is not defined:

>> Gee.Traversable

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/gi/module.py", line 243, in
__getattr__
return getattr(self._introspection_module, name)
  File "/usr/lib/python2.7/dist-packages/gi/module.py", line 105, in
__getattr__
self.__name__, name))
AttributeError: 'gi.repository.Gee' object has no attribute 'Traversable'



-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] [Bug 677389] New: Can't use Gee in python

[Daniel Espinosa]

This is not just a problem focused on Gee/Python, is that I was using Gee
in GDA to create an extension to access Data base objects and I would like
to use the GObjects classes on Python to use GDA on the web. Then if I
can't use Gee directly on Python then I can't use my GDA's extensions with
Python too.

If Gee can't be used with GObject Introspection, no libraries can be
created to develop other software depending on Gee.

May be some one else in gtk-list or gtk-app-devel-list can help to find how
to use Vala's generics or construct generics classes on
GObject-Introspection, at the end Gee C definitions have constructors
defining the object type to use and some functions to create/free them.


2012/6/4 Maciej Marcin Piechotka 

> Hi,
>
> Unfortunately due to GNOME DB problems the bug was lost. I will try to
> reply here.
>
> On Sun, 2012-06-03 at 13:00 +, libgee wrote:
> > I'm trying to use python to use Gee. Gee is primary a Vala library to
> > be used on software written in Vala, but it defines GIR files, then it
> > must be usable in any language supporting GObject Introspection.
> >
>
> Unfortunatly no. Libgee uses Vala generics which are not supported by
> GIR. This will cause problem when marshalling/demarshalling python
> objects.
>
> > When try to define a new object in Python, like Gee.ArrayList, I can't
> > because the following error:
> >
> > Traceback (most recent call last):
> >   File "", line 1, in 
> >   File "/usr/lib/python2.7/dist-packages/gi/module.py", line 243, in
> > __getattr__
> > return getattr(self._introspection_module, name)
> >   File "/usr/lib/python2.7/dist-packages/gi/module.py", line 180, in
> > __getattr__
> > wrapper = metaclass(name, bases, dict_)
> >   File "/usr/lib/python2.7/dist-packages/gi/types.py", line 232, in
> > __init__
> > register_interface_info(cls.__info__.get_g_type())
> > TypeError: must be an interface
> >
> > By reading the code I found that most Gee's Interfaces are not defined
> > GObject as pre-requisite, then I've added, then found that some other
> > doesn't put interfaces definition inside a namespace clause. That
> > doesn't make Vala compiler to rise errors and GIR are correct, but
> > they must be correctly defined. I'll attach a patch to get your review
> > and aprobation.
> >
>
> I believe that would be a Vala error while generating GIR as the
> pre-requisite exists (indirectly). I don't think it is possible to write
> Vala interface without this.
>
> I am not sure what you mean by "GIR are correct, but they must be
> correctly defined"
>
> > But at the end found that Gee.Traversable is not defined in GIR
> > repository. I'm trying to find it by:
> >
> > >>> Gee.Traversable
> >
> > I spect to get a pointer to an object defined in gir.repository.Gee,
> but the following error was rised:
> > Traceback (most recent call last):
> >  File "", line 1, in 
> >  File "/usr/lib/python2.7/dist-packages/gi/module.py", line 243, in
> > __getattr__
> >return getattr(self._introspection_module, name)
> >  File "/usr/lib/python2.7/dist-packages/gi/module.py", line 105, in
> > __getattr__
> >self.__name__, name))
> > AttributeError: 'gi.repository.Gee' object has no attribute
> 'Traversable'
> >
> > I'm reading the Gee.Traversable and GIR definition in order to find
> the problem.
>
> Thanks for looking into this. I am not sure how much time you have - it
> would be great if vala and gir played nicely but it would require work
> on both sides.
>
> Best regards,
> Maciej
>



-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Is there any way to deserialize something into object in vala?

[Daniel Espinosa]

I don't know about json-glib, but GDA uses a GObject/GLib C API to wrap C
API from its providers, provides prepared SQL commands to be executed
directly by the providers, and so on. Look at http://www.gnome-db.org/

Vala extensions are written in pure Vala. It just use GDA Vala bindings to
get access to the Database and run queries to save/load fields, this is at
least for GdaData.Record class. Record class is a pure Vala implementation
that use Gee classes, it internally uses Gda.SqlBuilder to run queries on
load or save data; they are run when you call update() or save() methods,
but you can dinamically set fields' value using set_field(), no access to
database are performer jet. An example for GdaData.Record is:

http://git.gnome.org/browse/libgda/tree/samples/vala/SampleDataObject.vala?id=b71b62ab68ddec29637f59dc05ae270ed10efee5

May be the only object you will get a penalty in performance (what are your
requirements? Real Time?) will be GdaData.Table class, but just for
update(), because it uses GDA's metadata updates to know fields, types,
keys, foreign keys and referenced tables, but this is just for the first
time, you will be able to use Gee classes to get access to metadata
directly. With GdaData.Table you can create tables without run "CREATE"
statements, just set the fields you need, keys, foreign keys and other
data, and run save() to actually run a query into the database. I'm writing
an example for Table class, but in the middle you can check Unit Tests at:

http://git.gnome.org/browse/libgda/tree/tests/vala/CheckTable.vala?id=b71b62ab68ddec29637f59dc05ae270ed10efee5



2012/3/22 mar...@saepia.net 

> Hi Daniel,
>
> thank you for your suggestion. I was considering GDA but as
> performance is quite important in my project, I wanted to recreate
> minimal subset of functionality of database abstraction layer by
> myself and do that in Vala.
>
> GDA is written in C, so it propably uses the same macros that
> json-glib does. But I still wonder if it is possible to do that in
> pure Vala?
>
> m.
>
> 2012/3/22 Daniel Espinosa :
> > May you want to test GDA's Vala extensions.
> >
> > They provides a Record object that could be used as a base class for your
> > objects and save all your properties directly to a database. Check out
> > samples/vala code.
> >
> > Vala extensions are available from git.gnome.org/libgda
> >
> > El mar 20, 2012 7:04 a.m., "mar...@saepia.net" 
> escribió:
> >>
> >> Hi,
> >>
> >> I need to create a sort of abstraction layer between the database and
> >> my vala app.
> >>
> >> It would be great if it was possible to interate over my class
> >> properties, read they type etc. and dynamically map fields from the DB
> >> to the properties.
> >>
> >> Is there any way to do that?
> >>
> >> I know that it is possible within GObject, as json-glib has that
> >> functionality, but is it possible without access to low-level C
> >> GLib/GObject macros? Only in Vala?
> >>
> >> m.
> >> ___
> >> vala-list mailing list
> >> vala-list@gnome.org
> >> http://mail.gnome.org/mailman/listinfo/vala-list
>



-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Is there any way to deserialize something into object in vala?

[Daniel Espinosa]

May you want to test GDA's Vala extensions.

They provides a Record object that could be used as a base class for your
objects and save all your properties directly to a database. Check out
samples/vala code.

Vala extensions are available from git.gnome.org/libgda
El mar 20, 2012 7:04 a.m., "mar...@saepia.net"  escribió:

> Hi,
>
> I need to create a sort of abstraction layer between the database and
> my vala app.
>
> It would be great if it was possible to interate over my class
> properties, read they type etc. and dynamically map fields from the DB
> to the properties.
>
> Is there any way to do that?
>
> I know that it is possible within GObject, as json-glib has that
> functionality, but is it possible without access to low-level C
> GLib/GObject macros? Only in Vala?
>
> 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] Escape string for use in sqlite

[Daniel Espinosa]

You can keep your code in Python, because GDA supports GObject
Introspection and PyGObject. Vala bindings in GDA are build based on
GObject Introspection.

2012/3/12 Rodrigo Herefeld 

> I started testing libgda, but the apps  simple does not compile on my
> debian( the funny thing is that i
> was able to do that on windows), i would need to compile libgda and then
> vala for that to work, and
> the program is too small for that, in fact i had it already done in
> python, but since i needed to run it
> on a machine where i may not install python i decided to port it to vala.
>
>
> 2012/3/12 Daniel Espinosa 
>
>> Use GDA. Look at:
>>
>> http://live.gnome.org/ChooseLibgdaSQLite
>>
>>
>> 2012/3/9 Shawn Ferris 
>>
>> > On Tue, Mar 6, 2012 at 12:33 PM, Luca Bruno 
>> wrote:
>> > > On Tue, Mar 6, 2012 at 8:30 PM, Rodrigo Herefeld <
>> > rodrigo.heref...@gmail.com
>> > >> wrote:
>> > >
>> > > When you bind a string parameter it will be escaped.
>> >
>> > I would add that database engines are usually better at optimizing SQL
>> > with bind variables, as well, binds help prevent SQL Injection
>> > attacks. The latter is the best reason of all, to use them, the other
>> > two you get for free. :D
>> >
>> > Shawn
>> > ___
>> > vala-list mailing list
>> > vala-list@gnome.org
>> > http://mail.gnome.org/mailman/listinfo/vala-list
>> >
>>
>>
>>
>> --
>> Trabajar, la mejor arma para tu superación
>> "de grano en grano, se hace la arena" (R) (en trámite, pero para los
>> cuates: LIBRE)
>>
>> ___
>> vala-list mailing list
>> vala-list@gnome.org
>> http://mail.gnome.org/mailman/listinfo/vala-list
>>
>>
>
>
> --
> Rodrigo Cesar Herefeld
>



-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Escape string for use in sqlite

[Daniel Espinosa]

Use GDA. Look at:

http://live.gnome.org/ChooseLibgdaSQLite


2012/3/9 Shawn Ferris 

> On Tue, Mar 6, 2012 at 12:33 PM, Luca Bruno  wrote:
> > On Tue, Mar 6, 2012 at 8:30 PM, Rodrigo Herefeld <
> rodrigo.heref...@gmail.com
> >> wrote:
> >
> > When you bind a string parameter it will be escaped.
>
> I would add that database engines are usually better at optimizing SQL
> with bind variables, as well, binds help prevent SQL Injection
> attacks. The latter is the best reason of all, to use them, the other
> two you get for free. :D
>
> Shawn
> ___
> vala-list mailing list
> vala-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/vala-list
>



-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] [gnome-db] GDA as Gee.Collection Reched Milestone 1

[Daniel Espinosa]

I've filed bug #668205 to track advances on documentation about GIR
generation.

2012/1/17 Vivien Malerba 

>
>
> On 13 January 2012 17:53, Daniel Espinosa  wrote:
>
>>
>>
>> 2012/1/13 Vivien Malerba 
>>
>>>
>>>
>>> On 13 January 2012 00:51, Daniel Espinosa  wrote:
>>>
>>>>
>>>>
>>>> Here is what I propose to you:
>>>>>
>>>>>- remove the generated files from git
>>>>>
>>>>>
>>>>>- add to git the "reference" of these files along with a test
>>>>>script (sh, python, perl, ...) which can then compare (or other) the
>>>>>generated files with the expected "reference" files to enable you to 
>>>>> detect
>>>>>any problem.
>>>>>
>>>>> The advantage of having a script to detect problems is that it can be
>>>>> documented (in its header for example) and run by anybody who thinks there
>>>>> is a problem.
>>>>>
>>>>>
>>>> for example copy Gda-5.0.gir to libgda/gir ? And then a script to check
>>>> diffs?
>>>
>>>
>>> Yes, for example create a libgda/girtest to store the expected GIR file
>>> (managed using git), let the build mechanism create the GIR file in
>>> libgda/, and then have a script in libgda/girtest (also managed by git)
>>> which compares (or does other tests) the two GIR files after compilation
>>> (maybe executed when "make check" is run).
>>>
>>>
>> This could be Ok if you always know the file format and what contents
>> might be in. GIR format is undocumented and in GDA depends on API additions
>> or minor improvements.
>>
>> One of the "aditional goals" of GObject Introspectio is API verification,
>> I would like to try on GDA and get a first hit. I filed bug 667837 to
>> notify API break in GDA-5.0.gir generated by GI master, the problem comes
>> when check Vala extensions and fails to find a function on Gda.DataProxy.
>>
>> As explained on GI website, we could hold GIR versions for each release,
>> not each time we compile, because the resulting GIR could include API
>> breaks that must be fixed before release. To deal with bug 667837, I can
>> make use on Vala of custom code or metadata, but on Python or JavaScript,
>> witch depends directly on GIR, I can't do that.
>>
>> Another is to autogenerate GIR files but not install them. Instead we can
>> send a patch to Vala or fix our code to make sure we will get not API break
>> but API additions and improvements. When a new release is ready, we can
>> check for API breaks by manually or include Unit Tests cases for the whole
>> API in Python.
>
>
> Ok, I see it's a bit more complicated than I had anticipated. Then I'll
> let you do what you think is the best.
>
> However please add some doc (even as a README.GIR file for example) to
> tell how and when GIR files are generated, checked, updated, validated,
> whatever, so that other developers can understand what's going on.
>
> Thanks,
>
> Vivien
>
>


-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] [gnome-db] GDA as Gee.Collection Reched Milestone 1

[Daniel Espinosa]

2012/1/13 Vivien Malerba 

>
>
> On 13 January 2012 00:51, Daniel Espinosa  wrote:
>
>>
>>
>> Here is what I propose to you:
>>>
>>>- remove the generated files from git
>>>
>>>
>>>- add to git the "reference" of these files along with a test script
>>>(sh, python, perl, ...) which can then compare (or other) the generated
>>>files with the expected "reference" files to enable you to detect any
>>>problem.
>>>
>>> The advantage of having a script to detect problems is that it can be
>>> documented (in its header for example) and run by anybody who thinks there
>>> is a problem.
>>>
>>>
>> for example copy Gda-5.0.gir to libgda/gir ? And then a script to check
>> diffs?
>
>
> Yes, for example create a libgda/girtest to store the expected GIR file
> (managed using git), let the build mechanism create the GIR file in
> libgda/, and then have a script in libgda/girtest (also managed by git)
> which compares (or does other tests) the two GIR files after compilation
> (maybe executed when "make check" is run).
>
>
This could be Ok if you always know the file format and what contents might
be in. GIR format is undocumented and in GDA depends on API additions or
minor improvements.

One of the "aditional goals" of GObject Introspectio is API verification, I
would like to try on GDA and get a first hit. I filed bug 667837 to notify
API break in GDA-5.0.gir generated by GI master, the problem comes when
check Vala extensions and fails to find a function on Gda.DataProxy.

As explained on GI website, we could hold GIR versions for each release,
not each time we compile, because the resulting GIR could include API
breaks that must be fixed before release. To deal with bug 667837, I can
make use on Vala of custom code or metadata, but on Python or JavaScript,
witch depends directly on GIR, I can't do that.

Another is to autogenerate GIR files but not install them. Instead we can
send a patch to Vala or fix our code to make sure we will get not API break
but API additions and improvements. When a new release is ready, we can
check for API breaks by manually or include Unit Tests cases for the whole
API in Python.

-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vapi automatic installation

[Daniel Espinosa]

I think that all projects must distribute its own VAPI files and
install in system's directories defined by vala. This is done by
libgda and gxml projects, including its GObject Introspection files,
created at build time and installed automatically. Distribution
packagers can create different packages for GI and VAPI.

Libgda master have added resently GIR and VAPI files in order to track
API updates and unwanted changes.

2012/1/6 Antono Vasiljev :
> On Tue, 2012-01-03 at 16:16 +0200, Denis Kuzmenok wrote:
>
>> What do you think about making vapi repository like perl's cpan to
>> search over different vapi's, and install them easily via commandline
>> utils?  With storage containing them, of course.
>
> vapi is not usable without headers and libs. and if this tool will
> install headers and libs we are reinventing package manager :)
>
> ___
> vala-list mailing list
> vala-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/vala-list



-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] OFF - choose a database.

[Daniel Espinosa]

I think you can use libgda. You can open connections to two databases
(local and network if you want) at the same time, then you can choose
if you save information at the same to two tables located in different
places. It has good Vala support, autogenerated from source code and
adding new features using Vala too!



2011/12/27 Kris Thomsen :
> I dont have experience in use databases in Vala, but I really like to use
> PostgreSQL and SQLite from other languages. They work nice and are quite
> easy to use.
>
> As replacement for MySQL is MariaDB (read about it on their webpage).
>
> // Kris
>
> 2011/12/27 Reid Thompson 
>
>> On 12/27/2011 10:50 AM, Brian Duffy wrote:
>>
>>> Does it require much concurrent db access while accessing over the
>>> network?
>>> I like sqlite for local db storage. It could be a good choice on the
>>> server
>>> as well if you are not planning on servicing multiple concurrent
>>> connections. Probably, I would use sqlite locally and mysql or postgresql
>>> on the server.
>>>
>>>
>>>  +1 postgresql
>>
>> __**_
>> 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
>



-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] DataBase as a Gee Collection of Collections

[Daniel Espinosa]

No really.

I'll use real database engines through GDA.

I'm seeing Gee just for its interfaces. I plan to implement them with
minimal info in memory, just results of queries.

GDA have an experimental implementation of Gee Collection for GdaDataModel
and some interfaces to model a database in Gee Collections, but using
GdaMetaData to retrieve info from any Gda supported database.

Also hope to model queries in a way that in feature Vala could gain LinQ
like suport.
El dic 23, 2011 3:31 a.m., "Serge Hulne"  escribió:

> I assume that you are considering developing a database system in RAM
> (since you mentioned Gee).
>
> Also I am assuming that you are considering a relational model (with tables
> and relationship between tables, etc..., possibly with SQL).
>
> 1. Here is an example of an implementation  in Java.
> http://hsqldb.org/
>
> 2. Here is an  example of an implementation in Python.
> http://gadfly.sourceforge.net/
>
> 3. Alternatively NoSQL databases (also worth considering):
> http://en.wikipedia.org/wiki/NoSQL
>
> 4. Since Gee already has Maps, which are not unlike "tables in RAM" (whose
> keys are accessed via a hash function) and since Vala has got generics (in
> the shape of templates), it is very easy to create a non persistent
> database in RAM as:
>
> - a HashMap
> - a MultiMap
> - a "map" of "maps" (a map having maps as keys, again: generics make this
> very easy) with the help of which complex relationships can be expressed
> between "tables" in RAM, without the overhead and runtime penalty of SQL.
>
> So the question of whether it is worth developing an additional  layer of
> abstraction on top of Gee is actually a good question.
> Food for thoughts !
>
> Perhaps the most important question to consider would be:
>
> - What would be the aim of this construct on top of Gee:
>
> 1. expressing relationships between tables (implementing a relational
> model) ?
> 2. Building an in-RAM easy-to-use DBMS.
> 3. With of without SQL ?
> 4. Store Classes (objects)  : Like ORM models : Object-to-relational
> databases.
> 5. is ease-of-use the foremost priority ?
> 6. is speed the top priority ?
> 7. Is minimal (optimal) use of RAM one of the priorities ?
>
> More concretely : What use do you have in mind for it, in practice ?
>
> Serge.
>
> ___
> 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] [gnome-db] DataBase as a Gee Collection of Collections

[Daniel Espinosa]

2011/12/23 Vivien Malerba :
>
>
> On 22 December 2011 22:01, Daniel Espinosa  wrote:
>>
>> I'm planning to create an implementation of interfaces to access a
>> database with classes and interfaces from Gee.
>>
>> This thread is planned to collect comments, suggestions and track
>> implementations. May be I can add a link on live.gnome.org when I have
>> something functional and solid plans.
>>
>> First Concepts:
>>
>> * A database is a collection of schemas and other objects
>> * Each schema have a collection of tables, views and other objects
>> that have Rows
>> * A Row is a collection of values with different types and with
>> attributes like: PRIMARY KEY, NAME, TYPE, VALUE, REFERENCEDBY,
>> REFERENCE
>> * REFERENCEBY and REFERENCE attributes can be used to get a collection
>> of related values from other table collection
>>
>>
>> First implementation ideas:
>>
>> * Define Interfaces and implementator classes , like Gee does, to
>> allow any one to access any kind of data. For now current GDA's
>> infrastructure will be used.
>
>
> Libgda reports all this information in a GdaMetaStruct object.
>
> Regards,
>
> Vivien

I've commited first interfaces as general concept. They uses Vala
Generics in order to help any other to implement them whitout a fixed
implementation. Added interfaces[1] include DbCollection (Database
abstraction as a collection of collections), DbSchema, DbTable,
DbRecord and DbField.

Derived class will use GdaMetaStruct on demand to retrieve database
information and expose as expected by the interfaces.

May be I'll propose a new Gee interface called Selectable, where
implementors must define a 'select (SqlWhere)' method with SqlWhere as
a tree of SqlExpressions to define simple to complex conditions. These
could be the first steps to add LinQ support to Vala.

On GDA implementations I plan to use GdaSqlBuilder and SqlStatements
to implement Selectable interface and include as a pre-
requisite for DbTable interface.

[1] 
http://git.gnome.org/browse/libgda/commit/?id=04317b0316398dbe29ad24043219efe735ff1af7

-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list