On Apr 14 19:24, Igor Peshansky wrote:
Hmm. Even now, one does not have to edit the registry to switch from
binary mode to text mode -- you just need to re-mount with the appropriate
option. I assume the same will hold for the /etc/fstab approach.
No, how should it? Of course you have to
On Apr 14 20:02, Brian Dessent wrote:
Christopher Faylor wrote:
Yes, I know. I just don't think it clarifies anything to put a Red
Hat in the registry.
I was thinking Cygwin would be better as well, but since it is
supposed to be a two-level heirarchy how about
On Apr 15 02:29, Brian Dessent wrote:
Corinna Vinschen wrote:
Having said that, should we really rename the registry keys, what do we
do with the Program Options and the two heap_foo values? Should
they be moved to the new registry key? If yes, should the postinstall
script I created
On Apr 15 02:48, Brian Dessent wrote:
Corinna Vinschen wrote:
They do? How and Why? Is that something which should be rather fixed
in newlib instead of in the autogen configuration?
The BSD implementation of funopen() doesn't explicitly define any types
for the cookie functions, but
Corinna Vinschen wrote:
Having said that, should we really rename the registry keys, what do we
do with the Program Options and the two heap_foo values? Should
they be moved to the new registry key? If yes, should the postinstall
script I created a couple of days ago also move them?
For
On Apr 15 11:31, Corinna Vinschen wrote:
On Apr 15 02:29, Brian Dessent wrote:
Corinna Vinschen wrote:
Having said that, should we really rename the registry keys, what do we
do with the Program Options and the two heap_foo values? Should
they be moved to the new registry key? If
First of all, I couldn't have said anything better than Brian did.
On Apr 14 20:37, Brian Dessent wrote:
For example I recently tracked
down a configure issue in autogen where it assumed the BSD signatures of
the types used with funopen(), which differ from the implementation in
newlib.
On Apr 15 10:55, Corinna Vinschen wrote:
On Apr 14 20:02, Brian Dessent wrote:
Christopher Faylor wrote:
Yes, I know. I just don't think it clarifies anything to put a Red
Hat in the registry.
I was thinking Cygwin would be better as well, but since it is
supposed to be a
Corinna Vinschen wrote:
I see. So what we have in newlib is how it's defined on Linux.
Howver, shouldn't autogen have the same problem on Linux then?
If not, any idea why?
I suppose it's because on linux, HAVE_FOPENCOOKIE would be set and this
code would be skipped. It was only when
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Corinna Vinschen on 4/15/2008 3:50 AM:
|
| I see. So what we have in newlib is how it's defined on Linux.
fopencookie matches Linux. Linux does not have funopen. I guess the
reason funopen disagrees with BSD is that BSD took a
On Apr 15 06:06, Eric Blake wrote:
Speaking of newlib stdio functions, shouldn't we go ahead and export
fopen_memstream and fmemopen, as those will be required by POSIX 200x (and
have a more standardized interface than either funopen or fopencookie)?
IIRC, you implemented it. Did I miss a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Corinna Vinschen on 4/15/2008 6:15 AM:
| On Apr 15 06:06, Eric Blake wrote:
| Speaking of newlib stdio functions, shouldn't we go ahead and export
| fopen_memstream and fmemopen, as those will be required by POSIX 200x (and
| have a more
Brian,
I just found that, regardless of my privileges, setup-1.7 defaults
to install for just me instead of all users while the standard
setup defaults to all users. Why does that happen?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project
On Tue, Apr 15, 2008 at 11:08:49AM +0200, Corinna Vinschen wrote:
On Apr 15 10:55, Corinna Vinschen wrote:
On Apr 14 20:02, Brian Dessent wrote:
Christopher Faylor wrote:
Yes, I know. I just don't think it clarifies anything to put a Red
Hat in the registry.
I was thinking Cygwin would be
On Mon, Apr 14, 2008 at 8:11 AM, Corinna Vinschen
[EMAIL PROTECTED] wrote:
Hi all,
we're now finally starting the release cycle for Cygwin 1.7. Not
everything is in it's place, some changes are still in flux and the
installation is still somewhat bumpy but we should get to all of that
On Apr 15 10:17, Christopher Faylor wrote:
On Tue, Apr 15, 2008 at 11:08:49AM +0200, Corinna Vinschen wrote:
Having said that, should we really rename the registry keys, what do we
do with the Program Options and the two heap_foo values?
I'd like to keep the Program Options and nuke the
2008/4/15, Corinna Vinschen:
On Apr 15 10:17, Christopher Faylor wrote:
I also object to using Red Hat as the owner [...]
Red Hat *is* the owner of the code, regardless of the registry key you
want to use. I know that you have mixed feelings about Red Hat,
however, assuming the code is
On Tue, Apr 15, 2008 at 05:44:00PM +0200, Corinna Vinschen wrote:
On Apr 15 10:17, Christopher Faylor wrote:
On Tue, Apr 15, 2008 at 11:08:49AM +0200, Corinna Vinschen wrote:
Having said that, should we really rename the registry keys, what do we
do with the Program Options and the two heap_foo
On Apr 15 13:59, Christopher Faylor wrote:
On Tue, Apr 15, 2008 at 05:44:00PM +0200, Corinna Vinschen wrote:
Red Hat *is* the owner of the code, regardless of the registry key you
want to use. I know that you have mixed feelings about Red Hat,
however, assuming the code is owned by the FSF,
Corinna Vinschen wrote:
I will not further argue against using Cygwin Project\Cygwin or
just Cygwin.
I guess the one name no one can strongly argue against is the one we're
using right now: perfect or outdated as it may be, it has at least
one reason to be (retro-compatibility).
PS: my
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Corinna Vinschen on 4/15/2008 12:38 PM:
|
| Since everybody else seems to dislike the company name in the registry
| key, I will not further argue against using Cygwin Project\Cygwin or
| just Cygwin.
I hate unnecessary spaces. Can we
Eric Blake wrote:
I hate unnecessary spaces. Can we go with Cygwin rather than Cygwin
Project, so that scripts using /proc/registry don't have to worry about
the space?
The only reason I suggested Cygwin Project\Cygwin is that it's
supposed to be a two level hierarchy, company\product,
Corinna Vinschen wrote:
I just found that, regardless of my privileges, setup-1.7 defaults
to install for just me instead of all users while the standard
setup defaults to all users. Why does that happen?
This is very odd. Setup's is_admin() was returning 0 despite the user
belonging to the
23 matches
Mail list logo
