+N3huyLaUn9yMwQ/lj4Ndj1g=
MIME-Version: 1.0
Received: by 10.204.141.69 with SMTP id l5mr3865126bku.64.1267010028293; Wed,
24 Feb 2010 03:13:48 -0800 (PST)
Reply-To: noloa...@gmail.com
Date: Wed, 24 Feb 2010 06:13:48 -0500
Message-ID: <605f8e051002240313y626fe709webba88c1799b5...@mail.gmail.com>
24 Feb 2010 02:28:59 -0800 (PST)
Reply-To: noloa...@gmail.com
Date: Wed, 24 Feb 2010 05:28:59 -0500
Message-ID: <605f8e051002240228v26b2eefeu9441c891d960f...@mail.gmail.com>
Subject: Tests diff
From: Jeffrey Walton
To: pdf-devel@gnu.org
Content-Type: multipart/mixed
Hi Aleksander,
> Did you try gzip-ing the file before sending it?
I tried tar/bz2.
Sadly, the mail server leaves the rejection as a mystery by not
offering a reason.
Does GNU have an FTP site?
Jeff
On Wed, Feb 24, 2010 at 5:34 AM, Aleksander Morgado
wrote:
> Hi Jeff,
>
>>
>> > Could you send
Hi Aleksander,
> Could you send a diff or bzr merge directive instead of all
> these changed files?
Unfortunately, I cannot. The mail server is rejecting again.
Jeff
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more o
Hi All,
This is an updated unit test. The test cases include overflow and
detection, and bad params. It was tested with and without
PDF_FORCE_BIGNUMS. I did not create the full patch/diff since it can
be rejected.
* drop pdf_i64_neg.c in torture/unit/base/types/ over top of the existing file
Jef
Hi All,
This is an updated unit test. The test cases include overflow and
detection, and bad params. It was tested with and without
PDF_FORCE_BIGNUMS. I did not create the full patch/diff since it can
be rejected.
* drop pdf_i64_abs.c torture/unit/base/types/ over top of the existing file
Jeff
/
Hi All,
This is a missing unit test. It was tested with and without
PDF_FORCE_BIGNUMS. I did not create the full patch/diff since it can
be rejected.
* drop pdf_i64_mult_i32.c torture/unit/base/types/
* add a declaration and statement in torture/unit/base/types/tsuites-types.c
* add a entry under
Hi All,
This is a missing unit test. It was tested with and without
PDF_FORCE_BIGNUMS. I did not create the full patch/diff since it can
be rejected.
* drop pdf_i64_cmp_i32.c into torture/unit/base/types/
* add a declaration and statement in torture/unit/base/types/tsuites-types.c
* add a entry u
Hi All,
This is a missing unit test. It was tested with and without
PDF_FORCE_BIGNUMS. I did not create the full patch/diff since it can
be rejected.
* drop pdf_i64_add_i32.c into torture/unit/base/types/
* add a declaration and statement in torture/unit/base/types/tsuites-types.c
* add a entry u
H All,
patch_safety_dispatcher.py seems to be hanging on error_exit_success.
Below was stopped after about half an hour (the checks before
error_exit_success returned immediately).
Any ideas?
Jeff
jeff...@gauss:~/Gnu-Pdf$ make syntax-check
GFDL_version
GPL_version
Wundef_boolean
avoid_if_before
Hi Aleksander,
> That `srunner_run' function is in SVN check:
> svn co https://check.svn.sourceforge.net/svnroot/check check
OK. Thanks. I should have paid better attention to "the SVN version..."
Jeff
On Fri, Feb 19, 2010 at 4:59 AM, Aleksander Morgado wrote:
>
>> Sorry to ask yet another lame
Hi All,
Nearly all (if not all) of the pdf-types functions return PDF_ERROR if
response to a required but missing parameter. For example,
pdf_i64_t a, b;
pdf_status_t status;
pdf_i64_add(NULL, a, b, &status)
would return PDF_ERROR even though PDF_EBADDATA specifies bad
arguments into
Hi Jose,
Sorry to ask yet another lame question
> Briefly, now it is possible to specify a selection when
> invoking make check. So...
>
>$ make check FUNCTION=pdf_alloc
> ...
>
> The hacker's guide has been updated to document this new
> functionality.
'make check' is failing due to und
Hi Aleksander,
>> Can the functions with an asterisk be removed? If the functions are
>> not 'code proliferation' added over time, I will write test cases for
>> them.
> No, we shouldn't remove them. They may not be used in the base layer,
> but they may be used in upper layers.
OK. I'll begin on
Hi All/Aleksander,
> Also created a new flyspray task for the remaining ones:
> http://www.gnupdf.org/flyspray/index.php?do=details&task_id=110
> The task is quite easy and can be taken by any new contributor.
If no one else is interested, I'd be happy to work them.
I'm a firm believer in slaying
Hi All/Jose,
Below is a list of functions of interest relating to pdf_i64_t from
http://gnupdf.org/Lib:API_Consistency_Report. I believe they make up
the public functions exposed by pdf-type.h/pdf-type.c.
The items with an asterisk (*) are not used. In general, they are a
pdf_i32_t variant of the
Hi Aleksander,
> I agree in that a name like "pdf_i64_set_i32" would be clearer.
> Not in the other things.
OK (but don't discount elegance).
>> something like pdf_i64_new_i32 might be more useful:
> Well, that is something that could also be added, and may be
> useful in cases like the one you s
Hi All,
jeff...@gauss:~/gnu-pdf$ sudo rm -rf /usr/local/lib/*gnupdf*
...
./configure CFLAGS=-g PREFIX=/usr
...
make install
...
Libraries have been installed in:
/usr/local/lib
jeff...@gauss:~/gnu-pdf$ ls /usr/local/lib/*gnupdf*
/usr/local/lib/libgnupdf.a /usr/local/lib/libgnupdf.so.0
/usr/l
Hi Aleksander (and Jose),
> Jose and me tried on weekend to run under GDB all torture
> tests, playing with "follow-fork-mode" and "detach-on-fork"
> options; but no success.
> [SNIP]
Thanks for the help. It's nice to see it was not something dumb on my part.
> Thus, this is not a good method to
Hi Jose,
> Its not enough to '#define PDF_FORCE_BIGNUMS' in types.h (apparently,
> some modules do not treat pdf_i64_t opaquely, or do not honor
> PDF_USE_BUILTIN_64BIT_SUPPORT).
>
> Which modules are those? We definitely want to fix that.
I think this one is now tracked down. pdf-time.c wo
Hi All/Jose,
I was looking at the gnupdf.texi file. In the document, pdf_i64_add is
shown as (in the documentation for pdf_error):
pdf_i64_t dest, addend_1, addend_2;
pdf_status_t status;
...
status = pdf_i64_add (dest, addend_1, addend_2);
In the H and C file, the function is as follows:
pdf_i
Hi All/Jose,
In config.h near line 790, there's the following comment:
/* Force the usage of the 64bits bignum implementation even if the system
support a suitable native type */
/* #undef PDF_FORCE_BIGNUMS */
I think the comment could be revised to better reflect preprocessor state:
/* Force
Hi Aleksander,
Thanks for the QC... It's a new day, and I'm fresh, so hopefully no
dumb mistakes.
Jeff
On Tue, Feb 2, 2010 at 3:13 AM, Aleksander Morgado
wrote:
> Hi Jeff,
>
>> I believe the problem arises because, in the case of
>> PDF_FORCE_BIGNUMS, a struct is being pushed on the stack and a
Hi All,
If PDF_FORCE_BIGNUMS is defined, the library's pdf_i64_t is used:
struct pdf_i64_s
{
pdf_i32_t high;
pdf_u32_t low;
};
typedef struct pdf_i64_s pdf_i64_t;
Running 'make check' causes a melt down in a number of modules (shown
below). I can control the way many of these functions crash
Hi Aleksander,
>> I was able load and run the script under gdb as stated in [1]. I set a
>> BP on the function of interest. gdb responded as expected with a file
>> and line number (which were correct).
>>
>> However, when I run the script, the BP is never hit. I do see the
>> results of the faile
Hi All/Jose,
I was able load and run the script under gdb as stated in [1]. I set a
BP on the function of interest. gdb responded as expected with a file
and line number (which were correct).
However, when I run the script, the BP is never hit. I do see the
results of the failed test, so I know t
Hi All,
I seem to be having problems running runtests.sh after building. Any
ideas where ${srcdir}/runtests is located? I can't seem to find it and
the script appears to be blowing up.
Jeff
jeff...@gauss:~/trunk/torture/unit$ sh ./runtests.sh
chmod: cannot access `/torture/testdata/TD4': No
Hi All,
Does the group have a preference on using assertions? I found one
thread in the archives that touched on their use, but nothing in the
style guide.
Jeff
28 matches
Mail list logo
