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
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 mo
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 i
gt; 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 introduced the 'wchar' module,
> we effectively dropped support for this platform (on 2007-01-12 and
> 2007-01-16).
I don't know the answer to that, so I&#
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
rate compat.h. Improve unlocked I/O checkis.
* lib/Makefile.am, lib/Makefile.in, m4/gnulib-cache.m4,
m4/gnulib-comp.m4,
m4/stdarg.m4: Add stdarg module.
* snprintfv/Makefile.am (DISTCLEANFILES, pkginclude_HEADERS)
(nodist_pkginclude_HEADERS, noinst_HEADERS, nodist
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
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
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
. config.sub.
>
> If the right answer is just "use --add-missing", then should we delete
> the existing copy of libtool.m4 / ltmain.sh?
In fact, did you try building from this? :-) It won't configure,
because it wants snprintfv/printf.h, which is a generated file. I'll
ju
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
# d
; || mismatch
> that I have not had the time to understand. It passes the testsuite
> except for floating-point printing.
OK, thanks. I'll restart tonight or over the weekend.
> Still, as I said I fully agreed -- in fact my first step would have been
> to gnulib-ize snpr
t one as the basis for submission to
gnulib,
unless there is a consensus that Bruce's version is preferable for
some
reason. Either way, having a single flavour maintained outside of
both
smalltalk, autogen (and m4 eventually) is a big win all round.
OK, I'm starting from there. I
for submission to
> gnulib,
> unless there is a consensus that Bruce's version is preferable for some
> reason. Either way, having a single flavour maintained outside of both
> smalltalk, autogen (and m4 eventually) is a big win all round.
OK, I'm starting from there. I have
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 pri
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
s than ten millionths
> of one percent of disk space.
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.
Bruno
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"),
> -
Hi Gary,
> > OK Guys, shall we dust this "snprintfv" thing off, polish a bit and
> > hand off to the interested gnulib folks? :) It'd be nice to have it
> > have first class support. Heck, I'd like to see some of the add-on
> > interfaces made
28 matches
Mail list logo
