> I wrote a fuzzing "framework" called Fusil and this week I wrote a fuzzer for
> Python. The idea is quite simple: for a module,
> - list all functions, classes and class methods
> - call a function with random arguments (of random types)
> - instanciate a class with random arguments
> - if t
> It's not only a question of changing a static label in this case. A
> given buildslave can run the tests for multiple projects, in which
> case it becomes tricky to change the label on the fly accordingly.
I think you could set up different builders for a single slave in
that case (use a slave l
On Sun, Jul 6, 2008 at 4:11 PM, Victor Stinner
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I wrote a fuzzing "framework" called Fusil and this week I wrote a fuzzer for
> Python. The idea is quite simple: for a module,
> - list all functions, classes and class methods
> - call a function with random arg
Hi,
I wrote a fuzzing "framework" called Fusil and this week I wrote a fuzzer for
Python. The idea is quite simple: for a module,
- list all functions, classes and class methods
- call a function with random arguments (of random types)
- instanciate a class with random arguments
- if the clas
On Sun, Jul 6, 2008 at 8:46 AM, <[EMAIL PROTECTED]> wrote:
>
> However, let's say that this were tremendously successful, and lots of
> people start paying attention. I think pybots.org needs to be updated to
> say exactly what a participant interested in python testing needs to do,
> beyond "her
> I believe there is still a need for packing integers as strings and
> unpacking strings as integers, more specifically, offering to Python
> an interface to _PyLong_FromByteArray() and _PyLong_AsByteArray(). I
> would be happy to write the functionality and unittests this coming
> week for 2.6 a
> (I'd also like to improve the labels of the build slaves. What exactly
> is "x86 Red Hat 9 trunk" testing? Trunk of what? What project?)
It seems like you would like to edit the master configuration file.
That can be arranged fairly easily.
Regards,
Martin
___
[EMAIL PROTECTED] writes:
> On 01:02 am, [EMAIL PROTECTED] wrote:
> >To bring my $0.02 to this discussion: the Pybots 'community buildbots'
> >turned out largely to be a failure.
>
> Let's not say it's a failure. Let's instead say that it hasn't yet
> become a success :-).
+1
> >I still
> Why a borrowed reference rather than a new one? It could be decref'ed as
> part as the proposed PyBuffer_Release procedure.
The question is
a) whether a Py_Buffer remains valid even if the object goes away.
That seems not to be the case, i.e. the caller of getbuffer needs
to hold onto the
On 01:02 am, [EMAIL PROTECTED] wrote:
To bring my $0.02 to this discussion: the Pybots 'community buildbots'
turned out largely to be a failure.
Let's not say it's a failure. Let's instead say that it hasn't yet
become a success :-).
I still haven't given up, and I hope this thread will spur
Le dimanche 06 juillet 2008 à 00:28 +0200, "Martin v. Löwis" a écrit :
> I propose that new codes s*, t*, w* are added, and that s#,t#,w# refuses
> objects which implement a releasebuffer procedure (alternatively, s# etc
> might be removed altogether right away). Users of s* then need to pass
> in
11 matches
Mail list logo
