Re: [PATCH] New module rand48 [rebased]

On Wed, Oct 29, 2008 at 11:38 AM, Richard W.M. Jones <[EMAIL PROTECTED]>wrote: > > Updated with feedback from Ralf Wildenhues. > > Rich. > > -- > Richard Jones, Emerging Technologies, Red Hat > http://et.redhat.com/~rjones > virt-p2v converts physical machines to v

Re: Gauge interest in an XDR implementation

"Richard W.M. Jones" <[EMAIL PROTECTED]> writes: > I maintain portableXDR (http://et.redhat.com/~rjones/portablexdr/) > which is an XDR library for Windows and Macs. As far as I'm aware it > is only used by libvirt (http://libvirt.org/), and only on platforms > which lack any XDR library (ie. Win

Gauge interest in an XDR implementation

I maintain portableXDR (http://et.redhat.com/~rjones/portablexdr/) which is an XDR library for Windows and Macs. As far as I'm aware it is only used by libvirt (http://libvirt.org/), and only on platforms which lack any XDR library (ie. Windows) or a usable XDR library (Macs and other Unix systems

Re: [PATCH] New module rand48 [rebased]

Updated with feedback from Ralf Wildenhues. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjone

Re: [PATCH] New module rand48 [rebased]

Sorry, ignore this one. I realized that Ralf Wildenhues sent some feedback which I haven't incorporated. I'll post an updated patch in a moment. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/

Re: [PATCH] Implementations of random, srandom, initstate, setstate, rand, srand

"Richard W.M. Jones" <[EMAIL PROTECTED]> wrote: > On Wed, Oct 29, 2008 at 11:22:08AM +0100, Jim Meyering wrote: > [random, random_r, RAND_MAX] >> However, what if an application wants only random_r? >> We shouldn't require that they import all of the non-thread-safe >> functions, too, so I think ra

Re: [PATCH] Implementations of random, srandom, initstate, setstate, rand, srand

On Wed, Oct 29, 2008 at 11:22:08AM +0100, Jim Meyering wrote: [random, random_r, RAND_MAX] > However, what if an application wants only random_r? > We shouldn't require that they import all of the non-thread-safe > functions, too, so I think random really does belong separate. > Of course, it depen

Re: [PATCH] Implementations of random, srandom, initstate, setstate, rand, srand

"Richard W.M. Jones" <[EMAIL PROTECTED]> wrote: > This patch adds a 'random' module which implements: > > - random > - srandom > - initstate > - setstate > > and replaces: > > - rand > - srand > - RAND_MAX > > It depends on the 'random_r' module. > > random vs random_r > -

[PATCH] New module rand48 [rebased]

This is the module implementing the *rand48* functions, rebased to the current head. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging,

Re: multiple invocations of gnulib-tool

Simon Josefsson wrote: > I have tried variations of this before, but always ran into some > problem, e.g., the GPL module AC_REQUIRE some LGPL module that runs > AC_LIBOBJ or similar that fails in a split setup. That would be a bug in gnulib: An AC_REQUIREd macro is allowed only to set variables w

[PATCH] Implementations of random, srandom, initstate, setstate, rand, srand. [rebased]

This is rebased against the current head of gnulib. 'struct random_data' is now in gnulib, so I've removed the addition of this structure from the patch. This version also preserves the glibc locking code, albeit as empty macros, so that the code more closely follows what was originally in glibc.

Re: multiple invocations of gnulib-tool

Bruno Haible <[EMAIL PROTECTED]> writes: > This setup just won't work in the long run.(*) If you use multiple gnulib-tool > invocations, you also need multiple configure files. > > Two setups that will work are: > 1) Completely separate directories for the two gnulib-tool invocations, > Nei