I'd suggest leaving off the gnulib list during the porting phase, unless someone
not involved with snprintfv on that list says they want to follow the minutia of
this port. Seems like it would be mostly be noise to the full list. To me.
On 2/22/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
Doe
The existing snprintfv supports both use as a libtool convenience
library and installation as a separate standalone library. Since
we're merging this into gnulib, can we drop the standalone library?
Currently, the standalone library has the possibility to load additional
external modules. I
The existing snprintfv supports both use as a libtool convenience
library and installation as a separate standalone library. Since
we're merging this into gnulib, can we drop the standalone library?
I'm hoping to rely entirely on gnulib infrastructure (e.g. for
portability issues that libsnprin
On Sun, Feb 25, 2007 at 03:56:46PM +0100, Bruno Haible wrote:
> Daniel Jacobowitz wrote:
> > Paolo's updates added a check for runetype.h
> > in order to make Mac OS/X's work properly. Perhaps gnulib's
> > substitute wchar.h ought to handle that?
>
> For which version of Mac OS X was this? MacOS
Daniel Jacobowitz wrote:
> Paolo's updates added a check for runetype.h
> in order to make Mac OS/X's work properly. Perhaps gnulib's
> substitute wchar.h ought to handle that?
For which version of Mac OS X was this? MacOS X 10.3 has a working .
MacOS X 10.2 has no wchar.h at all. When gnulib in
Daniel Jacobowitz wrote:
> One of the items on my plate is figuring out the best way to
> regenerate the generated .h files after moving them to gnulib.
> One way would be at gnulib-tool time, another to have a separate
> script and keep updated copies checked in.
gnulib-tool so far has no options
Daniel Jacobowitz wrote:
> - I don't know how to make one gnulib module override another yet
There are two ways to achieve this, both in the area of the
package that uses gnulib. Say, you want override 'snprintf'
with 'snprintfv'.
a) Invoke "gnulib-tool --avoid=snprintf --import snprintfv".
or
b
On 2/23/07, Gary V. Vaughan <[EMAIL PROTECTED]> wrote:
Looks like you have a good plan for gnulib integration.
Date: Fri, 23 Feb 2007 10:03:35 -0800
Indeed. Welcome to California, Gary. :) - Bruce
Looks like you have a good plan for gnulib integration. I especially
like splitting out the other datatypes into independently useable
modules.
On 23 Feb 2007, at 04:36, Paolo Bonzini wrote:
I will work on gnulib-izing snprintfv first. Are there any
particular
platforms you would recommend c
On 2/23/07, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
One of the items on my plate is figuring out the best way to
regenerate the generated .h files after moving them to gnulib.
One way would be at gnulib-tool time, another to have a separate
script and keep updated copies checked in.
``gnul
I don't think I copied you on an email -- there is a bug fix and a
number of
warning fixes in my version that did not make it into the smalltalk
version.
I think some, at least, are in the libsnprintfv sources. I think it
will be
worth checking. (Paolo - I'm at work -- could you forward him m
Daniel,
I don't think I copied you on an email -- there is a bug fix and a number of
warning fixes in my version that did not make it into the smalltalk version.
I think some, at least, are in the libsnprintfv sources. I think it will be
worth checking. (Paolo - I'm at work -- could you forward
How should I initially configure this? It has a couple of support
files already (compile, ltmain.sh) but not in the build-aux directory
where it wants to find them, and not all of the necessary files
e.g. config.sub.
If the right answer is just "use --add-missing", then should we delete
the exis
On Fri, Feb 23, 2007 at 07:46:27AM -0500, Daniel Jacobowitz wrote:
> How should I initially configure this? It has a couple of support
> files already (compile, ltmain.sh) but not in the build-aux directory
> where it wants to find them, and not all of the necessary files
> e.g. config.sub.
>
> I
On Fri, Feb 23, 2007 at 08:22:45AM +0100, Paolo Bonzini wrote:
> I added you to the group to give you commit rights,
> https://savannah.nongnu.org/cvs/?group=libsnprintfv has the instructions
> for checking out the project. Is it ok if we use bug-gnulib@gnu.org,
> for the time being, to host pa
- The unlocked I/O module isn't actually what snprintfv wants. It
needs flockfile and unlocked-io.h defines that to nothing. All it
really wants is an autoconf check for unlocked IO.
Yes, the same thing that gnulib does in getdelim:
#if !HAVE_FLOCKFILE
# undef flockfile
# define flockfi
On Fri, Feb 23, 2007 at 08:22:45AM +0100, Paolo Bonzini wrote:
> Agreed. However, I'm sorry to say that you might have to restart part
> of your work. I've checked in into the libsnprintfv repository on
> savannah a merge of my work and Bruce's, except for the && || mismatch
> that I have not
On 22 Feb 2007, at 18:34, Daniel Jacobowitz wrote:
On Mon, Feb 19, 2007 at 11:42:59PM -0700, Gary V. Vaughan wrote:
My copy is in ftp://ftp.gnu.org/gnu/smalltalk/smalltalk-2.3.3.tar.gz
AFAIK, I have all the bugfixes from Gary and Bruce's stuff there.
Then we should probably take that one as
On Mon, Feb 19, 2007 at 11:42:59PM -0700, Gary V. Vaughan wrote:
> >My copy is in ftp://ftp.gnu.org/gnu/smalltalk/smalltalk-2.3.3.tar.gz
> >
> >AFAIK, I have all the bugfixes from Gary and Bruce's stuff there.
>
> Then we should probably take that one as the basis for submission to
> gnulib,
> u
On 19 Feb 2007, at 23:17, Paolo Bonzini wrote:
Yes it does. I'm not sure which is which now either. I remember
that
I did much of the work on a v2 release, and Paolo did something very
similar but we each did the work independently of the other.
There is
some reconciling to be done there
And how much of the L1 instruction cache? Intel's Pentium, Pentium Pro,
Pentium III, Celeron 1.7 GHz each have only 8 KB of it. Make one call to
snprintfv, and the cache is emptied. AMD64 has 64 KB of it; it's a bit better.
Let's talk L2 cache. I doubt glibc has a smaller printf, and anyway I
Yes it does. I'm not sure which is which now either. I remember that
I did much of the work on a v2 release, and Paolo did something very
similar but we each did the work independently of the other. There is
some reconciling to be done there too.
My copy is in ftp://ftp.gnu.org/gnu/smalltal
Bruce Korb wrote:
> > But I think the *printf replacements should continue to be based on the
> > vasnprintf code, because of object code size. On a Linux/x86 system:
>
> With typical new systems using 1GB ram and 150GB disk,
> we're talking 1/10 of the RAM and less than ten millionths
> of on
On 19 Feb 2007, at 20:29, Bruce Korb wrote:
Daniel Jacobowitz wrote:
On Mon, Feb 19, 2007 at 04:59:02PM -0700, Gary V. Vaughan wrote:
That sounds like a splendid idea! I'll even have some time to spend
on it starting next month.
I have some motivation to work on this, though no urgency.
E
Daniel Jacobowitz wrote:
> On Mon, Feb 19, 2007 at 04:59:02PM -0700, Gary V. Vaughan wrote:
>> That sounds like a splendid idea! I'll even have some time to spend
>> on it starting next month.
>
> I have some motivation to work on this, though no urgency. Especially
> if there's already code ava
Bruno Haible wrote:
> This would be welcome. The presence in gnulib offers for your library:
> - a tool for integration into other packages ("gnulib-tool --import
> snprintfv")
> and for standalone testing ("gnulib-tool --create-testdir snprintfv"),
> - some people who proofread the code a
26 matches
Mail list logo
