Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #61362 > unrolled thread
| Started by | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| First post | 2015-05-01 17:55 -0700 |
| Last post | 2015-05-03 10:58 -0700 |
| Articles | 20 on this page of 73 — 16 participants |
Back to article view | Back to comp.lang.c
Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-01 17:55 -0700
Re: Understandability Keith Thompson <kst-u@mib.org> - 2015-05-01 19:41 -0700
Re: Understandability wssimms@gmail.com - 2015-05-01 20:45 -0700
Re: Understandability Bartc <bc@freeuk.com> - 2015-05-02 10:38 +0100
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-02 09:15 -0700
Re: Understandability David Brown <david.brown@hesbynett.no> - 2015-05-04 09:26 +0200
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-04 12:52 -0700
Re: Understandability Noob <root@127.0.0.1> - 2015-05-02 14:21 +0200
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-02 09:13 -0700
Re: Understandability Ian Collins <ian-news@hotmail.com> - 2015-05-03 08:07 +1200
Re: Understandability Keith Thompson <kst-u@mib.org> - 2015-05-02 13:11 -0700
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-03 10:50 -0700
Re: Understandability Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-03 13:26 -0700
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-04 12:29 -0700
Re: Understandability Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-05 05:47 -0700
Re: Understandability raltbos@xs4all.nl (Richard Bos) - 2015-05-08 21:10 +0000
Re: Understandability Ian Collins <ian-news@hotmail.com> - 2015-05-09 09:17 +1200
Re: Understandability Keith Thompson <kst-u@mib.org> - 2015-05-08 14:32 -0700
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-09 09:13 -0700
Re: Understandability Keith Thompson <kst-u@mib.org> - 2015-05-09 16:48 -0700
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-10 11:05 -0700
Re: Understandability David Brown <david.brown@hesbynett.no> - 2015-05-11 08:48 +0200
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-11 09:55 -0700
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-11 17:52 -0400
Re: Understandability glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-11 22:54 +0000
Re: Understandability David Brown <david.brown@hesbynett.no> - 2015-05-12 08:49 +0200
Re: Understandability Morris Dovey <mrdovey@iedu.com> - 2015-05-12 02:15 -0500
Re: Understandability Phil Carmody <pc+usenet@asdf.org> - 2015-05-25 03:15 +0300
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-25 00:45 -0400
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-25 10:26 -0700
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-11 10:06 -0700
Re: Understandability David Brown <david.brown@hesbynett.no> - 2015-05-12 08:59 +0200
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-12 08:37 -0700
Re: Understandability David Brown <david.brown@hesbynett.no> - 2015-05-13 08:53 +0200
Re: Understandability Keith Thompson <kst-u@mib.org> - 2015-05-13 08:16 -0700
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-13 09:49 -0700
Re: Understandability Keith Thompson <kst-u@mib.org> - 2015-05-13 10:53 -0700
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-14 10:35 -0700
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-13 09:31 -0700
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-13 13:10 -0400
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-14 10:27 -0700
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-14 22:51 -0400
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-15 10:02 -0700
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-15 13:37 -0400
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-16 09:18 -0700
Re: Understandability David Brown <david.brown@hesbynett.no> - 2015-05-16 23:56 +0200
Re: Understandability gazelle@shell.xmission.com (Kenny McCormack) - 2015-05-17 12:45 +0000
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-17 09:16 -0700
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-17 12:47 -0400
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-18 10:54 -0700
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-18 15:00 -0400
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-19 09:49 -0700
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-19 13:10 -0400
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-16 19:01 -0400
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-17 09:30 -0700
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-17 12:58 -0400
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-18 10:54 -0700
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-18 14:56 -0400
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-19 09:46 -0700
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-19 13:16 -0400
Re: Understandability Richard Heathfield <rjh@cpax.org.uk> - 2015-05-19 18:23 +0100
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-19 14:02 -0400
Re: Understandability David Brown <david.brown@hesbynett.no> - 2015-05-19 00:11 +0200
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-18 18:28 -0400
Re: Understandability Keith Thompson <kst-u@mib.org> - 2015-05-15 10:52 -0700
Re: Understandability David Brown <david.brown@hesbynett.no> - 2015-05-13 21:53 +0200
Re: Understandability David Brown <david.brown@hesbynett.no> - 2015-05-09 16:18 +0200
Re: Understandability Noob <root@127.0.0.1> - 2015-05-09 18:31 +0200
Re: Understandability raltbos@xs4all.nl (Richard Bos) - 2015-05-17 10:44 +0000
Re: Understandability glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-17 15:53 +0000
Re: Understandability David Brown <david.brown@hesbynett.no> - 2015-05-04 09:15 +0200
Re: Understandability Waldek Hebisch <hebisch@math.uni.wroc.pl> - 2015-05-16 00:28 +0000
Re: Understandability Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-03 10:58 -0700
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-14 10:27 -0700 |
| Message-ID | <d1836c48-c7bb-4aac-ad37-2fa079968ed5@googlegroups.com> |
| In reply to | #61945 |
On Wednesday, May 13, 2015 at 10:10:14 AM UTC-7, James Kuyper wrote: > On 05/13/2015 12:31 PM, David Kleinecke wrote: > > On Tuesday, May 12, 2015 at 11:54:00 PM UTC-7, David Brown wrote: > ... > >> If I remember the history of this thread correctly (and perhaps I > >> remember /incorrectly/), the key objection was that you wrote "Gnu is > >> right to call their work a collection. It is really a fiction that gcc > >> is a free-standing program." You followed this with a series of > >> misconceptions about gcc and the way it works. > > What followed the "fiction" comment was: > > There are two parts - the front > > and back ends. The front end produces a "source program" in an > > intermediate language which the back end "assembles" into machine > > code. GNU, I believe, uses a Lisplike language called RTL. One way to > > make gcc a true program would be to make the back end a subroutine > > called at the end of front processing. A pipe might be a better idea. > > So those sentences presumably contain the misconceptions David was > talking about. > > > I protest once again. I believe I understand what gcc is doing. If you > > feel I have "misconceptions" please tell me what they are. It is possible > > I do have misconceptions. > > Two of the very first responses told you what Keith Thompson and David > Browne thought were misconceptions expressed in those sentences: > > On 05/02/2015 04:11 PM, Keith Thompson wrote: > > There are more than two. > ... > > I don't know a whole lot about gcc's internal workings, but I don't > > believe it writes its intermediate representation to a file. It does > > generate an assembly language program, but that's the output of the > > "back end". > > Your response to that message neither acknowledged nor disputed those > points, but only discussed other issues. > > On 05/04/2015 03:15 AM, David Brown wrote: > > Three parts - there is also the "middle end". (And the assembler and > > linker come in addition - they are normally from binutils rather than > gcc.) > ... > > Nope. The "front end" is specific to the source code language, such > > as C, C++, Fortran, etc. It produces an intermediate language > > (GIMPLE), which is passed on to the "middle end" where much of the > > optimisation work takes place. > > > > The middle-end is /mostly/ independent of both the back-end target and > > the front-end language, but there is a certain amount of cross-talk > > between the parts. (llvm has a similar theoretical structure, but has > > much cleaner separation between the parts.). The output from the > > middle-end is another intermediate language (RTL). > > > > The back-end handles the target-specific register allocation and code > > generation. The result is assembly, not machine code - an external > > assembler (usually "gas" from binutils) is called to generate the > > machine code. Then another external program (usually "ln" from > > binutils) is called to link the object code and static libraries into > > an executable. > > > > (Things are a little more complicated when using link-time > > optimisation, but lets skip that for now.) > ... > > Pipes /are/ the usual way of passing data and options between the > > passes inside gcc. Intermediary files are only stored if you ask for > > them (typically for debugging gcc itself). > > David's remarks received no response from anybody that I can see. > > Were either Keith or David wrong about the discrepancies between your > description and reality on those issues? None of the subsequent > discussion gave me that impression. It just wandered over into a > discussion of other issues. > -- > James Kuyper I didn't see any differences from what I said. Expansions - yes. But differences - no. I based my depiction of gcc on the Wikipedia article. Maybe I condensed it too much to make people happy.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-05-14 22:51 -0400 |
| Message-ID | <mj3mtf$at8$1@dont-email.me> |
| In reply to | #62007 |
On 05/14/2015 01:27 PM, David Kleinecke wrote: > On Wednesday, May 13, 2015 at 10:10:14 AM UTC-7, James Kuyper wrote: >> On 05/13/2015 12:31 PM, David Kleinecke wrote: >>> On Tuesday, May 12, 2015 at 11:54:00 PM UTC-7, David Brown wrote: >> ... >>>> If I remember the history of this thread correctly (and perhaps I >>>> remember /incorrectly/), the key objection was that you wrote "Gnu is >>>> right to call their work a collection. It is really a fiction that gcc >>>> is a free-standing program." You followed this with a series of >>>> misconceptions about gcc and the way it works. >> >> What followed the "fiction" comment was: >>> There are two parts - the front >>> and back ends. The front end produces a "source program" in an >>> intermediate language which the back end "assembles" into machine >>> code. GNU, I believe, uses a Lisplike language called RTL. One way to >>> make gcc a true program would be to make the back end a subroutine >>> called at the end of front processing. A pipe might be a better idea. >> >> So those sentences presumably contain the misconceptions David was >> talking about. >> >>> I protest once again. I believe I understand what gcc is doing. If you >>> feel I have "misconceptions" please tell me what they are. It is possible >>> I do have misconceptions. >> >> Two of the very first responses told you what Keith Thompson and David >> Browne thought were misconceptions expressed in those sentences: >> >> On 05/02/2015 04:11 PM, Keith Thompson wrote: >>> There are more than two. >> ... >>> I don't know a whole lot about gcc's internal workings, but I don't >>> believe it writes its intermediate representation to a file. It does >>> generate an assembly language program, but that's the output of the >>> "back end". >> >> Your response to that message neither acknowledged nor disputed those >> points, but only discussed other issues. >> >> On 05/04/2015 03:15 AM, David Brown wrote: >>> Three parts - there is also the "middle end". (And the assembler and >>> linker come in addition - they are normally from binutils rather than >> gcc.) >> ... >>> Nope. The "front end" is specific to the source code language, such >>> as C, C++, Fortran, etc. It produces an intermediate language >>> (GIMPLE), which is passed on to the "middle end" where much of the >>> optimisation work takes place. >>> >>> The middle-end is /mostly/ independent of both the back-end target and >>> the front-end language, but there is a certain amount of cross-talk >>> between the parts. (llvm has a similar theoretical structure, but has >>> much cleaner separation between the parts.). The output from the >>> middle-end is another intermediate language (RTL). >>> >>> The back-end handles the target-specific register allocation and code >>> generation. The result is assembly, not machine code - an external >>> assembler (usually "gas" from binutils) is called to generate the >>> machine code. Then another external program (usually "ln" from >>> binutils) is called to link the object code and static libraries into >>> an executable. >>> >>> (Things are a little more complicated when using link-time >>> optimisation, but lets skip that for now.) >> ... >>> Pipes /are/ the usual way of passing data and options between the >>> passes inside gcc. Intermediary files are only stored if you ask for >>> them (typically for debugging gcc itself). >> >> David's remarks received no response from anybody that I can see. >> >> Were either Keith or David wrong about the discrepancies between your >> description and reality on those issues? None of the subsequent >> discussion gave me that impression. It just wandered over into a >> discussion of other issues. >> -- >> James Kuyper > > I didn't see any differences from what I said. Expansions - yes. You said there were two parts; both Keith and David agreed that there were three parts. In a sense, that's "merely" an expansion - but it's also a difference, and in particular, it is a kind of difference that justifies describing your version as a misconception, if their version is correct. You said the output from the front end was in RTL; David says that it's GIMPLE. If he's correct, that also counts as a misconception on your part. You said that the output of the back end is machine code. David said that it's assembly code. If he's right, that also counts as a misconception on your part. Both of those two changes imply major differences in what kind of work the front and back ends do. You said that using a pipe would be a better idea; in context, that can only mean "a better idea than the way that gcc currently does it", which in turn implies that you thought that gcc doesn't use a pipe. Both Keith and David pointed out that it does use a pipe. If they're correct, that also counts as a misconception on your part. I said, repeatedly, "if ... correct", only because I can't confirm any of those points from personal knowledge - but I have no real reason to doubt either Keith or David on this matter. If those four misconceptions occurred in the context of a much larger discussion, they wouldn't matter much. However, those four points constitute a large fraction, possibly the majority, of the (mis)information contained in those sentences. > But > differences - no. I based my depiction of gcc on the Wikipedia article. > Maybe I condensed it too much to make people happy. I don't see how dropping the middle end, converting GIMPLE into RTL, changing assembly code to machine code, and implying that pipes are not used, when in fact they are, counts as "condensation". -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-15 10:02 -0700 |
| Message-ID | <1e157a01-0835-41e9-849b-40dab655173e@googlegroups.com> |
| In reply to | #62034 |
On Thursday, May 14, 2015 at 7:51:37 PM UTC-7, James Kuyper wrote: > On 05/14/2015 01:27 PM, David Kleinecke wrote: > > On Wednesday, May 13, 2015 at 10:10:14 AM UTC-7, James Kuyper wrote: > >> On 05/13/2015 12:31 PM, David Kleinecke wrote: > >>> On Tuesday, May 12, 2015 at 11:54:00 PM UTC-7, David Brown wrote: > >> ... > >>>> If I remember the history of this thread correctly (and perhaps I > >>>> remember /incorrectly/), the key objection was that you wrote "Gnu is > >>>> right to call their work a collection. It is really a fiction that gcc > >>>> is a free-standing program." You followed this with a series of > >>>> misconceptions about gcc and the way it works. > >> > >> What followed the "fiction" comment was: > >>> There are two parts - the front > >>> and back ends. The front end produces a "source program" in an > >>> intermediate language which the back end "assembles" into machine > >>> code. GNU, I believe, uses a Lisplike language called RTL. One way to > >>> make gcc a true program would be to make the back end a subroutine > >>> called at the end of front processing. A pipe might be a better idea. > >> > >> So those sentences presumably contain the misconceptions David was > >> talking about. > >> > >>> I protest once again. I believe I understand what gcc is doing. If you > >>> feel I have "misconceptions" please tell me what they are. It is possible > >>> I do have misconceptions. > >> > >> Two of the very first responses told you what Keith Thompson and David > >> Browne thought were misconceptions expressed in those sentences: > >> > >> On 05/02/2015 04:11 PM, Keith Thompson wrote: > >>> There are more than two. > >> ... > >>> I don't know a whole lot about gcc's internal workings, but I don't > >>> believe it writes its intermediate representation to a file. It does > >>> generate an assembly language program, but that's the output of the > >>> "back end". > >> > >> Your response to that message neither acknowledged nor disputed those > >> points, but only discussed other issues. > >> > >> On 05/04/2015 03:15 AM, David Brown wrote: > >>> Three parts - there is also the "middle end". (And the assembler and > >>> linker come in addition - they are normally from binutils rather than > >> gcc.) > >> ... > >>> Nope. The "front end" is specific to the source code language, such > >>> as C, C++, Fortran, etc. It produces an intermediate language > >>> (GIMPLE), which is passed on to the "middle end" where much of the > >>> optimisation work takes place. > >>> > >>> The middle-end is /mostly/ independent of both the back-end target and > >>> the front-end language, but there is a certain amount of cross-talk > >>> between the parts. (llvm has a similar theoretical structure, but has > >>> much cleaner separation between the parts.). The output from the > >>> middle-end is another intermediate language (RTL). > >>> > >>> The back-end handles the target-specific register allocation and code > >>> generation. The result is assembly, not machine code - an external > >>> assembler (usually "gas" from binutils) is called to generate the > >>> machine code. Then another external program (usually "ln" from > >>> binutils) is called to link the object code and static libraries into > >>> an executable. > >>> > >>> (Things are a little more complicated when using link-time > >>> optimisation, but lets skip that for now.) > >> ... > >>> Pipes /are/ the usual way of passing data and options between the > >>> passes inside gcc. Intermediary files are only stored if you ask for > >>> them (typically for debugging gcc itself). > >> > >> David's remarks received no response from anybody that I can see. > >> > >> Were either Keith or David wrong about the discrepancies between your > >> description and reality on those issues? None of the subsequent > >> discussion gave me that impression. It just wandered over into a > >> discussion of other issues. > >> -- > >> James Kuyper > > > > I didn't see any differences from what I said. Expansions - yes. > > You said there were two parts; both Keith and David agreed that there > were three parts. In a sense, that's "merely" an expansion - but it's > also a difference, and in particular, it is a kind of difference that > justifies describing your version as a misconception, if their version > is correct. > > You said the output from the front end was in RTL; David says that it's > GIMPLE. If he's correct, that also counts as a misconception on your part. > You said that the output of the back end is machine code. David said > that it's assembly code. If he's right, that also counts as a > misconception on your part. > Both of those two changes imply major differences in what kind of work > the front and back ends do. > You said that using a pipe would be a better idea; in context, that can > only mean "a better idea than the way that gcc currently does it", which > in turn implies that you thought that gcc doesn't use a pipe. Both Keith > and David pointed out that it does use a pipe. If they're correct, that > also counts as a misconception on your part. > I said, repeatedly, "if ... correct", only because I can't confirm any > of those points from personal knowledge - but I have no real reason to > doubt either Keith or David on this matter. > > If those four misconceptions occurred in the context of a much larger > discussion, they wouldn't matter much. However, those four points > constitute a large fraction, possibly the majority, of the > (mis)information contained in those sentences. > > > But > > differences - no. I based my depiction of gcc on the Wikipedia article. > > Maybe I condensed it too much to make people happy. > > I don't see how dropping the middle end, converting GIMPLE into RTL, > changing assembly code to machine code, and implying that pipes are not > used, when in fact they are, counts as "condensation". > -- > James Kuyper "Pipe" has a formal and an informal meaning. I intended it formally when I made that statement. I doubt that gcc uses formal pipes - but it surely pipes in the informal sense.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-05-15 13:37 -0400 |
| Message-ID | <55562EE4.3080202@verizon.net> |
| In reply to | #62050 |
On 05/15/2015 01:02 PM, David Kleinecke wrote: > On Thursday, May 14, 2015 at 7:51:37 PM UTC-7, James Kuyper wrote: >> On 05/14/2015 01:27 PM, David Kleinecke wrote: >>> On Wednesday, May 13, 2015 at 10:10:14 AM UTC-7, James Kuyper wrote: >>>> On 05/13/2015 12:31 PM, David Kleinecke wrote: ... >>>>> called at the end of front processing. A pipe might be a better idea. ... >>>> On 05/02/2015 04:11 PM, Keith Thompson wrote: ... >>>>> I don't know a whole lot about gcc's internal workings, but I don't >>>>> believe it writes its intermediate representation to a file. ... >>>> On 05/04/2015 03:15 AM, David Brown wrote: ... >>>>> Pipes /are/ the usual way of passing data and options between the >>>>> passes inside gcc. Intermediary files are only stored if you ask for >>>>> them (typically for debugging gcc itself). ... >> You said that using a pipe would be a better idea; in context, that can >> only mean "a better idea than the way that gcc currently does it", which >> in turn implies that you thought that gcc doesn't use a pipe. Both Keith >> and David pointed out that it does use a pipe. If they're correct, that >> also counts as a misconception on your part. ... > "Pipe" has a formal and an informal meaning. I intended it formally when > I made that statement. I doubt that gcc uses formal pipes - but it surely > pipes in the informal sense. Could you describe the distinction between those formal and informal meanings? I would assume, in context, that both Keith and David were referring to what, on typical Unix-like systems, results from using the "mkfifo" command or the "|" symbol at the command line, or the pipe() or popen() functions in C code. Those are four different ways of invoking the same feature of the operating system. Does that differ from your expectations?
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-16 09:18 -0700 |
| Message-ID | <89e6a413-a002-481f-a084-16b7c0d9213a@googlegroups.com> |
| In reply to | #62055 |
On Friday, May 15, 2015 at 10:37:48 AM UTC-7, James Kuyper wrote: > On 05/15/2015 01:02 PM, David Kleinecke wrote: > > On Thursday, May 14, 2015 at 7:51:37 PM UTC-7, James Kuyper wrote: > >> On 05/14/2015 01:27 PM, David Kleinecke wrote: > >>> On Wednesday, May 13, 2015 at 10:10:14 AM UTC-7, James Kuyper wrote: > >>>> On 05/13/2015 12:31 PM, David Kleinecke wrote: > ... > >>>>> called at the end of front processing. A pipe might be a better idea. > ... > >>>> On 05/02/2015 04:11 PM, Keith Thompson wrote: > ... > >>>>> I don't know a whole lot about gcc's internal workings, but I don't > >>>>> believe it writes its intermediate representation to a file. > ... > >>>> On 05/04/2015 03:15 AM, David Brown wrote: > ... > >>>>> Pipes /are/ the usual way of passing data and options between the > >>>>> passes inside gcc. Intermediary files are only stored if you ask for > >>>>> them (typically for debugging gcc itself). > ... > >> You said that using a pipe would be a better idea; in context, that can > >> only mean "a better idea than the way that gcc currently does it", which > >> in turn implies that you thought that gcc doesn't use a pipe. Both Keith > >> and David pointed out that it does use a pipe. If they're correct, that > >> also counts as a misconception on your part. > ... > > "Pipe" has a formal and an informal meaning. I intended it formally when > > I made that statement. I doubt that gcc uses formal pipes - but it surely > > pipes in the informal sense. > > Could you describe the distinction between those formal and informal > meanings? I would assume, in context, that both Keith and David were > referring to what, on typical Unix-like systems, results from using the > "mkfifo" command or the "|" symbol at the command line, or the pipe() or > popen() functions in C code. Those are four different ways of invoking > the same feature of the operating system. Does that differ from your > expectations? These are all examples of what I called formal pipes. Informal pipes involve situations where one piece of code gets data from another by (usually) next_token or the like calls. I call these pull pipes. There are also push pipes where one code piece sends data along by a handle_token call. The practical effect of both kinds of pipes is the same.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-05-16 23:56 +0200 |
| Message-ID | <mj8ebo$v1t$1@dont-email.me> |
| In reply to | #62118 |
On 16/05/15 18:18, David Kleinecke wrote: > On Friday, May 15, 2015 at 10:37:48 AM UTC-7, James Kuyper wrote: >> On 05/15/2015 01:02 PM, David Kleinecke wrote: >>> On Thursday, May 14, 2015 at 7:51:37 PM UTC-7, James Kuyper wrote: >>>> On 05/14/2015 01:27 PM, David Kleinecke wrote: >>>>> On Wednesday, May 13, 2015 at 10:10:14 AM UTC-7, James Kuyper wrote: >>>>>> On 05/13/2015 12:31 PM, David Kleinecke wrote: >> ... >>>>>>> called at the end of front processing. A pipe might be a better idea. >> ... >>>>>> On 05/02/2015 04:11 PM, Keith Thompson wrote: >> ... >>>>>>> I don't know a whole lot about gcc's internal workings, but I don't >>>>>>> believe it writes its intermediate representation to a file. >> ... >>>>>> On 05/04/2015 03:15 AM, David Brown wrote: >> ... >>>>>>> Pipes /are/ the usual way of passing data and options between the >>>>>>> passes inside gcc. Intermediary files are only stored if you ask for >>>>>>> them (typically for debugging gcc itself). >> ... >>>> You said that using a pipe would be a better idea; in context, that can >>>> only mean "a better idea than the way that gcc currently does it", which >>>> in turn implies that you thought that gcc doesn't use a pipe. Both Keith >>>> and David pointed out that it does use a pipe. If they're correct, that >>>> also counts as a misconception on your part. >> ... >>> "Pipe" has a formal and an informal meaning. I intended it formally when >>> I made that statement. I doubt that gcc uses formal pipes - but it surely >>> pipes in the informal sense. >> >> Could you describe the distinction between those formal and informal >> meanings? I would assume, in context, that both Keith and David were >> referring to what, on typical Unix-like systems, results from using the >> "mkfifo" command or the "|" symbol at the command line, or the pipe() or >> popen() functions in C code. Those are four different ways of invoking >> the same feature of the operating system. Does that differ from your >> expectations? > > These are all examples of what I called formal pipes. Those are the only "pipes" anyone else was considering - and those are the pipes gcc uses if you pass it the "-pipe" command line, or build it with the "--use-gcc-pipe" option (which is not uncommon, especially on Windows systems where it can make a big difference. On *nix systems, temporary files are almost as fast as pipes). There is nothing wrong with ignorance - it is easily fixed by a bit of reading, or asking some questions. But please stop posting guesses and incorrect assumptions with such apparent self-conviction. People might read your posts, now or as archives, and mistakenly believe you know what you are talking about! > Informal pipes > involve situations where one piece of code gets data from another by > (usually) next_token or the like calls. I call these pull pipes. There > are also push pipes where one code piece sends data along by a > handle_token call. That would not be a "pipe", because "pipe" has a very clear and specific meaning for *nix (and Windows, and many other systems). You could call them "information channels" if you like. A critical difference is that a pipe is normally used as a method of communication between two separate processes, while what you are describing is just moving data around within a single process. > > The practical effect of both kinds of pipes is the same. > No, they are totally different.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2015-05-17 12:45 +0000 |
| Message-ID | <mja2gk$b1u$2@news.xmission.com> |
| In reply to | #62130 |
In article <mj8ebo$v1t$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
...
>> The practical effect of both kinds of pipes is the same.
>
>No, they are totally different.
You two (David & David) need to get a room and work this thing out.
--
The scent of awk programmers is a lot more attractive to women than
the scent of perl programmers.
(Mike Brennan, quoted in the "GAWK" manual)
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-17 09:16 -0700 |
| Message-ID | <869117f2-65ef-4de9-82a5-01d75b6a46f7@googlegroups.com> |
| In reply to | #62130 |
On Saturday, May 16, 2015 at 2:56:20 PM UTC-7, David Brown wrote: > On 16/05/15 18:18, David Kleinecke wrote: > > On Friday, May 15, 2015 at 10:37:48 AM UTC-7, James Kuyper wrote: > >> On 05/15/2015 01:02 PM, David Kleinecke wrote: > >>> On Thursday, May 14, 2015 at 7:51:37 PM UTC-7, James Kuyper wrote: > >>>> On 05/14/2015 01:27 PM, David Kleinecke wrote: > >>>>> On Wednesday, May 13, 2015 at 10:10:14 AM UTC-7, James Kuyper wrote: > >>>>>> On 05/13/2015 12:31 PM, David Kleinecke wrote: > >> ... > >>>>>>> called at the end of front processing. A pipe might be a better idea. > >> ... > >>>>>> On 05/02/2015 04:11 PM, Keith Thompson wrote: > >> ... > >>>>>>> I don't know a whole lot about gcc's internal workings, but I don't > >>>>>>> believe it writes its intermediate representation to a file. > >> ... > >>>>>> On 05/04/2015 03:15 AM, David Brown wrote: > >> ... > >>>>>>> Pipes /are/ the usual way of passing data and options between the > >>>>>>> passes inside gcc. Intermediary files are only stored if you ask for > >>>>>>> them (typically for debugging gcc itself). > >> ... > >>>> You said that using a pipe would be a better idea; in context, that can > >>>> only mean "a better idea than the way that gcc currently does it", which > >>>> in turn implies that you thought that gcc doesn't use a pipe. Both Keith > >>>> and David pointed out that it does use a pipe. If they're correct, that > >>>> also counts as a misconception on your part. > >> ... > >>> "Pipe" has a formal and an informal meaning. I intended it formally when > >>> I made that statement. I doubt that gcc uses formal pipes - but it surely > >>> pipes in the informal sense. > >> > >> Could you describe the distinction between those formal and informal > >> meanings? I would assume, in context, that both Keith and David were > >> referring to what, on typical Unix-like systems, results from using the > >> "mkfifo" command or the "|" symbol at the command line, or the pipe() or > >> popen() functions in C code. Those are four different ways of invoking > >> the same feature of the operating system. Does that differ from your > >> expectations? > > > > These are all examples of what I called formal pipes. > > Those are the only "pipes" anyone else was considering - and those are > the pipes gcc uses if you pass it the "-pipe" command line, or build it > with the "--use-gcc-pipe" option (which is not uncommon, especially on > Windows systems where it can make a big difference. On *nix systems, > temporary files are almost as fast as pipes). > > There is nothing wrong with ignorance - it is easily fixed by a bit of > reading, or asking some questions. But please stop posting guesses and > incorrect assumptions with such apparent self-conviction. People might > read your posts, now or as archives, and mistakenly believe you know > what you are talking about! > > > Informal pipes > > involve situations where one piece of code gets data from another by > > (usually) next_token or the like calls. I call these pull pipes. There > > are also push pipes where one code piece sends data along by a > > handle_token call. > > That would not be a "pipe", because "pipe" has a very clear and specific > meaning for *nix (and Windows, and many other systems). You could call > them "information channels" if you like. > > A critical difference is that a pipe is normally used as a method of > communication between two separate processes, while what you are > describing is just moving data around within a single process. > > > > > The practical effect of both kinds of pipes is the same. > > > > No, they are totally different. There is not much I an say except I think you are wrong - especially about the practical effect.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-05-17 12:47 -0400 |
| Message-ID | <mjagka$4v4$1@dont-email.me> |
| In reply to | #62174 |
On 05/17/2015 12:16 PM, David Kleinecke wrote: > On Saturday, May 16, 2015 at 2:56:20 PM UTC-7, David Brown wrote: >> On 16/05/15 18:18, David Kleinecke wrote: ... >>> Informal pipes >>> involve situations where one piece of code gets data from another by >>> (usually) next_token or the like calls. I call these pull pipes. There >>> are also push pipes where one code piece sends data along by a >>> handle_token call. ... >> A critical difference is that a pipe is normally used as a method of >> communication between two separate processes, while what you are >> describing is just moving data around within a single process. >> >>> >>> The practical effect of both kinds of pipes is the same. >>> >> >> No, they are totally different. > > There is not much I an say except I think you are wrong - especially > about the practical effect. OK - then how would you go about using informal pipes rather than formal pipes to achieve practically the same effect as: file * | grep text | cut -f1 -d: -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-18 10:54 -0700 |
| Message-ID | <1b3c16ae-907e-41cf-a5d9-2976068a6823@googlegroups.com> |
| In reply to | #62179 |
On Sunday, May 17, 2015 at 9:47:17 AM UTC-7, James Kuyper wrote:
> On 05/17/2015 12:16 PM, David Kleinecke wrote:
> > On Saturday, May 16, 2015 at 2:56:20 PM UTC-7, David Brown wrote:
> >> On 16/05/15 18:18, David Kleinecke wrote:
> ...
> >>> Informal pipes
> >>> involve situations where one piece of code gets data from another by
> >>> (usually) next_token or the like calls. I call these pull pipes. There
> >>> are also push pipes where one code piece sends data along by a
> >>> handle_token call.
> ...
> >> A critical difference is that a pipe is normally used as a method of
> >> communication between two separate processes, while what you are
> >> describing is just moving data around within a single process.
> >>
> >>>
> >>> The practical effect of both kinds of pipes is the same.
> >>>
> >>
> >> No, they are totally different.
> >
> > There is not much I an say except I think you are wrong - especially
> > about the practical effect.
>
> OK - then how would you go about using informal pipes rather than formal
> pipes to achieve practically the same effect as:
>
> file * | grep text | cut -f1 -d:
> --
> James Kuyper
I could, at least in theory, rewrite grep and the others in the form of
informal pipes and get the same result. But why bother when formal pipes
can be used.
I could write a C compiler so that to execute it I use
tokenizer | pre-processor | parser | ...
but I don't need tokenizer, pre-processor, parser ... as free-standing
tool so why bother.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-05-18 15:00 -0400 |
| Message-ID | <555A36DD.3040704@verizon.net> |
| In reply to | #62230 |
On 05/18/2015 01:54 PM, David Kleinecke wrote: > On Sunday, May 17, 2015 at 9:47:17 AM UTC-7, James Kuyper wrote: >> On 05/17/2015 12:16 PM, David Kleinecke wrote: >>> On Saturday, May 16, 2015 at 2:56:20 PM UTC-7, David Brown wrote: >>>> On 16/05/15 18:18, David Kleinecke wrote: ... >>>>> The practical effect of both kinds of pipes is the same. >>>>> >>>> >>>> No, they are totally different. >>> >>> There is not much I an say except I think you are wrong - especially >>> about the practical effect. >> >> OK - then how would you go about using informal pipes rather than formal >> pipes to achieve practically the same effect as: >> >> file * | grep text | cut -f1 -d: ... > I could, at least in theory, rewrite grep and the others in the form of > informal pipes ... Having to re-write code that isn't even mine to modify is NOT an example of a "practical effect" that is "the same". > ... and get the same result. But why bother when formal pipes > can be used. You shouldn't: because what you call "formal pipes" provides a "practical effect" which is NOT provided by what you call "informal pipes". It is therefore a counter-example to your claim that they have the same practical effect.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-19 09:49 -0700 |
| Message-ID | <084184a5-99e0-43ba-a744-4f54619383f1@googlegroups.com> |
| In reply to | #62241 |
On Monday, May 18, 2015 at 12:00:54 PM UTC-7, James Kuyper wrote: > > Having to re-write code that isn't even mine to modify is NOT an example > of a "practical effect" that is "the same". Why not? I wouldn't heistate to rewrite anybody else's code if there was a valid reason. There is no valid reason here. It's just a what-if.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-05-19 13:10 -0400 |
| Message-ID | <555B6E99.4040605@verizon.net> |
| In reply to | #62301 |
On 05/19/2015 12:49 PM, David Kleinecke wrote: > On Monday, May 18, 2015 at 12:00:54 PM UTC-7, James Kuyper wrote: >> >> Having to re-write code that isn't even mine to modify is NOT an example >> of a "practical effect" that is "the same". > > Why not? Because "practical", as I understand it, always allows for consideration of the amount of work that needs to be done. The amount of work needed to use what you call "formal pipes" to do file * | grep text | cut -f1 -d: is enormously less than the work needed to find source code for "file", "grep", and "cut", understand the design of those programs well enough to figure out how to merge all three into a single process so they can use "informal pipes", and then building the combined program. That strikes me as extremely impractical, and I can't understand how you could even dream that the practical effect was the same. > I wouldn't heistate to rewrite anybody else's code if there was a valid > reason. There is no valid reason here. It's just a what-if. There's no valid reason because what you call "formal pipes" is a far better way to deal with the problem, making them NOT have the same "practical effect".
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-05-16 19:01 -0400 |
| Message-ID | <mj8i5u$ejc$1@dont-email.me> |
| In reply to | #62118 |
On 05/16/2015 12:18 PM, David Kleinecke wrote: > On Friday, May 15, 2015 at 10:37:48 AM UTC-7, James Kuyper wrote: ... >> Could you describe the distinction between those formal and informal >> meanings? I would assume, in context, that both Keith and David were >> referring to what, on typical Unix-like systems, results from using the >> "mkfifo" command or the "|" symbol at the command line, or the pipe() or >> popen() functions in C code. Those are four different ways of invoking >> the same feature of the operating system. Does that differ from your >> expectations? > > These are all examples of what I called formal pipes. Informal pipes > involve situations where one piece of code gets data from another by > (usually) next_token or the like calls. I call these pull pipes. There > are also push pipes where one code piece sends data along by a > handle_token call. Could you identify the context in which next_token and handle_token apply (just like I did above, when I said "typical Unix-like system", "command line", and "functions in C code")? On my desktop machine, the 'man' command gives me nothing for either of those names. A google search gives me too many hits, none of them obviously the one you were talking about. > The practical effect of both kinds of pipes is the same. David Brown does recognize the token routines you are talking about, and says they can only be used for intra-process communication, whereas pipes can also be used for inter-process communication. If he's right, that's a huge difference, given that almost all uses of pipes that I'm familiar with are for inter-process communication. I've seen pipes used for intra-process communication, but it was merely a neat trick, not something that was actually reasonable to do. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-17 09:30 -0700 |
| Message-ID | <36df77da-254f-4c25-941f-b5e27fb296a2@googlegroups.com> |
| In reply to | #62135 |
On Saturday, May 16, 2015 at 4:01:29 PM UTC-7, James Kuyper wrote: > On 05/16/2015 12:18 PM, David Kleinecke wrote: > > On Friday, May 15, 2015 at 10:37:48 AM UTC-7, James Kuyper wrote: > ... > >> Could you describe the distinction between those formal and informal > >> meanings? I would assume, in context, that both Keith and David were > >> referring to what, on typical Unix-like systems, results from using the > >> "mkfifo" command or the "|" symbol at the command line, or the pipe() or > >> popen() functions in C code. Those are four different ways of invoking > >> the same feature of the operating system. Does that differ from your > >> expectations? > > > > These are all examples of what I called formal pipes. Informal pipes > > involve situations where one piece of code gets data from another by > > (usually) next_token or the like calls. I call these pull pipes. There > > are also push pipes where one code piece sends data along by a > > handle_token call. > > Could you identify the context in which next_token and handle_token > apply (just like I did above, when I said "typical Unix-like system", > "command line", and "functions in C code")? On my desktop machine, the > 'man' command gives me nothing for either of those names. A google > search gives me too many hits, none of them obviously the one you were > talking about. > > > The practical effect of both kinds of pipes is the same. > > David Brown does recognize the token routines you are talking about, and > says they can only be used for intra-process communication, whereas > pipes can also be used for inter-process communication. If he's right, > that's a huge difference, given that almost all uses of pipes that I'm > familiar with are for inter-process communication. I've seen pipes used > for intra-process communication, but it was merely a neat trick, not > something that was actually reasonable to do. > -- > James Kuyper You are the captives of the jargon. I don't hesitate to deviate when I need new terms - I called my "new" terms "informal pipes" because they are not the formal kind used in the jargon. They are, if you will, a coding pattern. Given C (any version) there is a preprocessor and what I have been calling a parser. It is quite possible (and has been done) to write a stand alone pre-processor. And a stand alone parser (that doesn't recognize pre-processor statements). Then formally pipe the output of the pre-processor into the parser. (I ignore tokenization.) But it is better to pipe it informally by having the parser call next_token and the pre-processor part fo the code then returns the next token. This is what I could have called "the informal piping pattern".
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-05-17 12:58 -0400 |
| Message-ID | <mjahad$7ab$1@dont-email.me> |
| In reply to | #62175 |
On 05/17/2015 12:30 PM, David Kleinecke wrote: > On Saturday, May 16, 2015 at 4:01:29 PM UTC-7, James Kuyper wrote: >> On 05/16/2015 12:18 PM, David Kleinecke wrote: ... >>> The practical effect of both kinds of pipes is the same. >> >> David Brown does recognize the token routines you are talking about, and >> says they can only be used for intra-process communication, whereas >> pipes can also be used for inter-process communication. If he's right, >> that's a huge difference, given that almost all uses of pipes that I'm >> familiar with are for inter-process communication. I've seen pipes used >> for intra-process communication, but it was merely a neat trick, not >> something that was actually reasonable to do. >> -- >> James Kuyper > > You are the captives of the jargon. ... Feel free to replace all occurrences of "pipes" in the above paragraph with your jargon, "formal pipes". As far as I understand, the replacement would leave the meaning unchanged - and it's a meaning that your "response" is not responsive to. > ... I don't hesitate to deviate when I > need new terms - I called my "new" terms "informal pipes" because they > are not the formal kind used in the jargon. They are, if you will, a > coding pattern. > > Given C (any version) there is a preprocessor and what I have been > calling a parser. It is quite possible (and has been done) to write a > stand alone pre-processor. And a stand alone parser (that doesn't > recognize pre-processor statements). Then formally pipe the output of > the pre-processor into the parser. (I ignore tokenization.) But it > is better to pipe it informally by having the parser call next_token > and the pre-processor part fo the code then returns the next token. > This is what I could have called "the informal piping pattern". That doesn't really address the issue I was raising. You said that the practical effect of formal and informal pipes was the same. For me, one of the most important practical effects of what you call "formal" pipes is that they allow me to connect stand-alone processes that were not specifically designed to be connected to each other, without needing to re-write their code or recompile it. If David Brown's comments are correct (a point you've declined to comment on), the most important (to me, at least) practical effect of what you call "formal" pipes is something that can't be done at all by what you call "informal" pipes. Is that or is that not the case? -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-18 10:54 -0700 |
| Message-ID | <4e3fe37a-e46d-493e-824a-0cca44e9cc01@googlegroups.com> |
| In reply to | #62180 |
On Sunday, May 17, 2015 at 9:59:04 AM UTC-7, James Kuyper wrote: > On 05/17/2015 12:30 PM, David Kleinecke wrote: > > On Saturday, May 16, 2015 at 4:01:29 PM UTC-7, James Kuyper wrote: > >> On 05/16/2015 12:18 PM, David Kleinecke wrote: > ... > >>> The practical effect of both kinds of pipes is the same. > >> > >> David Brown does recognize the token routines you are talking about, and > >> says they can only be used for intra-process communication, whereas > >> pipes can also be used for inter-process communication. If he's right, > >> that's a huge difference, given that almost all uses of pipes that I'm > >> familiar with are for inter-process communication. I've seen pipes used > >> for intra-process communication, but it was merely a neat trick, not > >> something that was actually reasonable to do. > >> -- > >> James Kuyper > > > > You are the captives of the jargon. ... > > Feel free to replace all occurrences of "pipes" in the above paragraph > with your jargon, "formal pipes". As far as I understand, the > replacement would leave the meaning unchanged - and it's a meaning that > your "response" is not responsive to. > > > ... I don't hesitate to deviate when I > > need new terms - I called my "new" terms "informal pipes" because they > > are not the formal kind used in the jargon. They are, if you will, a > > coding pattern. > > > > Given C (any version) there is a preprocessor and what I have been > > calling a parser. It is quite possible (and has been done) to write a > > stand alone pre-processor. And a stand alone parser (that doesn't > > recognize pre-processor statements). Then formally pipe the output of > > the pre-processor into the parser. (I ignore tokenization.) But it > > is better to pipe it informally by having the parser call next_token > > and the pre-processor part fo the code then returns the next token. > > This is what I could have called "the informal piping pattern". > > That doesn't really address the issue I was raising. You said that the > practical effect of formal and informal pipes was the same. For me, one > of the most important practical effects of what you call "formal" pipes > is that they allow me to connect stand-alone processes that were not > specifically designed to be connected to each other, without needing to > re-write their code or recompile it. If David Brown's comments are > correct (a point you've declined to comment on), the most important (to > me, at least) practical effect of what you call "formal" pipes is > something that can't be done at all by what you call "informal" pipes. > Is that or is that not the case? > > > -- > James Kuyper I didn't see anything in DB's comment that needed a comment. If any comment is needed I think I have made it in replies to you.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-05-18 14:56 -0400 |
| Message-ID | <555A35FA.4050205@verizon.net> |
| In reply to | #62229 |
On 05/18/2015 01:54 PM, David Kleinecke wrote: > On Sunday, May 17, 2015 at 9:59:04 AM UTC-7, James Kuyper wrote: >> On 05/17/2015 12:30 PM, David Kleinecke wrote: >>> On Saturday, May 16, 2015 at 4:01:29 PM UTC-7, James Kuyper wrote: >>>> On 05/16/2015 12:18 PM, David Kleinecke wrote: >> ... >>>>> The practical effect of both kinds of pipes is the same. >>>> >>>> David Brown does recognize the token routines you are talking about, and >>>> says they can only be used for intra-process communication, whereas >>>> pipes can also be used for inter-process communication. If he's right, >>>> that's a huge difference, given that almost all uses of pipes that I'm >>>> familiar with are for inter-process communication. I've seen pipes used >>>> for intra-process communication, but it was merely a neat trick, not >>>> something that was actually reasonable to do. ... >> That doesn't really address the issue I was raising. You said that the >> practical effect of formal and informal pipes was the same. For me, one >> of the most important practical effects of what you call "formal" pipes >> is that they allow me to connect stand-alone processes that were not >> specifically designed to be connected to each other, without needing to >> re-write their code or recompile it. If David Brown's comments are >> correct (a point you've declined to comment on), the most important (to >> me, at least) practical effect of what you call "formal" pipes is >> something that can't be done at all by what you call "informal" pipes. >> Is that or is that not the case? ... > I didn't see anything in DB's comment that needed a comment. If any > comment is needed I think I have made it in replies to you. Your claim that "The practical effect of both kinds of pipes is the same" is inconsistent with David's claim that "what you are describing is just moving data around within a single process". I expected you to either make a comment that he was wrong about his claim, or an admission that you were wrong about your claim. A third alternative would be an explanation why you believe that the uselessness of "informal pipes" for inter-process communication (which is the main use I'm aware of for "formal pipes") fails to render your claim invalid. Would you care to provide one of those three alternatives? Or suggest a fourth?
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-19 09:46 -0700 |
| Message-ID | <7fae8b4b-66b3-4e31-966c-8455b719bf7f@googlegroups.com> |
| In reply to | #62240 |
On Monday, May 18, 2015 at 11:57:06 AM UTC-7, James Kuyper wrote: > On 05/18/2015 01:54 PM, David Kleinecke wrote: > > On Sunday, May 17, 2015 at 9:59:04 AM UTC-7, James Kuyper wrote: > >> On 05/17/2015 12:30 PM, David Kleinecke wrote: > >>> On Saturday, May 16, 2015 at 4:01:29 PM UTC-7, James Kuyper wrote: > >>>> On 05/16/2015 12:18 PM, David Kleinecke wrote: > >> ... > >>>>> The practical effect of both kinds of pipes is the same. > >>>> > >>>> David Brown does recognize the token routines you are talking about, and > >>>> says they can only be used for intra-process communication, whereas > >>>> pipes can also be used for inter-process communication. If he's right, > >>>> that's a huge difference, given that almost all uses of pipes that I'm > >>>> familiar with are for inter-process communication. I've seen pipes used > >>>> for intra-process communication, but it was merely a neat trick, not > >>>> something that was actually reasonable to do. > ... > >> That doesn't really address the issue I was raising. You said that the > >> practical effect of formal and informal pipes was the same. For me, one > >> of the most important practical effects of what you call "formal" pipes > >> is that they allow me to connect stand-alone processes that were not > >> specifically designed to be connected to each other, without needing to > >> re-write their code or recompile it. If David Brown's comments are > >> correct (a point you've declined to comment on), the most important (to > >> me, at least) practical effect of what you call "formal" pipes is > >> something that can't be done at all by what you call "informal" pipes. > >> Is that or is that not the case? > ... > > I didn't see anything in DB's comment that needed a comment. If any > > comment is needed I think I have made it in replies to you. > > Your claim that "The practical effect of both kinds of pipes is the > same" is inconsistent with David's claim that "what you are > describing is just moving data around within a single process". > I expected you to either make a comment that he was wrong about his claim, > or an admission that you were wrong about your claim. He was obviously right. That's what I intended. What's to comment? > A third > alternative would be an explanation why you believe that the uselessness > of "informal pipes" for inter-process communication (which is the main > use I'm aware of for "formal pipes") fails to render your claim invalid. The kinds of pipes are just two different ways of doing the same thing. Obviously you can't use a within-one-process pattern to do things wiht two processes and vice versa. > Would you care to provide one of those three alternatives? Or suggest a > fourth? I fear you don't understand what I am talking about.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-05-19 13:16 -0400 |
| Message-ID | <555B6FD0.8050105@verizon.net> |
| In reply to | #62300 |
On 05/19/2015 12:46 PM, David Kleinecke wrote: ... > The kinds of pipes are just two different ways of doing the same thing. > Obviously you can't use a within-one-process pattern to do things wiht > two processes and vice versa. The second sentence contradicts the first. > I fear you don't understand what I am talking about. I understand that it's not worthwhile talking with you any more.
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.lang.c
csiph-web