> >BTW,
> >BIG THANKS to all the people out there who already worked on a Cygwin
> >port of aforementioned packages. A grep -il cygwin on the
> sources almost
> >always gave me a clue where to put my hands on for the Uwin port.
>
> I guess this is one of the benefits of open source
> developmen
> -Original Message-
> From: Randall R Schulz [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 22, 2002 4:08 PM
> To: Robert Collins; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: OT: possible project/research project -- ksh has
> it all and is now av
> -Original Message-
> From: Christopher Faylor [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 22, 2002 3:54 AM
>
> Can we take this discussion somewhere else? I don't really
> see how it relates to cygwin.
Sure. Given the apparent interest I was about to start looking for a
maili
Hi, Robert,
At 20:58 2002-03-21, Robert Collins wrote:
>Re:
>
>http://cygwin.com/ml/cygwin/2002-03/msg01270.html
>
>Right, I knew someone had to have thought along similar lines.
Umm... You rebuffed me when I pointed out it was not a new idea...
>I'm gonna' be a convert, I can tell.
Until an
Re:
http://cygwin.com/ml/cygwin/2002-03/msg01270.html
Right, I knew someone had to have thought along similar lines. I'm gonna
be a convert I can tell.
Rob
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation:
On Fri, Mar 22, 2002 at 04:15:27AM +0100, Karsten Fleischer wrote:
>> What happened to supplying this for the cygwin distribution?
>
>This is a release done by AT&T, I have nothing to do with it.
Ah. I should have realized this. Ok.
>I was waiting for their new source code to be released.
>I o
> What happened to supplying this for the cygwin distribution?
This is a release done by AT&T, I have nothing to do with it.
I was waiting for their new source code to be released.
I only noticed this discussion on the list and forwarded it to them.
As you will have noticed, they compiled with C
On Fri, Mar 22, 2002 at 02:39:10AM +0100, Karsten Fleischer wrote:
>ksh93 is capable of keeping specially prepared executables as builtins.
>Below is a copy of a mail I just got from the AT&T research labs with
>some comments on how to implement such things, and a link where you can
>download ksh9
Hi,
ksh93 is capable of keeping specially prepared executables as builtins.
Below is a copy of a mail I just got from the AT&T research labs with
some comments on how to implement such things, and a link where you can
download ksh93 source and binaries (yes, Cygwin binaries).
Please follow the in
On Thu, Mar 21, 2002 at 11:37:26PM +1100, Robert Collins wrote:
>
>
>> -Original Message-
>> From: Jesper Eskilson [mailto:[EMAIL PROTECTED]]
>> Sent: Thursday, March 21, 2002 11:27 PM
>> To: Robert Collins
>> Cc: [EMAIL PROTECTED]
>> Subject:
> -Original Message-
> From: Jesper Eskilson [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 21, 2002 11:27 PM
> To: Robert Collins
> Cc: [EMAIL PROTECTED]
> Subject: Re: OT: possible project/research project
>
>
> "Robert Collins" <[
"Robert Collins" <[EMAIL PROTECTED]> writes:
> make -j serialises at directory borders (at a minimum). You might like
> to review the 'recursive make considered harmful' paper (if you haven't
> already).
'make -j' and recursive make are orthogonal issues.
--
/Jesper
--
Unsubscribe info:
> -Original Message-
> From: Jesper Eskilson [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 21, 2002 4:52 PM
> To: [EMAIL PROTECTED]
> Subject: Re: OT: possible project/research project
>
>
> "Gary R. Van Sickle" <[EMAIL PROTECTED]> writes:
> -Original Message-
> From: Gary R. Van Sickle [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 21, 2002 2:32 PM
> The thing is, a lot of work *has* been done to make fork as
> efficient as possible. But there's a limit on how fast you
> can create a new process and duplicate the
> -Original Message-
> From: Gary R. Van Sickle [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 21, 2002 2:25 PM
> #1 is basically the same as what you propose, though I'm not
> sure I'm wild about the DLL idea; if everything's a builtin,
> why not just statically link?
Several r
"Gary R. Van Sickle" <[EMAIL PROTECTED]> writes:
> # Why should this...:
> rm //a/bunch/of/files/out/on/a/super/slow/server/*
> # ...block this:
> gcc hello.c
>
> Obviously you're never going to be able to take advatage of all
> non-dependencies, but as a wise man once told me, "you can't win if
> Gary,
>
> You labelled yourself a patriot.
I quoted the label of a beer bottle. Samuel Adams to be precise.
> I just pointed out some relevant wisdom.
Indeed. But not the relevant wisdom you thought you had.
> If you perceive that to be namecalling, so be it. It's the sort of baseless
> co
> The issue at hand though, is twofold:
> 1) Minimise the changes needed to make a proxy for a program. I.e.
> imagine if GCC and cc1plus.exe lived in-process. That would remove 2Mb
> of disk IO for each compile. However the _only_ chance of getting such a
> program proxied would be a minimalistic
> I would certainly agree with you about that, but the fact remains, a lot
> of code, that cygwin exists to ease the porting of, uses it. If the work
> was done on fork itself, it would help speed-up a lot more that just
> configure (or similar) scripts.
>
> Stephano Mariani
The thing is, a lot o
> Sir,
>
> We await your improved model for process control and the operating system
> that implements it.
>
Senor,
Well wait no longer! These days, by gosh, we got everything from spawns to
execs to named synchronization objects to... dare I say it?... yes, even
threads! Gone are the days whe
Just to get a little more off-topic...
> Don't forget this:
>
> "... this is the best of all possible worlds."
> -- Voltaire
Maybe this was a joke, but you *do* realize that this was taken from
a work of fiction? (_Candide_, which was a satire of Gottfried Wilhelm
Leibnitz' philosophy.) Leibn
Randall..
> -Original Message-
> From: Randall R Schulz [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 21, 2002 2:47 AM
> To: Robert Collins; [EMAIL PROTECTED]
> Subject: RE: OT: possible project/research project
> >No - sounds like you haven't been pa
On Wed, Mar 20, 2002 at 09:37:42AM -, Stephano Mariani wrote:
>I would certainly agree with you about that, but the fact remains, a
>lot of code, that cygwin exists to ease the porting of, uses it. If
>the work was done on fork itself, it would help speed-up a lot more
>that just configure (o
On Wed, Mar 20, 2002 at 06:04:44PM +1100, Robert Collins wrote:
>In fact cgf has had a copy-on-write fork() for cygwin in alpha-quality
>IIRC. I'd love to do some perf tests with that, and in fact on my todo
>list is cygwin profiling. Time however, is the killer.
This keeps coming up. Maybe it s
Rob,
More...
At 01:33 2002-03-20, Robert Collins wrote:
>Randall,
>responses inline..
>
> > -Original Message-
> > From: Randall R Schulz [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, March 20, 2002 7:34 PM
>
> > >Well we still have that basic separate - bash's builtin's
> > for examp
age-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf
> Of Gary R. Van Sickle
> Sent: Wednesday, 20 March 2002 2:52 AM
> To: [EMAIL PROTECTED]
> Subject: RE: OT: possible project/research project
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [m
Randall,
responses inline..
> -Original Message-
> From: Randall R Schulz [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 20, 2002 7:34 PM
> >Well we still have that basic separate - bash's builtin's
> for example.
> >If
> >it's not builtin, it needs a sub process.
>
> That's not
Robert,
Responses interposed below.
At 22:55 2002-03-19, Robert Collins wrote:
> > -Original Message-
> > From: Randall R Schulz [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, March 20, 2002 12:15 PM
>
> >
> > Robert,
> >
> > This idea isn't really new.
>
>I don't recall claiming it as
> -Original Message-
> From: Matthew Smith [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 20, 2002 11:46 AM
> To: Cygwin
> Subject: Re: OT: possible project/research project
>
>
> Robert:
>
> I'm not sure what I could do, but if you
> -Original Message-
> From: Gary R. Van Sickle [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 20, 2002 1:52 PM
>
> I don't see it that the source of the problem is the
> implementation of fork/vfork; the way I see it the very
> *concept* of forking makes little to no sense. I
> -Original Message-
> From: Stephano Mariani [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 20, 2002 12:34 PM
> To: 'Randall R Schulz'; Robert Collins; [EMAIL PROTECTED]
> Subject: RE: OT: possible project/research project
>
>
> I am no cyg
> -Original Message-
> From: Randall R Schulz [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 20, 2002 12:15 PM
>
> Robert,
>
> This idea isn't really new.
I don't recall claiming it as 'new' .. just an idea. :} (ok, pedant
mode off).
> The problem is that you're creating a hug
Sir,
We await your improved model for process control and the operating system
that implements it.
Randall Schulz
Mountain View, CA USA
Patriotism is the last refuge of a scoundrel.
-- Samuel Johnson
At 18:51 2002-03-19, Gary R. Van Sickle wrote:
>I don't see it that the source of the prob
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
> Of Stephano Mariani
> Sent: Tuesday, March 19, 2002 7:34 PM
> To: 'Randall R Schulz'; 'Robert Collins'; [EMAIL PROTECTED]
> Subject: RE: OT: possible project/resear
em is not being targeted.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf
> Of Randall R Schulz
> Sent: Wednesday, 20 March 2002 1:15 AM
> To: Robert Collins; [EMAIL PROTECTED]
> Subject: Re: OT: possible project/research project
>
>
Robert:
I'm not sure what I could do, but if you're willing to be the project
leader, and hand out work to do, I'd be more than happy to pitch in and
help. Sounds like you have a pretty good idea of what needs to be done.
cheers,
-Matt Smith
>I've not seen a specific project to accomplish
Robert,
This idea isn't really new. I remember people talking about it back in the
System 6, System 7 and 32v days, when programs were starting to get bigger,
disks were still pretty slow, main store rather small and there was not yet
a copy-on-write fork(2) or a vfork(2). (Not to mention the
Just a curiousity...
I've a mental concept I've been batting around for a while - about how can we
drastically increase configure and related script performance on cygwin...
AFAICT the largest performance issue is fork() and exec(). File access is quite fast,
as is networking. Unix sockets are
38 matches
Mail list logo
