On Sep 6, 2011, at 10:21 PM, Martin S. Weber wrote:
> When adding a "-std=c89" to the generated Makefile with gcc as the compiler,
> I end up getting (ignoring the C++ style comment at line 87)
BTW, this code is guarded by #ifdef GCC, so I will build on C89-only compilers
(except for the C++-st
On Tue, Sep 06, 2011 at 05:19:23PM -0400, Ron Wilson wrote:
> On Tue, Sep 6, 2011 at 4:21 PM, Martin S. Weber wrote:
> > (and many, many, many, many more lines like that). This seems to be because
> > of the calls to asm() ... I don't know how to fix that. FYI, after
> > preprocessing, the first i
2011/9/7 Lluís Batlle i Rossell
> On Tue, Sep 06, 2011 at 06:16:23PM -0400, Ron Wilson wrote:
> > 2. Does C89 support inline functions?
>
> Not in the C code. Up to the compiler whether to make it inline or not.
> Declaring it static will give more chances to get it inline, I think.
>
c89 doesn'
On Sep 7, 2011, at 12:16 AM, Ron Wilson wrote:
> I guess I'm too used to dealing with dumb compilers.
>
> 1. Does it work with the C89 restrictions turned on?
Yes.
>
> 2. Does C89 support inline functions?
No. Plus, modern compilers ignore 'inline' keywords, and decide on their own
inlining
On Tue, Sep 06, 2011 at 06:16:23PM -0400, Ron Wilson wrote:
> I guess I'm too used to dealing with dumb compilers.
>
> 1. Does it work with the C89 restrictions turned on?
The code looks plain c89 to me.
> 2. Does C89 support inline functions?
Not in the C code. Up to the compiler whether to ma
I guess I'm too used to dealing with dumb compilers.
1. Does it work with the C89 restrictions turned on?
2. Does C89 support inline functions?
3. If not, will it handle the folowing correctly?
#define rotateLeft(x,n) { unsigned int t; t = x >> (SIZEOFINT -
n); x = (x << n) | t; } /* bitw
On Sep 6, 2011, at 11:19 PM, Ron Wilson wrote:
>
> The asm() calls are being used to invoke the rotate instructions. C
> does not have operators for peforming bitwise rotation of an operand
> and emulating a rotate using shifts is messy and very ineficient:
>
> unsigned int rotateLeft(unsigned in
On 09/06/11 17:19, Ron Wilson wrote:
On Tue, Sep 6, 2011 at 4:21 PM, Martin S. Weber wrote:
(and many, many, many, many more lines like that). This seems to be because
of the calls to asm() ... I don't know how to fix that. FYI, after
preprocessing, the first instruction of line 104 looks like:
On Tue, Sep 6, 2011 at 4:21 PM, Martin S. Weber wrote:
> (and many, many, many, many more lines like that). This seems to be because
> of the calls to asm() ... I don't know how to fix that. FYI, after
> preprocessing, the first instruction of line 104 looks like:
>
> qq[4]+=((qq[1]&(qq[2]^qq[3])
On Tue, Sep 06, 2011 at 04:21:43PM -0400, Martin S. Weber wrote:
> When adding a "-std=c89" to the generated Makefile with gcc as the
> compiler, I end up getting (ignoring the C++ style comment at line
> 87)
That was part of
http://fossil-scm.org/index.html/info/f2ede7da6d70851
I don't get that
Hi, all,
i've added a couple files to my local json fork of fossil and i've got a
question: the new files are in makemake.tcl, and they're built fine for
Make-based builds on Unix, but is there anything special i need to be doing
to get them added to the Windows/etc builds?
--
- stephan beal
2011/9/6 Lluís Batlle i Rossell
> In this case, I did not benchmark anything; and I started this work because
> a
> public fossil repository was hanging the linux serving it in a machine with
> 512MiB of RAM, due to the big leak in annotate. I had forgotten requiring
> anonymous login for the lin
Hi,
fossil currently does not build in a ANSI C-89 environment - a requirement of
the coding style guidelines ([1], point 16). There's an obvious build error in
http_ssl.c (C++ style comments), but there's something more in sha1.c...
When adding a "-std=c89" to the generated Makefile with gcc a
On Tue, Sep 06, 2011 at 09:45:46PM +0200, Stephan Beal wrote:
> 2011/9/5 Lluís Batlle i Rossell
>
> > Yesterday I achieved quite a working code, through the use of empty_blob
> > (to
> > overcome the assertion), changing some blob operations (solving some
> > leaks), and
> > freeing that allocate
2011/9/5 Lluís Batlle i Rossell
> Yesterday I achieved quite a working code, through the use of empty_blob
> (to
> overcome the assertion), changing some blob operations (solving some
> leaks), and
> freeing that allocated never freed.
>
Hi, Lluís!
A comment on your commit message:
[ef8266b710
On Tue, Sep 6, 2011 at 7:42 PM, Matt Welland wrote:
> I am continuing to test the limits of fossil and I've run into an
> interesting case where I can't merge. I'd like to know how I could recover
> from this. Note, this is from running the scripts (two in parallel) that I
> put at :http://chisel
I am continuing to test the limits of fossil and I've run into an
interesting case where I can't merge. I'd like to know how I could recover
from this. Note, this is from running the scripts (two in parallel) that I
put at :http://chiselapp.com/user/kiatoa/repository/testfossil with more and
larger
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/06/2011 11:33 AM, Remigiusz Modrzejewski wrote:
>
> On Sep 6, 2011, at 1:18 AM, Konstantin Khomoutov wrote:
>
>> The problem is while PDF is considered to be a binary file (and it
>> indeed usually contains compressed regions, it does contain ASC
On Sep 6, 2011, at 1:18 AM, Konstantin Khomoutov wrote:
> The problem is while PDF is considered to be a binary file (and it
> indeed usually contains compressed regions, it does contain ASCII header
> and footer (I think it's its PostScript heritage), so it can be
> considered to be a plain ASCI
19 matches
Mail list logo
