2:07 p.m.
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
2:46 a.m.
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.
7:43 a.m.
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
12:56 p.m.
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(a)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
1:11 p.m.
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
3872
days inactive
3877
days old
4 comments
3 participants
participants (3)
-
Claudio Bley -
Eric Blake -
Pasquale Dir