os;
> +return PDF_OK;
> + }
>
> Same problem with the codying style. Are you sure you sent the
> right patch?
BTW, here is the trunk-updated one.
cheers,
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ge...@gnu.org-20100419214335-m0t0
os;
> +return PDF_OK;
> + }
>
> Same problem with the codying style. Are you sure you sent the
> right patch?
>
Ah, sorry. It was late night :-)
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ge...@gnu.org-20100419212947-5slqrrerw7
Here is a patch for new method pdf_fsys_build_path(). I tested it on
GNU/Linux. Could anyone test it under win32 ?
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ge...@gnu.org-20100419170436-4jrtn5o6esdkodo4
# target_branch: file:///home/gerel/PROJECTS/libgnupdf/trunk
Here is a patch for a small fix. It's better to leave the original pointer
unchanged if pdf_realloc() fails.
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ge...@gnu.org-20100419120134-14rd0ap31ofson9n
# target_branch: file:///home/gerel/PROJECTS/libgnupdf/
> in the copyright notice of the new files.
>
Ouch, corrected. :-)
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ge...@gnu.org-20100419112149-zn9llbaur451bluk
# target_branch: file:///home/gerel/PROJECTS/libgnupdf/trunk/
# testament_sha1: 57e1baa33322166419a32ff471d0a60
Here is a patch for #117, text object and ASCII concat (doc and tests are a
gift :-) ).
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ge...@gnu.org-20100419041257-27mlz6ww2gz9khgu
# target_branch: file:///home/gerel/PROJECTS/libgnupdf/trunk/
# testament_sha1
es and formatting standards.
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ge...@gnu.org-20100418220134-trs0lcewdogy6i00
# target_branch: file:///home/gerel/PROJECTS/libgnupdf/trunk/
# testament_sha1: d9d08026b881b338443d8f01871f0fa8b1792db2
# timestamp: 2010-04-18 19:01:37 -0300
# ba
Ok. Here is try 2 :-)
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ge...@gnu.org-20100418215209-0imic49ywr2s6dx9
# target_branch: file:///home/gerel/PROJECTS/libgnupdf/trunk/
# testament_sha1: e23fd060d388ce397f3749dd265260573d26eafb
# timestamp: 2010-04-18 18:52:31 -0300
Here is try 2. Review and apply.
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ge...@gnu.org-20100418214759-c1ho9719elvho1kk
# target_branch: file:///home/gerel/PROJECTS/libgnupdf/trunk/
# testament_sha1: ef2e62b091722280c7473af3bcc5769214eadcfb
# timestamp: 2010-04-18 18:48
callback, casting the bool to
> pdf_bool_t as appropriate. Such an extra level of callback will allow
> to make changes on the callback provided by pdf_list in the future.
>
Right but I have no clue how we can access the user-suplied
callback from pdf-list's callback. Can you give me a hint on this ?
cheers,
-gerel
Hi GNUsuperblovers.
Here is a patch for FS#116. New pdf_text_get_printable.
Aleks, tell me if this was what you meant.
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ge...@gnu.org-20100417224914-sh8jq4wz0vee17tr
# target_branch: file:///home/gerel/PROJECTS/libgnupdf/trunk
Hi GNU PDFists,
Here is a patch for FS#115 with casting. Note that we still need stdbool.h, I
guess wa can't get rid of it.
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ge...@gnu.org-20100417212056-37k2sfn5njwt1m72
# target_branch: file:///home/gerel/PROJECTS/libg
Hi pdf-fanatics,
I wrote a patch for FS#114. The test 'pdf_stm_bseek_003' which was failing,
now passes with this patch.
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ge...@gnu.org-20100417202736-pwl7xtabdsz66804
# target_branch: file:///home/gerel/PROJECTS/libgn
Hi folks,
Here is a patch for the task. Also added a little description about the filter
utility.
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ge...@gnu.org-20100417195754-895q68ulo5ivyj38
# target_branch: file:///home/gerel/PROJECTS/libgnupdf/trunk/
# testament_sha1
> Date: Thu, 15 Apr 2010 19:55:43 +0200 (CEST)
> From: Jose E. Marchesi
>
>
> Gerel, if you gree with my suggestion, please add a note to the task
> in flyspray explaining why it is being put on hold.
>
> BTW, I just added a WAITING state for the ta
> From: James Cloos
> Date: Wed, 14 Apr 2010 15:34:41 -0400
>
> >>>>> "g" == gerel writes:
>
> g> Comments needed!!
>
> Recently, a number of projects which used to rely on jasper for dealing
> with jpeg2k have switched to openj
ing). So, if the same object is to be used by different threads, then
> the app using the object should provide proper sync mechanisms to access
> the object.
>
I understand, that's a good point. :-)
cheers,
-gerel
any new call to pdf_text_get_printable()
> will re-create the printable string again with the proper contents.
>
Hey Aleks,
We shouldn't forget about multi-threading in that case, right ?
cheers,
-gerel
rojects (unlike OpenJPEG) and should be more
stable. Also note that Jasper supports the old JPG format with the IJG library.
Comments needed!!
-gerel
.90)
# revision_id: ge...@gnu.org-20100407145719-2q2w0105emxjo8q1
# target_branch: file:///home/gerel/PROJECTS/libgnupdf/trunk/
# testament_sha1: e103c25a94ba4c997041483413ae7b134bf36b50
# timestamp: 2010-04-07 11:58:22 -0300
# base_revision_id: jema...@gnu.org-20100406180821-f11qzdma8q95ql09
#
# Begin patch
BTW, shouldn't those tests be expecting a PDF_EBADDATA ?
They're expecting a PDF_ERROR when they're giving a NULL parameter.
-gerel
p_status);
}
if (pdf_i64_cmp(dividend,zero) < 0)
{
pdf_i64_abs(÷nd,dividend, p_status);
result_sign = -1;
}
[...]
###
I may be wrong, I didn't read the whole function code, because I'm not familiar
with the Knuth method.
Despite that, I tried the above proposed modification and no new test fails. It
seems to work fine or do nothing. :-)
Any comments ?
cheers,
-gerel
> Date: Tue, 30 Mar 2010 21:08:23 +0200 (CEST)
> From: Jose E. Marchesi
>
>
> Hi Gerel.
>
> Well, this is an updated patch. Since the native/macros 64bit support
> returned
> PDF_ERROR when the built-in implementation returns PDF_EBAADDATA. Aft
...@gnu.org-20100330141235-qeuvfavpsrx5rafw
# target_branch: file:///home/gerel/PROJECTS/libgnupdf/trunk/
# testament_sha1: f841372ab4f10f7323b4bc49f42d022eb5c5f05d
# timestamp: 2010-03-30 11:12:41 -0300
# base_revision_id: jema...@gnu.org-20100329190802-wr4mv6t7v3iej6j4
#
# Begin patch
=== modified
0.90)
# revision_id: ge...@gnu.org-20100330132441-midx1wxntds9tlm4
# target_branch: file:///home/gerel/PROJECTS/libgnupdf/trunk/
# testament_sha1: c029f221976f4e69952408b1fed3c820694b8fdc
# timestamp: 2010-03-30 10:24:50 -0300
# base_revision_id: jema...@gnu.org-20100329190802-wr4mv6t7v3iej6j4
#
#
to the check library.
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ge...@gnu.org-20100329165037-1vf251lf9qru3h5u
# target_branch: file:///home/gerel/PROJECTS/libgnupdf/trunk/
# testament_sha1: 2cc2ad68d7f79803f6554f84a3d4c05b89e06a81
# timestamp: 2010-03-29 13:50:44 -0300
# ba
The day we
start with beta testing, we're gonna be writing tons of them to find a bug. We
could start now instead. :-)
cheers,
-gerel
unassigned task and marked
as NEXT.
welcome and happy hacking!
-gerel
Hi,
I'm sending a patch for "FS#101 - API consistency script update".
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ge...@gnu.org-20090727144138-b9ozhykkqi3g0vd0
# target_branch: file:///home/gerel/PROJECTS/libgnupdf/trunk/
#
> Date: Thu, 23 Jul 2009 20:45:33 +0200
> From: jema...@gnu.org
>
>
> Hi Gerel.
>
>+...@item PDF_EIMPLLIMIT
>+The filter has been asked for features that aren't implemented
>yet.
>
> That error code is for signaling that the operati
Arch document includes 3 new filter status codes as we agreed.
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ge...@gnu.org-20090723165640-uiv7mde1x5k7t51v
# target_branch: file:///home/gerel/PROJECTS/libgnupdf/trunk/
# testament_sha1: 3a67cbabc4f85f73abbbd91c7feebaa5e091b2ce
# time
pecify a
> estimated size the hash tables for performance. I suppose gnulib has
> support this.
>
Hi David,
Well if you refer to the size of the hash struct and gnulib supports what you
need, then it could be easily estimated given that it's composed of gnulib
lists. Correct me if I'm wrong.
cheers,
-gerel
valid data)
Tell me what you think and then i'll proceed.
cheers,
-gerel
n, May 18, 2009 at 21:14:17 -0300, gerel wrote:
> =2E..
> > Sure, it all comes down to one thing: error !=3D eof !=3D no_read/writte=
> n data.
> > I believe the current code was meant to work mainly for memory backends.
> >=20
> > So, the set of status code for
Hi Michael,
First, please note that most of your comments are for already existing code, so
we should ignore my previous patch on this discussion.
Now to the comments.
> Date: Mon, 18 May 2009 19:30:27 -0400
> From: Michael Gold
>
> On Mon, May 18, 2009 at 16:44:15 -0300,
only made to the 'pdf_stm_flush()' function.
-gerel
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ge...@gnu.org-20090518194211-yxh994dwe8cbvsb3
# target_branch: file:///home/gerel/PROJECTS/libgnupdf/trunk/
# testament_sha1: 67f5d91d3a742545d61a5b4a11854d30aefd8d10
#
Here is a patch for the tests plus minor fixes on the Fsys API.
BTW, there is no function in the Fsys API for removing a file yet.
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ge...@gnu.org-20090515193503-2wlvzcq2krwog2ql
# target_branch: file:///home/gerel/PROJECTS
1159: libtool: compile: cannot determine name of library
object from `': command not found
make[3]: *** [gl_array_list.lo] Error 1
make[3]: Leaving directory `/home/gerel/PROJECTS/libgnupdf/work/lib'
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory `/home/gerel/PROJECTS
r the time
it takes)
That way we can ask people in case 4 how is it going, and if they would leave it
for someone else.
cheers,
-gerel
> Please proceed.
>
BTW, Aleks seems to be implementing the Fsys module, any news ?
-gerel
p
but without an assigned task.
I'd like to ask you to change the status to STARTED for every task you have
assigned. In case you are unable to work on it, someone could take over it if
you leave it unassigned again.
I don't want to hurry anyone, but to keep us all busy and get fun. :-)
regards,
-gerel
u, May 14, 2009 at 23:00:50 -0300, gerel wrote:
> =2E..
> > I suggest getting rid of the ELEM_SIZE+ELEM_COUNT variables. And, if a b=
> igger
> > than 1 octet should be read for buffering issues (fread/fwrite), that
> > should be managed by the implementation and not publis
> Date: Fri, 15 May 2009 00:07:48 +0200
> From: jema...@gnu.org
>
>
> Hi Gerel.
>
>The return description for fsys file read/write is wrong when using the
> default
>disk implementation, since fread/fwrite return the number of 'elements'
u, May 14, 2009 at 02:03:26 -0300, gerel wrote:
> >=20
> > Hi,
> >=20
> > The return description for fsys file read/write is wrong when using the d=
> efault
> > disk implementation, since fread/fwrite return the number of 'elements'
> > read/wr
e file stream tests as soon as we resolve this.
cheers,
-gerel
ing on gcc 4.1.2, although I don't believe it's a
version issue but a macro one. Any ideas jemarch ? you're the macro guru :-)
greetings
-gerel
changes from 5.8.x to 5.10.x, although the script uses
'standard' modules. So, I'll go straight to 5.10.x and do some tests.
Is it a big deal if you provide me access to that version with the source tree ?
I'll have to waste some time compiling that version myself otherwise.
cheers,
-gerel
> Date: Wed, 06 May 2009 17:39:33 +0200
> From: jema...@gnu.org
>
>
> Hi Gerel.
>
>The page http://gnupdf.org/Lib:API_Consistency_Report reports that
>pdf_stm_read() has 0 unit tests, while the perl script says there are 11
> (which
>is the
Hi,
The page http://gnupdf.org/Lib:API_Consistency_Report reports that
pdf_stm_read() has 0 unit tests, while the perl script says there are 11 (which
is the right answer).
cheers,
-gerel
on_id: ge...@gnu.org-20090419191134-eurwefzyg37iqbbj
# target_branch: file:///home/gerel/PROJECTS/libgnupdf/trunk/
# testament_sha1: c4e3c675750c4e614b69df35af941be386bc3828
# timestamp: 2009-04-19 16:11:41 -0300
# base_revision_id: jema...@termi-20090416221338-b8nyznfgedla5ys9
#
# Begin patch
=== modi
> Date: Mon, 6 Apr 2009 22:11:16 +0200
> From: the Adib
>
> that was quick!
>
> Thx, all.
>
> Adib.
> ---
In fact, thank _you_ for reporting the bug. :-)
-gerel
w8TWpIJQRyOU+1RIep7HImJjUjI4Ey/gpDmVn75ORE68tFw4chaGyKGQxh9eo4GLK/+SX46fTnU
AwsRd3FF7hfrZqFfxDQTdhec5icxlwEcSYznoiv42Om0IPRBjJ50072Wow2Bgj3Di+kHCPME/Z0s
OGm8B4ETguPKxFRYtdQGFnLGwuEIFzkALilQhYKoUKPXEpATYBwElBc5g6NRkADd6pAzFYgbaIIk
ZI5pLF6uDwnWjXqNu3aD5lmCAOMS4ljKQ3cDysJHhvYHI93VkwsnpDkpcbitk+lJQi4O49YTWg+c
GGY0pyuNk0RmzmoKVuQMTBEyz0KIqQu98sXnl+wWNmZVBCNsiYiigT2C1w5Jb9s9IHuBBQVqDDmB
EMg7fQhmYCm9mbaB0qAunWYKLwtv2i7kinChId5IwnQ=
###
-gerel
ary
> Summary - Add cplusplus guards in the generated pdf.h header file
Want me to do it ?
-gerel
e filtered
>data to the output file; then it would close the stream
>
But, in the meantime (i.e. before the save), isn't all in RAM anyways ? If it
is, I can't see the benefit of this idea in terms of RAM consumption.
I'd still define this feature as optional, we could use temp files (the legacy
method) or use the method you propose (a more secure method).
cheers,
-gerel
of the library creating temporary files on
> its own. Opening a file in a library can cause security issues, for
> example:
> http://udrepper.livejournal.com/20407.html
> (Linux 2.6.27 is needed to protect against this, and I'm sure there are
> operating systems without this feature.)
Interesting security risk, but if we make all memory-based, how much memory will
we need, on average, to edit a document ?
Maybe we could provide this as an optional feature for the poor user with few MB
of RAM.
just my 2 cents,
-gerel
F document ? (e.g. an indirect reference). I tried to find
out with the PDF reference but nothing.
Anyways, if they can't, I suggest to move the API description to the "Object
documents" section, as I see it, they're an attribute of the document.
BTW, I read 'strong reference' in the object layer section but couldn't find any
mention to them in the PDF reference. Any help ?
regards,
-gerel
Hi I've found a bug in configure.ac, whether a feature is called with --enable
or --disable the script always enables it.
I attach a patch for the correct behavior.
regards,
-gerel
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ge...@gnu.org-20090205225432-bn49l3dhpt0
> From: David Vazquez
> Date: Wed, 04 Feb 2009 16:01:58 +0100
>
>
> Hi gerel,
>
> It seems. I think there is similar errors (e.g: sqrt operand works on
> real numbers and it does not check their parameter to be non-negative).
>
> I am working on error
-;
break;
[...]
case OPC_idiv:
if (sp < 1) goto stack_underflow;
if (!INT_P(stack[sp]) || !INT_P(stack[sp-1]))
goto type_error;
stack[sp-1] = INT(stack[sp]) / INT(stack[sp-1]);
sp--;
break;
###
Is that a bug ?
regards,
-gerel
nd error.
Anyways, it's not essential so I agree whatever your resolution is. :-)
regards,
-gerel
-20090201215446-7hkfwa15j72m39kb
# target_branch: file:///home/gerel/PROJECTS/libgnupdf/trunk/
# testament_sha1: 68781c0a97a54921c9da416a27a16548df5d22b8
# timestamp: 2009-02-01 18:55:00 -0300
# base_revision_id: jema...@gnu.org-20090127234647-nrebrv4p7822miqn
#
# Begin patch
=== modified file
After Michael's suggestions here is a patch for the task.
cheers,
-gerel
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ge...@gnu.org-20090128115858-o2xmgr9bv9gxfn69
# target_branch: file:///home/gerel/PROJECTS/libgnupdf/trunk/
# testament
bort instead of giving the chance to handle the
error. But if the asserts would fail at compile-time or in the test suite at
run-time then I have no problem with them.
So, let's sum up. We use a 'void*' and add a test case with a:
assert(sizeof(gl_itr)<=sizeof(our_itr))
Any other suggestion ?
regards,
-gerel
of() on gl_list because that way we need to make gnulib
implementation public. :-/
Correct me if I'm wrong.
-gerel
gl_list_iterator_free doesn't
> do anything, and it would be a bit simpler to use the types without
> them. If _iterator can't fail with ENOMEM, I don't see what we'd need to
> free in the future.
Consider that the pdf_list is a wrapper, if gnulib developers tomorrow decide
that the free procedure IS necessary, we will regret about this decision. :-)
cheers,
-gerel
0.90)
# revision_id: ge...@gnu.org-20090127162410-3a4a7mwi5w4ehe2y
# target_branch: file:///home/gerel/PROJECTS/libgnupdf/trunk/
# testament_sha1: 80a8528867587b4d8e409d318e9816c9a497c33b
# timestamp: 2009-01-27 13:24:13 -0300
# base_revision_id: jema...@gnu.org-20090126221335-uawe5w60akblz44r
#
# Begin
Hi hackers,
I attach a patch for the task in question.
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ge...@gnu.org-20090127141432-ug96eejedyuzhhsp
# target_branch: file:///home/gerel/PROJECTS/libgnupdf/trunk/
# testament_sha1: 34dee3b07cc9994647497f38bdcef8c12eb90415
/paste or the pdf-filter compilation, but they generally don't
> mess downloading a file.
regards,
-gerel
to the flate encoded stream (so the user/developer can play with the
pdf-utility on his system)
my 2 cents.
cheers,
-gerel
> Date: Sun, 25 Jan 2009 21:20:46 +0100
> From: Aleksander Morgado
>
> Hi gerel
>
> >
> > I attach a patch for task #87, tested with null filter and seems to work
> > ok.
>
>
> Did you try to read/write files with the filesystem module
Hi all,
I attach a patch for task #87, tested with null filter and seems to work ok.
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ge...@gnu.org-20090124203828-p65udq2xcg5kc55j
# target_branch: file:///home/gerel/PROJECTS/libgnupdf/trunk/
# testament_sha1
cause users usually don't know if they compiled
> the library the recommended way or not.
Hi Beuc,
I agree with you, note that the configure script prints a summary when
finishes. Maybe what we can do is to add to this summary what features are
recommended/essential, or to the README or INSTALL file.
What you think ?
-gerel
> Date: Fri, 23 Jan 2009 00:53:39 +0100
> From: jema...@gnu.org
>
> > > Gerel, what do you think about this? We would of course loose the
> > > benefits of the opaque pointers in this case, but
> 'pdf_obj_equal_p'
> > &
plications, each with a different OOM policy.
> We shouldn't impose any policy on them.
>
It was hardly suggested to not fix/modify the gnulib modules in previous emails,
I don't know...
cheers,
-gerel
> Date: Fri, 23 Jan 2009 00:27:43 +0100
> From: jema...@gnu.org
>
> > Date: Thu, 22 Jan 2009 20:48:24 +0100
> > From: jema...@gnu.org
> >
> > Gerel, what do you think about this? We would of course loose the
> > benefits o
> Date: Thu, 22 Jan 2009 20:48:24 +0100
> From: jema...@gnu.org
>
> Gerel, what do you think about this? We would of course loose the
> benefits of the opaque pointers in this case, but 'pdf_obj_equal_p'
> throwing PDF_ENOMEM sounds quite weird, and I
rn that error). It would
>be nice if the iterator could be kept on the stack -- struct
>pdf_list_iterator_s only contains one member anyway.
>
> Gerel, what do you think about this? We would of course loose the
> benefits of the opaque pointers in this case, but 'p
Sorry, I would forget about multiple success conditions and treat them all as
one.
The newline character can't be meaningful in the context. :-)
cheers
-gerel
current format should be currently used in every test file, but it
> would need to be extended to support an easily-parseable list of used
> data files. Can you send a proposal to the list?
Sorry, I would forget about multiple success conditions and treat them all as
one.
The newline character can't be meaningful in the context. :-)
cheers
-gerel
the truly important part is the beginning string "Test:" that can
be found after any number of spaces/newlines.
Anyways, that's it.
cheers
-gerel
' have a 'TDX.desc' text file with
the test data description.
Keeping to those rules I can try to write a perl script that generates the Test
Specification Document automatically. That means we need to write less texinfo
code. :-D
cheers
-gerel
r consistent functions.
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ge...@gnu.org-20081230173312-axeey3fg7dihb121
# target_branch: file:///home/gerel/PROJECTS/libgnupdf/trunk/
# testament_sha1: 063f33cd8fe0d3ae33afcf5d618a7f39de0ea0c6
# timestamp: 2008-12-30 14:33:30 -0300
# base_re
> Date: Sun, 28 Dec 2008 17:58:59 +0100
> From: jema...@gnu.org
>
> Hi Gerel.
>
> Would it be possible for the check-api-doc-consistency.pl to tell if a
> given function has unit tests defined (at least one) in torture/unit,
> and the number of tests?
Yes, it
t; to insert a pdf_off_t value to a hash, please add the pdf_hash_add_off
> function to pdf-hash-helper.[ch] and use it. Note that we are
> supporting helper functions for types defined in pdf-types.h or
> pdf-fp.h.
>
> Gerel, what do you think about adding 'pdf_hash_
Hi people,
I attach a patch for a small bug that made the jbig2dec lib check incorrect.
merry xmas everyone. :-)
best wishes.
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ge...@gnu.org-20081224203556-zs0kfpdq0tlrmx63
# target_branch: file:///home/gerel/PROJECTS/libgnupdf
Gerel's patch, then? Should we install it?
jemarch, I don't agree with my patch :-). I'll send another patch with all test
cases working this week, please wait until then.
cheers
-gerel
solution exists which is to leave all as it is and add a flag to
disable opaque pointers when running the test cases.
Solution 1) is the most time consuming but the nicest too. Solution 2) would be
ok to me only if the introduced procedures are not just for testing
purposes. Solution 3 is the simplest one.
cheers,
-gerel
I think we always should use the incremental method for the filters.
As jemarch noted we're dealing with streams on which both ends can have an
arbitrary large data size and a given filter could be an unnecessary bottleneck
(think of remotely located backends).
cheers,
-gerel
hould not be of
your concern.
You can read more here:
http://gnupdf.org/Lib:Architecture/Base_Layer/Stream_Module#Buffers
Regarding the parameters you only ask for the key, as it's supposed to be
already
added prior the filter's call.
Hope it helps,
-gerel
ve
execution permission so you have to call it like
"perl prmgt/srcinfo-extractor.pl". Can we tell configure to chmod +x a file ?
Here is the patch:
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: [EMAIL PROTECTED]
# target_branch: file:///home/gerel/PROJECTS/libgnupdf
> Date: Wed, 26 Nov 2008 21:39:04 +0100
> From: [EMAIL PROTECTED]
>
> Hello Gerel.
>
> I am writing the MANIFEST.wiki files and I was not able to make
> prmgt/srcinfo-extractor.pl to work properly.
>
> I manually added several new directories where to scan
s,
##
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: [EMAIL PROTECTED]
# target_branch: file:///home/gerel/PROJECTS/libgnupdf/trunk/
# testament_sha1: a86d6008f6c1450ec0b91334a59a06977b7330d4
# timestamp: 2008-11-25 20:22:12 -0300
# base_revision_id: [EMAIL PROTECTED]
#
# Begin pat
base/types/pdf-i64-add.c:62: warning: integer constant is too large for
> > 'long' type
> > ###
> >
>
> I do not have such warnings in my compilation, with gcc 4.3.2. Which is
> your version of gcc? It seems that a proper cast to int from long can be
> the solution.
Hi Aleks, my version is 4.1.2, could be that really ?
regards,
-gerel
new module suggested in the previous item. But that doesn't mean that
in our architecture the crypt filter should be implemented _on top_
of that new module, i.e. there is a semantic dependency rather than
structural one, this due to the crypt filter concept on itself.
Just an opinion,
-gerel
integer constant is too large for
'long' type
base/types/pdf-i64-copy.c: In function 'pdf_i64_copy_001':
base/types/pdf-i64-copy.c:60: warning: integer constant is too large for 'long'
type
base/types/pdf-i64-add.c: In function 'pdf_i64_add_001':
base/types/pdf-i64-add.c:62: warning: integer constant is too large for 'long'
type
###
cheers
-gerel
to implement.
Also, don't forget to read:
http://gnupdf.org/Lib:Architecture/Base_Layer/Stream_Module#Filters
cheers,
-gerel
pening the accounts, so wait until he opens one for you. :-)
cheers,
-gerel
>
> I bet you wanted to point to this one:
> http://lists.gnu.org/archive/html/pdf-devel/2008-08/msg00001.html
Hehe, you bet it right, thanks Aleks. :-)
-gerel
Hi and welcome Vivek!!
Here is a link to a previous welcome email so we save some lines.
http://lists.gnu.org/archive/html/pdf-devel/2008-08/msg7.html
Of course, if you have any doubts, just ask. :-)
cheers
-gerel
ld be a new testcase (TCase)
file say, pdf-filter.c and reside in "torture/unit/base/stm/" with the rest.
Alternatively we could create a new file that would be executed by a Makefile
rule.
regards,
-gerel
1 - 100 of 330 matches
Mail list logo
