Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #91437 > unrolled thread
| Started by | luser droog <luser.droog@gmail.com> |
|---|---|
| First post | 2016-07-31 15:31 -0700 |
| Last post | 2016-08-08 22:12 -0700 |
| Articles | 20 on this page of 144 — 28 participants |
Back to article view | Back to comp.lang.c
Extending C with GC? luser droog <luser.droog@gmail.com> - 2016-07-31 15:31 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-07-31 15:52 -0700
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 17:21 -0700
Re: Extending C with GC? Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-01 20:34 +0200
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-01 12:14 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-01 12:46 -0700
Re: Extending C with GC? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-01 15:56 -0400
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-01 14:28 -0700
Re: Extending C with GC? Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-01 23:37 +0200
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-01 15:03 -0700
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-02 00:11 +0200
Re: Extending C with GC? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-01 18:19 -0400
Re: Extending C with GC? BGB <cr88192@hotmail.com> - 2016-08-02 12:46 -0500
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-03 15:26 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-03 15:49 -0700
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-04 14:07 +1200
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-03 19:26 -0700
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-04 14:55 +1200
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-03 20:38 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-04 05:10 -0700
Re: Extending C with GC? Siri Cruise <chine.bleu@yahoo.com> - 2016-08-04 05:57 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-04 06:13 -0700
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-05 07:24 +1200
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-04 12:47 -0700
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-04 23:32 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-05 10:09 +0100
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-05 20:32 +1200
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-05 06:14 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 04:14 -0700
Re: Extending C with GC? Melzzzzz <mel@zzzzz.com> - 2016-08-06 13:23 +0200
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 04:38 -0700
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-06 04:34 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 05:28 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 06:05 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 06:12 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-06 14:02 +0100
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-06 06:11 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-06 14:50 +0100
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-06 07:57 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-06 17:02 +0100
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-06 19:20 +0200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-06 14:27 +0100
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-06 14:45 +0100
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 09:59 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-06 19:38 +0100
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 17:03 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 09:54 +0100
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-07 21:53 +1200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 11:34 +0100
Re: Extending C with GC? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-07 12:06 +0000
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-07 14:10 +0100
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 15:38 +0100
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 14:32 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 23:44 +0100
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 16:12 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 01:42 +0100
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 18:56 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 10:20 +0100
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-08 09:39 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 02:30 +0100
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 20:15 +0100
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 01:24 +0100
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 02:08 +0100
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 18:49 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 03:28 +0100
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 12:14 +0100
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 07:37 +1200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 20:56 +0100
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 08:11 +1200
Re: Extending C with GC? Melzzzzz <mel@zzzzz.com> - 2016-08-07 22:19 +0200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 22:23 +0100
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-07 14:29 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 22:36 +0100
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-07 15:04 -0700
Re: Extending C with GC? jameskuyper@verizon.net - 2016-08-07 15:19 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 00:04 +0100
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-07 16:20 -0700
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 15:21 +1200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 10:35 +0100
Re: Extending C with GC? Gareth Owen <gwowen@gmail.com> - 2016-08-08 18:13 +0100
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-08 11:53 -0700
Re: Extending C with GC? raltbos@xs4all.nl (Richard Bos) - 2016-08-10 12:58 +0000
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-10 07:05 -0700
Re: Extending C with GC? Ken Brody <kenbrody@spamcop.net> - 2016-08-10 12:29 -0400
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 21:15 +0100
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-08 08:57 -0700
Re: Extending C with GC? luser droog <luser.droog@gmail.com> - 2016-08-07 15:37 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 14:58 -0700
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 15:26 +1200
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-08 10:26 +0200
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 21:13 +1200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 10:41 +0100
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-08 12:00 +0200
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 22:07 +1200
Re: Extending C with GC? David Brown <david.brown@hesbynett.no> - 2016-08-08 12:57 +0200
Re: Extending C with GC? Gareth Owen <gwowen@gmail.com> - 2016-08-08 18:12 +0100
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 21:25 +1200
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 02:57 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 13:28 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-07 05:42 -0700
Re: Extending C with GC? Florian Weimer <fw@deneb.enyo.de> - 2016-08-07 11:49 +0200
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-06 19:18 +0200
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-06 12:35 -0700
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-06 19:27 +0200
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 10:55 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-06 12:31 -0700
Re: Extending C with GC? James Kuyper <jameskuyper@verizon.net> - 2016-08-03 22:36 -0400
Re: Extending C with GC? David Brown <david.brown@hesbynett.no> - 2016-08-04 10:57 +0200
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-04 04:09 -0700
Re: Extending C with GC? David Brown <david.brown@hesbynett.no> - 2016-08-04 14:01 +0200
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-04 07:52 -0700
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-04 08:57 -0700
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-04 09:19 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-04 12:30 -0700
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-04 15:21 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-04 16:50 -0700
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-05 07:31 -0700
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 16:01 -0700
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-04 21:00 +0200
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-04 20:26 +0100
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-05 10:37 +0200
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-05 15:52 +0100
Re: Extending C with GC? antispam@math.uni.wroc.pl - 2016-08-21 00:09 +0000
Re: Extending C with GC? Gareth Owen <gwowen@gmail.com> - 2016-08-21 08:58 +0100
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-21 10:48 +0200
Re: Extending C with GC? "Pascal J. Bourguignon" <pjb@informatimago.com> - 2016-08-21 19:58 +0200
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-22 08:46 -0700
Re: Extending C with GC? Öö Tiib <ootiib@hot.ee> - 2016-08-26 02:24 -0700
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-26 13:37 -0700
Re: Extending C with GC? Melzzzzz <mel@zzzzz.com> - 2016-08-27 00:41 +0200
Re: Extending C with GC? Öö Tiib <ootiib@hot.ee> - 2016-08-28 06:12 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-05 10:06 +0100
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-05 15:26 +0100
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 08:11 -0700
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-05 17:43 +0200
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 15:28 -0700
Re: Extending C with GC? BGB <cr88192@hotmail.com> - 2016-08-04 17:11 -0500
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 17:35 -0700
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-01 07:45 +0200
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-01 08:49 -0700
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-01 09:06 -0700
Re: Extending C with GC? Aleksandar Kuktin <akuktin@gmail.com> - 2016-08-05 18:11 +0000
Re: Extending C with GC? luser droog <luser.droog@gmail.com> - 2016-08-05 11:24 -0700
Re: Extending C with GC? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-08 22:12 -0700
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-07 20:15 +0100 |
| Message-ID | <no81c3$mps$1@dont-email.me> |
| In reply to | #91853 |
On 07/08/2016 14:10, Ben Bacarisse wrote: > (c) Whine about how everyone else writes software on Usenet. > > What isn't going to happen is that people will stop using autoconf and > make because you don't like them. Personally, I hate autoconf, but I > don't know the problems it solves well enough to try to replace it, and > it has the benefit (for me) that it just works. > > I suppose you could consider switching to Linux, since I've not had to > run a configure script for years -- most often you just install the > required pre-built package. And of you do need to run ./configure; make > you'll find it probably just works. It sounds like you use Linux. That would explain why you think anyone else complaining about being forced to use it (effectively, at gun-point) is whining about nothing. Obviously, for you, everything works! What's the problem?! It's funny how in a newsgroup where the emphasis is on writing portable code, that there are these massive dependencies on ONE specific OS, and no one thinks there is anything wrong with that. Not even with applications that are inherently portable such as GMP. Or, where we're supposed to be discussing the C language, that an application purportedly in C cannot actually be compiled without making use of thousands of lines of code in completely unrelated languages. Sometimes, more lines of code than there are in C! As I've observed a few times, some of the attitudes in this group are extraordinary. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-08 01:24 +0100 |
| Message-ID | <8737mgm7jq.fsf@bsb.me.uk> |
| In reply to | #91864 |
BartC <bc@freeuk.com> writes: <snip> > It's funny how in a newsgroup where the emphasis is on writing > portable code, that there are these massive dependencies on ONE > specific OS, and no one thinks there is anything wrong with that. At first sight, this looks like a absurd things to say, but then I remembered your skill as a political speech writer. Take a few portable tools (like make and a shell that run on many systems) and call that a massive dependency on one specific OS (sorry ONE specific OS). Now you can roll your eyes and tut that no one thinks there's anything wrong with that! > Not > even with applications that are inherently portable such as GMP. If I had to guess, I would not guess that GMP is inherently portable. And yes, a quick glance at the source shows directories with assembler code for mips and 390 and goodness knows what else. If you can re-write any system dependencies in a portable subset of C that works on all the target platforms, I'm sure the maintainer would take your patches. It seems a shame that you, as one of the few people to see how it can be done better, does not help out. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-08 02:08 +0100 |
| Message-ID | <no8m38$kh0$1@dont-email.me> |
| In reply to | #91899 |
On 08/08/2016 01:24, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > <snip> >> It's funny how in a newsgroup where the emphasis is on writing >> portable code, that there are these massive dependencies on ONE >> specific OS, and no one thinks there is anything wrong with that. > > At first sight, this looks like a absurd things to say, but then I > remembered your skill as a political speech writer. Take a few portable > tools (like make and a shell that run on many systems) Which 'make' runs on many systems? Which 'shell'? With 'make', every C compiler seems to have its own incompatible version (and an incompatible makefile syntax to go with it). How can you take something like 'Bash' and say it's portable? It doesn't run on Windows because Windows isn't Linux. It can be emulated, but then pretty much any program can be 'portable'. >> Not >> even with applications that are inherently portable such as GMP. > > If I had to guess, I would not guess that GMP is inherently portable. > And yes, a quick glance at the source shows directories with assembler > code for mips and 390 and goodness knows what else. > > If you can re-write any system dependencies in a portable subset of C > that works on all the target platforms, I'm sure the maintainer would > take your patches. It seems a shame that you, as one of the few people > to see how it can be done better, does not help out. I have my own big integer library. It can be expressed in 100% portable C. So could most of gmp I would imagine (I don't know all the things it does). The assembly files you saw are probably optimisations for specific targets. (In the same way one of my bytecode interpreters can be expressed entirely in portable C, but there is also an ASM module that can optionally be used with x86-64.) There must be a better way of organising distributions of such libraries that doesn't depend on such outdated and non-portable tools. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-07 18:49 -0700 |
| Message-ID | <lninvcvxm9.fsf@kst-u.example.com> |
| In reply to | #91901 |
BartC <bc@freeuk.com> writes:
[...]
> Which 'make' runs on many systems? Which 'shell'?
>
> With 'make', every C compiler seems to have its own incompatible version
> (and an incompatible makefile syntax to go with it).
No C compiler has "make". Some collections of bundled software might
include both a C compiler and some version of "make". Refer to my
previous messages explaining what a "compiler" is.
> How can you take something like 'Bash' and say it's portable? It doesn't
> run on Windows because Windows isn't Linux. It can be emulated, but then
> pretty much any program can be 'portable'.
Google "Bash on Windows". It's supported by Microsoft.
Bash also runs on a number of systems that are neither Windows nor
Linux. Ignore the distinction between "Linux" and "Unix" if you like,
but it is significant.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-08 03:28 +0100 |
| Message-ID | <87r3a0kn8a.fsf@bsb.me.uk> |
| In reply to | #91901 |
BartC <bc@freeuk.com> writes: > On 08/08/2016 01:24, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> <snip> >>> It's funny how in a newsgroup where the emphasis is on writing >>> portable code, that there are these massive dependencies on ONE >>> specific OS, and no one thinks there is anything wrong with that. >> >> At first sight, this looks like a absurd things to say, but then I >> remembered your skill as a political speech writer. Take a few portable >> tools (like make and a shell that run on many systems) > > Which 'make' runs on many systems? Which 'shell'? > > With 'make', every C compiler seems to have its own incompatible > version (and an incompatible makefile syntax to go with it). > > How can you take something like 'Bash' and say it's portable? It > doesn't run on Windows because Windows isn't Linux. It can be > emulated, but then pretty much any program can be 'portable'. Neat footwork! I never said that one make or one specific shell is either portable or runs on many systems (although some versions of make do indeed run on many systems). The tools are portable because they (in some version or other) run on many systems. >>> Not >>> even with applications that are inherently portable such as GMP. >> >> If I had to guess, I would not guess that GMP is inherently portable. >> And yes, a quick glance at the source shows directories with assembler >> code for mips and 390 and goodness knows what else. >> >> If you can re-write any system dependencies in a portable subset of C >> that works on all the target platforms, I'm sure the maintainer would >> take your patches. It seems a shame that you, as one of the few people >> to see how it can be done better, does not help out. > > I have my own big integer library. Ah, so you're OK then. <snip> > There must be a better way of organising distributions of such > libraries that doesn't depend on such outdated I agree. There must be a better way, but it's hard to get right and harder to get such things widely adopted. Mainly because, your experience notwithstanding, the current tools work. > and non-portable tools. No, they work because they are portable. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-08 12:14 +0100 |
| Message-ID | <no9pji$e0l$1@dont-email.me> |
| In reply to | #91911 |
On 08/08/2016 03:28, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> I have my own big integer library. > > Ah, so you're OK then. The library supports big ints in a language, where there are used just like normal integers as: a=b*c. So the support could have been switched to using GMP, which is faster and covers many more operations, without affecting programs. But, because big ints form an unimportant part of the overall application, I didn't want issues with obtaining the binary GMP needed to cause difficulties. There are ways to make the use of GMP optional: a quick check for libgmp-3.dll for example, and then things can be fixed up to make use of that. But it's extra work on top of using GMP anyway. But behind decisions like that is the difficulty of ensuring GMP is available (for such an apparently niche platform as MS Windows). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-08 07:37 +1200 |
| Message-ID | <e0pgv1Foda0U3@mid.individual.net> |
| In reply to | #91847 |
On 08/ 7/16 10:34 PM, BartC wrote: > On 07/08/2016 10:53, Ian Collins wrote: >> On 08/ 7/16 08:54 PM, BartC wrote: >>> On 07/08/2016 01:03, Rick C. Hodgin wrote: >>>> >>>> Nobody else would have to do that, Bart. You would download and install >>>> the source files, and then include a DLL or OBJ files which are included >>>> in your distributed project. You could include a readme.txt file on how >>>> you built it so those who want to build it can. >>>> >>>> You can also refactor the source code so it is a single source file, and >>>> distribute it that way. >>> >>> You've got it back to front. Probably everyone else is happy to jump >>> through all those hoops (perhaps because they've always had to do it and >>> think that's how it must be). I'm not! >> >> ./configure; make >> >> Now that's one massive hoop... > > On my machine that doesn't work. Because it's designed to be meaningful > only on Linux or something that emulates Linux. Nope, the process predates Linux. I've used Solaris for over 20 years and due to the lack of packaged opensource software on older versions I was well used to to running "./configure; make" after downloading source. One reason configure scripts are so big is to take into account all of the possible (and often long dead) systems the code might get built on. > But even if it worked**, the question is WHY? What on earth does it do > that absolutely REQUIRES 20,000 lines of scripting code? Is there no one > willing to simplify it? How many lines are there in a compiler? Do you care? Configure scripts are machine generated to be run by another machine. Sure the generation could produce less code by applying functional decomposition, but why should it? The script wouldn't run any faster. > If everyone ignores these issues, then sooner or later we will need > 200,000 lines of scripting code (piling up layer upon layer) and no one > on the planet will know what it all does. Those who care know how the code generation works. Do you fully understand all of the assembler generated by a compiler? > (**And from my experience, even when I make the attempt, it too often > crashes out half way through. Or sometimes, it apparently completes - > except it neglects to tell you exactly what it has produced and where > it's placed it!) If it was an autoconf generated script there would be a log file. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-07 20:56 +0100 |
| Message-ID | <no83q9$ut0$1@dont-email.me> |
| In reply to | #91868 |
On 07/08/2016 20:37, Ian Collins wrote: > On 08/ 7/16 10:34 PM, BartC wrote: >> On my machine that doesn't work. Because it's designed to be meaningful >> only on Linux or something that emulates Linux. > > Nope, the process predates Linux. Linux, Unix, whatever. > One reason configure scripts are so big is to take into account all of > the possible (and often long dead) systems the code might get built on. Are we still talking about C code? And how exactly does it take account of these systems? Is the application written in C, or is it actually written in Bash? >> But even if it worked**, the question is WHY? What on earth does it do >> that absolutely REQUIRES 20,000 lines of scripting code? Is there no one >> willing to simplify it? > > How many lines are there in a compiler? Do you care? If someone gave me a program file.c and I had a compiler cc.exe then no, I wouldn't care how many lines there were in cc.exe. But I'm told I can't just type 'cc file.c' because I first have to run a script, in a language I don't recognise and requiring a program to execute it that I haven't got. I can't just look at the script to see what it does so that I can emulate it, because there are 20000 lines of it! And it contains myriad calls to other tools none of which I have either. So yes I do care! But even if I had just that tool to run that script, I'd still like to know what the hell it is that needs a *MASSIVE* 20,000 line program just to somehow prepare things so that I can do 'cc file.c'. What is it doing, actually generating the compiler or something? > Configure scripts are machine generated to be run by another machine. So why doesn't it write the script in C, if it doesn't care how big it is or what it looks like? At least the user will have a C compiler and doesn't hit a brick wall. > Sure the generation could produce less code by applying functional > decomposition, but why should it? The script wouldn't run any faster. You can make the script faster by deleting it completely. No one has yet managed to give me a satisfactory description of what it is actually doing. I think no one actually knows. Is this the modern equivalent of the Emperor's New Clothes? And only BartC can see that there is actually nothing there? >> (**And from my experience, even when I make the attempt, it too often >> crashes out half way through. Or sometimes, it apparently completes - >> except it neglects to tell you exactly what it has produced and where >> it's placed it!) > > If it was an autoconf generated script there would be a log file. Yes, 90 minutes' worth of log data would really help.... -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-08 08:11 +1200 |
| Message-ID | <e0piuqFoda0U4@mid.individual.net> |
| In reply to | #91871 |
On 08/ 8/16 07:56 AM, BartC wrote: > On 07/08/2016 20:37, Ian Collins wrote: >> On 08/ 7/16 10:34 PM, BartC wrote: > >>> On my machine that doesn't work. Because it's designed to be meaningful >>> only on Linux or something that emulates Linux. >> >> Nope, the process predates Linux. > > Linux, Unix, whatever. The whatever is important. >> One reason configure scripts are so big is to take into account all of >> the possible (and often long dead) systems the code might get built on. > > Are we still talking about C code? And how exactly does it take account > of these systems? Is the application written in C, or is it actually > written in Bash? By checking the system headers, checking what libraries and what version of those libraries are installed, checking what compilers (and which versions) are installed, checking the system architecture, system OS (and version) and what ever else is required to build the code. >>> But even if it worked**, the question is WHY? What on earth does it do >>> that absolutely REQUIRES 20,000 lines of scripting code? Is there no one >>> willing to simplify it? >> >> How many lines are there in a compiler? Do you care? > > If someone gave me a program file.c and I had a compiler cc.exe then no, > I wouldn't care how many lines there were in cc.exe. > > But I'm told I can't just type 'cc file.c' because I first have to run a > script, in a language The script is in the lowest common denominator language. Every system the code is targeted at will have it. > So yes I do care! So why do you persist in pushing shit up hill by developing C code on Windows? >> Configure scripts are machine generated to be run by another machine. > > So why doesn't it write the script in C, if it doesn't care how big it > is or what it looks like? At least the user will have a C compiler and > doesn't hit a brick wall. The only user hitting brick walls is you. If it hurts, stop doing it. >> If it was an autoconf generated script there would be a log file. > > Yes, 90 minutes' worth of log data would really help.... Hint - look at the end.... -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-08-07 22:19 +0200 |
| Message-ID | <20160807221936.34dcda6b@maxa-pc> |
| In reply to | #91872 |
On Mon, 8 Aug 2016 08:11:06 +1200 Ian Collins <ian-news@hotmail.com> wrote: > On 08/ 8/16 07:56 AM, BartC wrote: > > On 07/08/2016 20:37, Ian Collins wrote: > >> On 08/ 7/16 10:34 PM, BartC wrote: > > > >>> On my machine that doesn't work. Because it's designed to be > >>> meaningful only on Linux or something that emulates Linux. > >> > >> Nope, the process predates Linux. > > > > Linux, Unix, whatever. > > The whatever is important. > > >> One reason configure scripts are so big is to take into account > >> all of the possible (and often long dead) systems the code might > >> get built on. > > > > Are we still talking about C code? And how exactly does it take > > account of these systems? Is the application written in C, or is it > > actually written in Bash? > > By checking the system headers, checking what libraries and what > version of those libraries are installed, checking what compilers > (and which versions) are installed, checking the system architecture, > system OS (and version) and what ever else is required to build the > code. > > >>> But even if it worked**, the question is WHY? What on earth does > >>> it do that absolutely REQUIRES 20,000 lines of scripting code? Is > >>> there no one willing to simplify it? > >> > >> How many lines are there in a compiler? Do you care? > > > > If someone gave me a program file.c and I had a compiler cc.exe > > then no, I wouldn't care how many lines there were in cc.exe. > > > > But I'm told I can't just type 'cc file.c' because I first have to > > run a script, in a language > > The script is in the lowest common denominator language. Every > system the code is targeted at will have it. > > > So yes I do care! > > So why do you persist in pushing shit up hill by developing C code on > Windows? On Windows there is cygwin. I have used it successfully in the past to develop for Linux...
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-07 22:23 +0100 |
| Message-ID | <no88sa$g6p$1@dont-email.me> |
| In reply to | #91872 |
On 07/08/2016 21:11, Ian Collins wrote: > On 08/ 8/16 07:56 AM, BartC wrote: >> On 07/08/2016 20:37, Ian Collins wrote: >>> On 08/ 7/16 10:34 PM, BartC wrote: >> >>>> On my machine that doesn't work. Because it's designed to be meaningful >>>> only on Linux or something that emulates Linux. >>> >>> Nope, the process predates Linux. >> >> Linux, Unix, whatever. > > The whatever is important. > >>> One reason configure scripts are so big is to take into account all of >>> the possible (and often long dead) systems the code might get built on. >> >> Are we still talking about C code? And how exactly does it take account >> of these systems? Is the application written in C, or is it actually >> written in Bash? > > By checking the system headers, checking what libraries and what version > of those libraries are installed, checking what compilers (and which > versions) are installed, checking the system architecture, system OS > (and version) and what ever else is required to build the code. And that takes tens of thousands of lines of of code? What does it do with the result? What's the role of make files in all this, or is that yet another level? >> But I'm told I can't just type 'cc file.c' because I first have to run a >> script, in a language > > The script is in the lowest common denominator language. Every system > the code is targeted at will have it. Well, my system doesn't. Importing most of Linux to make it 'have' it doesn't count. And if I did have it, I still wouldn't want it. I like to have my own streamlined build procedures. >> So yes I do care! > So why do you persist in pushing shit up hill by developing C code on > Windows? Why should running a C compiler on Windows be any different to anywhere else? It sounds like the Linux/whatever development system has gotten itself so bound up with all this stuff that it can no longer extricate itself, and ends up inflicting it on everyone else. I've developed programs on Windows for years and there were never any such problems. >>> Configure scripts are machine generated to be run by another machine. >> >> So why doesn't it write the script in C, if it doesn't care how big it >> is or what it looks like? At least the user will have a C compiler and >> doesn't hit a brick wall. > > The only user hitting brick walls is you. The brick wall is when the build instructions say type ./configure and that doesn't work because you're not running linux/unix/whatever. And you haven't answered my question. If a library is written in C, then you know a C compiler is needed and will be available. So WHY NOT generate a script as C code? Or would yet another configure script be needed before you can build /that/?! That's assuming a script is needed of which I haven't yet seen any evidence. > If it hurts, stop doing it. I would. But sometimes you want to make use of a third party library, then you find it's been infected with all this Linux stuff that means it's no longer a trivial matter of compiling a few files, but having to deal with all the extraneous junk that comes with it. EXAMPLE Some time back I downloaded 'Smaller C', a simple C compiler. Despite there being being only 8 .c files (which are used to make 3 separate executables), it naturally comes with a configure script and two makefiles! (The configure script was small, but it was still gobbledygook.) Now I managed to build this under Windows by figuring out which C files go with which executable. Why can't the Readme or Install file just list this basic information? This configure/make palaver is very unfriendly outside the Linux world and is overkill IMO. It's taking something that could be very simple, and making it impossible. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-07 14:29 -0700 |
| Message-ID | <161418f7-c46c-442c-a48f-95b24bc56eaf@googlegroups.com> |
| In reply to | #91875 |
Bartc wrote: > The brick wall is when the build instructions say type > ./configure and that doesn't work because you're not > running linux/unix/whatever. Install cygwin. It gives you the appropriate bash terminal, and allows linux/unix/whatever on Windows, with generated binaries which run on Windows natively. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-07 22:36 +0100 |
| Message-ID | <no89lp$i2l$1@dont-email.me> |
| In reply to | #91876 |
On 07/08/2016 22:29, Rick C. Hodgin wrote: > Bartc wrote: >> The brick wall is when the build instructions say type >> ./configure and that doesn't work because you're not >> running linux/unix/whatever. > > Install cygwin. It gives you the appropriate bash terminal, and > allows linux/unix/whatever on Windows, with generated binaries > which run on Windows natively. I tried MSYS last time I made a serious attempt. It didn't work. My gripe however is with having to install either MSYS or CYGWIN. For a C application, why do you need anything beyond a C compiler? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-07 15:04 -0700 |
| Message-ID | <40109a45-cdb6-4c36-be29-272d947c9cd4@googlegroups.com> |
| In reply to | #91878 |
Bartc wrote:
> For a C application, why do you need anything beyond a C compiler?
Because it's not just C. It's a build system for multiple platforms,
with multiple other library requirements which, in your code case
happens to be C.
The autoconf tools make it easy for the developer, with only
two comnands:
./configure
make
It does require some effort to get it setup in Windows the first
time. After that, it's almost as easy on Windows as in Linux.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-08-07 15:19 -0700 |
| Message-ID | <0e4e80d4-8232-491d-8afb-5b75a1f6d52d@googlegroups.com> |
| In reply to | #91878 |
On Sunday, August 7, 2016 at 5:37:04 PM UTC-4, Bart wrote: > On 07/08/2016 22:29, Rick C. Hodgin wrote: > > Bartc wrote: > >> The brick wall is when the build instructions say type > >> ./configure and that doesn't work because you're not > >> running linux/unix/whatever. > > > > Install cygwin. It gives you the appropriate bash terminal, and > > allows linux/unix/whatever on Windows, with generated binaries > > which run on Windows natively. > > I tried MSYS last time I made a serious attempt. It didn't work. > > My gripe however is with having to install either MSYS or CYGWIN. MSVS? > For a C application, why do you need anything beyond a C compiler? Because a C compiler is only part of a C implementation. Typically, a complete implementation also includes an implementation of the C standard library, a linker, and an operating system of some kind, all of which must be compatible with each other. Other ways of putting together an implementation are possible, but uncommon, and this is the architecture I'm most familiar with. In addition, since the standard defines an implementation as "particular set of software, running in a particular translation environment under particular control options, that performs translation of programs for, and supports execution of functions in, a particular execution environment" (3.12p2), you can't have a complete C implementation without also having a CPU, and some kind of data storage, and the software must already be running on that CPU - otherwise it doesn't qualify as an implementation. I've been arguing that software alone can't qualify as a conforming implementation for years, but I only recently discovered that it's the standard's definition of "implementation" which justifies my claim. I'd been concentrating on the "conforming" aspect, and arguments based upon conformance necessarily addressed the issue less directly: a conforming implementation is required to produce certain kinds of behavior when translating or executing a program, and software that is not currently executing can neither translate a program, nor execute it, nor produce the required behavior. People for some reason found that a less convincing argument, though it seems pretty strong to me. However, the use of "running" in the present tense in 3.12p1 makes it clearer. So, having a C compiler is insufficient, just like having a engine is insufficient to travel from Chicago to New York. You're really surprised by this?
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-08 00:04 +0100 |
| Message-ID | <no8epm$3gh$1@dont-email.me> |
| In reply to | #91882 |
On 07/08/2016 23:19, jameskuyper@verizon.net wrote: > On Sunday, August 7, 2016 at 5:37:04 PM UTC-4, Bart wrote: >> On 07/08/2016 22:29, Rick C. Hodgin wrote: >>> Bartc wrote: >>>> The brick wall is when the build instructions say type >>>> ./configure and that doesn't work because you're not >>>> running linux/unix/whatever. >>> >>> Install cygwin. It gives you the appropriate bash terminal, and >>> allows linux/unix/whatever on Windows, with generated binaries >>> which run on Windows natively. >> >> I tried MSYS last time I made a serious attempt. It didn't work. >> >> My gripe however is with having to install either MSYS or CYGWIN. > > MSVS? No it was Msys, a lightweight Cygwin IIRC. >> For a C application, why do you need anything beyond a C compiler? > > Because a C compiler is only part of a C implementation. Typically, a complete implementation also includes an implementation of the C standard library, a linker, and an operating system of some kind, all of which must be compatible with each other. Other ways of putting together an implementation are possible, but uncommon, and this is the architecture I'm most familiar with. > So, having a C compiler is insufficient, just like having a engine is insufficient to travel from Chicago to New York. You're really surprised by this? Yes, a C compiler, and a linker, obviously. And a possibly an OS when you want to execute the result. I was talking about the prerequisites that seem to a feature of C applications developed under Unix. These apply even before you're allowed to get anywhere near a C compiler. So I meant BASH scripts and the assorted utilities they invoke. I'm not keen on make files either (because things tend to go wrong), but they unfortunately occur with Windows too. I believe in having a C compiler (and linker), and simple human-readable /instructions/ on how to build a project. (Have the make-file too if you like but not instead of.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-07 16:20 -0700 |
| Message-ID | <65289554-f595-46ef-93a7-e0f94bb1a152@googlegroups.com> |
| In reply to | #91890 |
Bartc wrote: > What's interesting however is that this NMAKE didn't need > 'configure' to work. So why does Linux need it? And what exactly > DOES it do? Apparently, nothing important! 20,000 pointless > lines just as I thought. It creates the make file for compilation, and typically a header file (or a few) which include machine + OS + compiler specific quirks so it compiles correctly with C89, C99, C11, partially- compliant compilers, etc. The configure script runs a host of tests to determine how to create the make file for use with "make". It can also be setup to allow options like make dll or make lib or make exe, etc. It's a way to create a system to distribute to compile on Unix, Linux, Sun, BSD, Mac, and Windows, and more. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-08 15:21 +1200 |
| Message-ID | <e0qc61Fdmg1U1@mid.individual.net> |
| In reply to | #91890 |
On 08/ 8/16 11:04 AM, BartC wrote: > > I believe in having a C compiler (and linker), and simple human-readable > /instructions/ on how to build a project. (Have the make-file too if you > like but not instead of.) Good luck building something small like an OS kernel, or a compiler with a C compiler and simple instructions. See you back here next year. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-08 10:35 +0100 |
| Message-ID | <no9jpp$rvo$1@dont-email.me> |
| In reply to | #91916 |
On 08/08/2016 04:21, Ian Collins wrote: > On 08/ 8/16 11:04 AM, BartC wrote: >> >> I believe in having a C compiler (and linker), and simple human-readable >> /instructions/ on how to build a project. (Have the make-file too if you >> like but not instead of.) > > Good luck building something small like an OS kernel, or a compiler with > a C compiler and simple instructions. See you back here next year. Any compiler *I* produce can be built with simple instructions (partly because I keep them simple, partly because I MAKE THE EFFORT). Any other project too. (I don't know what an OS kernel is or what it does. I suspect a lot of that is also just a lot of unnecessary complexity. And yes, I did at one time have to write code for bare boards that had no other software, to get peripherals, drives and displays up and running.) But it would be a really great laugh if it turns out all these scripts that everyone is blindly running without having a clue what they're doing, turn out to be a heap of rubbish, or doing a bunch of extra stuff that's totally useless. Maybe there were supposed to be only 50 lines but somehow an extra 19950 lines got added because of a mistake in the program that generated them. And no one has noticed since 1989. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-08-08 18:13 +0100 |
| Message-ID | <87invbchfo.fsf@gmail.com> |
| In reply to | #91933 |
BartC <bc@freeuk.com> writes: > On 08/08/2016 04:21, Ian Collins wrote: >> On 08/ 8/16 11:04 AM, BartC wrote: >>> >>> I believe in having a C compiler (and linker), and simple human-readable >>> /instructions/ on how to build a project. (Have the make-file too if you >>> like but not instead of.) >> >> Good luck building something small like an OS kernel, or a compiler with >> a C compiler and simple instructions. See you back here next year. > > Any compiler *I* produce can be built with simple instructions (partly > because I keep them simple, partly because I MAKE THE EFFORT). Well, that's one of the advantages of software that only ever needs to be run on one machine.
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web