[libvirt] More java bindings functions
Hello, I just added, because I needed them, two new bindings for java apis: Connection.getCpuStats(int, long) and Domain.getCpuStats(int, long) these two functions act like python's counterpart. I give you the .jar with sources so that, after you review it (it works but I am not entirely sure it is bug free), you could publish it thus helping java programmers who needed a cpu indicator too. Regards, Pasquale Di Rienzo
At Sun, 16 Mar 2014 20:07:48 +0100, Pasquale Dir wrote:
I just added, because I needed them, two new bindings for java apis:
Connection.getCpuStats(int, long) and Domain.getCpuStats(int, long)
What do those parameters mean? What's the return type of these methods?
these two functions act like python's counterpart.
I give you the .jar with sources
If there was an attachment, it has been stripped by the mailing list processor. Please send your patches directly to the list as that eases review a lot. In order to do so, just use the "git send-email" command. See http://libvirt.org/hacking.html#patches for general tips. Also, you might want to use "git config format.subjectprefix 'java][PATCH'" in order to indicate the project you're working on in the subject. -- BSc (Comp) Claudio Bley - Principal Software Engineer AV-TEST GmbH, Klewitzstr. 7, 39112 Magdeburg, Germany Phone: +49 391 6075460, Fax: +49 391 6075469 Web: <http://www.av-test.org> * https://twitter.com/avtestorg * https://facebook.com/avtestorg * * https://plus.google.com/100383867141221115206/ * Eingetragen am / Registered at: Amtsgericht Stendal (HRB 114076) Geschaeftsfuehrer (CEO): Andreas Marx, Guido Habicht, Maik Morgenstern Our services shall be effected on the basis of the General Terms and Conditions of AV-TEST GmbH, which are accessible under <http://www.av-test.org/en/av-test/terms-and-conditions/> or obtainable upon request. Unsere Leistungen erfolgen auf der Grundlage der Allgemeinen Geschäftsbedingungen der AV-TEST GmbH, die unter <http://www.av-test.org/av-test/agb/> abrufbar sind oder auf Anfrage übersandt werden.
On 03/17/2014 01:46 AM, Claudio Bley wrote:
At Sun, 16 Mar 2014 20:07:48 +0100, Pasquale Dir wrote:
I just added, because I needed them, two new bindings for java apis:
Connection.getCpuStats(int, long) and Domain.getCpuStats(int, long)
What do those parameters mean? What's the return type of these methods?
these two functions act like python's counterpart.
I give you the .jar with sources
If there was an attachment, it has been stripped by the mailing list processor.
The mailing list DID strip it. Your .jar was bigger than the mail limit of 150k. That, and binary attachments are frowned on - we prefer dealing with source patches, not binaries.
Please send your patches directly to the list as that eases review a lot. In order to do so, just use the "git send-email" command. See http://libvirt.org/hacking.html#patches for general tips.
Also, you might want to use "git config format.subjectprefix 'java][PATCH'" in order to indicate the project you're working on in the subject.
Both pieces of good advice. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
That seems a little complicated...sorry but I never used git in this way and I have very little time to learn this too. They are just 3-4 source files, if someone can handle this for me I'd be happy to send them so they can upload in the right way. Sources are less then 150Kb, that is for sure...if I send you a .rar with the sources would it be ok? 2014-03-17 13:43 GMT+01:00 Eric Blake <eblake@redhat.com>:
On 03/17/2014 01:46 AM, Claudio Bley wrote:
At Sun, 16 Mar 2014 20:07:48 +0100, Pasquale Dir wrote:
I just added, because I needed them, two new bindings for java apis:
Connection.getCpuStats(int, long) and Domain.getCpuStats(int, long)
What do those parameters mean? What's the return type of these methods?
these two functions act like python's counterpart.
I give you the .jar with sources
If there was an attachment, it has been stripped by the mailing list processor.
The mailing list DID strip it. Your .jar was bigger than the mail limit of 150k. That, and binary attachments are frowned on - we prefer dealing with source patches, not binaries.
Please send your patches directly to the list as that eases review a lot. In order to do so, just use the "git send-email" command. See http://libvirt.org/hacking.html#patches for general tips.
Also, you might want to use "git config format.subjectprefix 'java][PATCH'" in order to indicate the project you're working on in the subject.
Both pieces of good advice.
-- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 03/21/2014 11:56 AM, Pasquale Dir wrote: [please don't top-post on technical lists]
That seems a little complicated...sorry but I never used git in this way and I have very little time to learn this too.
Learning how to get 'git send-email' to do the right thing will generally save you more time in the long run than it costs in the short term to learn it.
They are just 3-4 source files, if someone can handle this for me I'd be happy to send them so they can upload in the right way.
The problem is that "upload in the right way" is best done by smaller incremental patches, not giant patch bombs. We don't like taking code that is unreviewed, but reviewers don't like reviewing giant blobs of code. It is in EVERYONE'S best interest to split patches into smaller chunks.
Sources are less then 150Kb, that is for sure...if I send you a .rar with the sources would it be ok?
No. Send the patches directly as plain-text attachments legible inline with the mail, the way 'git send-email' does it. Looking over past archives of the mailing list will show you examples of what forms a good patch. Doing it any other way merely serves to obscure the patches, and reviewers tend to not want to spend time digging out an obscure patch. Unpacking a .rar file just to get at the source patch is not my idea of fun, in comparison to just reading it in my email client. Which goes back to the premise above: the right way to get code in is to get it reviewed, but if you make the reviewer's life hard, it won't get reviewed, and therefore won't get in. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
participants (3)
-
Claudio Bley -
Eric Blake -
Pasquale Dir