Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #140005 > unrolled thread
| Started by | Bart <bc@freeuk.com> |
|---|---|
| First post | 2019-01-20 00:03 +0000 |
| Last post | 2019-01-21 00:13 -0600 |
| Articles | 20 on this page of 160 — 17 participants |
Back to article view | Back to comp.lang.c
Compiler tests Bart <bc@freeuk.com> - 2019-01-20 00:03 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-20 16:52 +1300
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-20 10:27 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-20 12:37 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 13:08 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 15:02 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-20 17:31 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 17:08 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-20 21:40 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 22:41 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 00:39 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 00:36 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-21 16:33 +1300
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 11:58 +0000
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-21 04:15 -0800
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-22 07:53 +1300
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-23 01:15 -0600
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 12:00 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-24 08:13 +1300
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-23 13:30 -0600
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 08:22 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 12:23 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 14:42 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 14:17 +0000
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-21 12:46 -0800
You guys really, really need to get a room (Was: Compiler tests) gazelle@shell.xmission.com (Kenny McCormack) - 2019-01-24 14:05 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-20 17:27 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 17:19 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 09:44 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 12:49 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 15:31 +0100
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-21 14:38 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-21 15:15 +0100
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-21 16:05 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 16:39 +0100
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-21 12:51 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 00:16 +0000
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-22 08:43 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 12:31 +0000
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-22 17:49 +0100
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-23 11:04 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 11:18 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 15:35 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 15:49 +0000
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-21 17:42 +0100
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-23 03:18 -0600
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 11:11 +0100
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-23 12:18 -0600
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 13:56 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-22 10:55 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 12:07 +0000
Re: Compiler tests fir <profesor.fir@gmail.com> - 2019-01-22 04:29 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 12:52 +0000
Re: Compiler tests mark.bluemel@gmail.com - 2019-01-22 05:04 -0800
Re: Compiler tests fir <profesor.fir@gmail.com> - 2019-01-22 05:18 -0800
Re: Compiler tests fir <profesor.fir@gmail.com> - 2019-01-22 05:45 -0800
Re: Compiler tests fir <profesor.fir@gmail.com> - 2019-01-22 05:35 -0800
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-22 15:10 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 17:30 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-22 23:02 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 23:14 +0000
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-22 15:45 -0800
Re: Compiler tests Robert Wessel <robertwessel2@yahoo.com> - 2019-01-22 17:57 -0600
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-22 16:36 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 01:37 +0000
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-22 18:53 -0800
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 09:42 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 09:22 +0100
Re: Compiler tests James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-23 08:52 -0500
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 15:13 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 14:33 +0000
Re: Compiler tests James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-23 07:30 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 16:05 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 17:17 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 16:29 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 22:04 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 21:50 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 10:45 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 11:55 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 13:58 +0100
Re: Compiler tests mark.bluemel@gmail.com - 2019-01-24 05:07 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 14:10 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 14:18 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 15:51 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 15:44 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 17:32 +0000
Re: Compiler tests scott@slp53.sl.home (Scott Lurndal) - 2019-01-24 19:07 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 20:14 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 22:24 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 22:46 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-25 12:34 +1300
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 01:01 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-25 14:15 +1300
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 10:05 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 14:51 +0000
Re: Compiler tests Mateusz Viste <mateusz@wont.tell> - 2019-01-25 09:48 +0000
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 10:56 +0100
Re: Compiler tests Mateusz Viste <mateusz@wont.tell> - 2019-01-25 12:08 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 13:28 +0100
Re: Compiler tests Mateusz Viste <mateusz@wont.tell> - 2019-01-25 13:33 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 15:38 +0100
Re: Compiler tests Mateusz Viste <mateusz@wont.tell> - 2019-01-25 15:08 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 13:53 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 12:25 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 10:03 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 10:08 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 11:14 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 12:02 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 13:37 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 13:58 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 14:26 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 15:01 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 15:42 +0100
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-25 10:25 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 14:37 +0000
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 16:33 +0100
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-25 07:44 -0800
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 17:53 +0100
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-25 10:33 -0800
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 20:43 +0100
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-25 12:17 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 18:31 +0000
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 20:41 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 21:19 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-26 10:24 +1300
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 22:27 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 22:39 +0000
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-25 18:46 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 12:43 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 14:37 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 14:19 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 15:47 +0100
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-25 07:17 -0800
Re: Compiler tests Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-03 07:28 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-02-03 12:35 +0100
Re: Compiler tests Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-03 21:47 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-02-03 22:57 +0100
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-24 06:47 -0800
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-23 20:22 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 22:12 +0100
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-23 21:54 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 11:41 +0100
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-24 23:17 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 11:11 +0100
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-25 12:04 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 14:05 +0100
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-25 18:40 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 22:36 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 22:15 +0000
Re: Compiler tests scott@slp53.sl.home (Scott Lurndal) - 2019-01-25 14:48 +0000
Re: Compiler tests scott@slp53.sl.home (Scott Lurndal) - 2019-01-25 14:46 +0000
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-25 17:48 +0000
Re: Compiler tests James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-23 08:23 -0800
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 16:41 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 16:18 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 17:28 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 20:23 +0000
Re: Compiler tests Robert Wessel <robertwessel2@yahoo.com> - 2019-01-22 17:52 -0600
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 20:17 +0000
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-21 00:13 -0600
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2019-01-24 05:07 -0800 |
| Message-ID | <ab178a99-426c-4c53-a0b4-e23976e2fac3@googlegroups.com> |
| In reply to | #140159 |
On Thursday, 24 January 2019 12:58:27 UTC, David Brown wrote: > If it does what /you (bart)/ need, then great. But it does not do > what /I/ need. Then clearly your requirements are wrong. It's already been established that Bart's requirements are correct, complete and sufficient for all users of any computing environment. * for some value of established, replace the term with "asserted" if you prefer.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-24 14:10 +0000 |
| Message-ID | <GHj2E.194369$gE1.67431@fx02.am4> |
| In reply to | #140159 |
On 24/01/2019 12:58, David Brown wrote:
> On 24/01/2019 12:55, Bart wrote:
> Compiling my C code relies on dozens of tools - shells, OS's, editors,
> compiler, assembler, linker, etc. I don't have to manually run extra
> processes to make sure that the latest version of my files get included
> - it happens automatically when I type "make" (or press "ctrl-B"), which
> is a shorter and simpler command than you use to run your compiler.
>
> People have been using tools since our ancestors climbed down from the
> trees. I wonder if you'd complain that nails are a bad idea, because
> they are sore to hammer in with your forehead.
I build my C compiler (which includes 40 embedded files) with one
command: mm cc. 'mm' is a compiler.
I build my other compilers, which also include embedded library files,
also with one command each: mm mc or mm qc.
Since they all build entirely from source, they will automatically get
the latest versions of everything.
There might still be scripts for some things, but only for those that
belong outside the core of the executable. (Sometimes, extra support
files are added to the executable to still form one .exe file. Eg.
install scripts.)
But core executables are done with a bare compiler. It really does sound
as though your tools are that ancient.
>> If this feature is rare, then I think it does make it more capable. (Not
>> even my idea, I think it came from something that BGB once said.)
>>
>
> If it is rare, it is because few others think it is a useful feature -
> or they think it is not worth the effort.
It is likely rare because it is next to impossible to add a feature like
this into a language. It would take years, then a further couple of
decades until support is widespread enough to rely on it.
And there would be opposite from people like you who have already
invested in their own workarounds.
> It would not have the features I need. I have given examples of these
> before, but let me try again. Sometimes I want to modify the file I
> bring in. Perhaps I want to add extra information to it - the size, a
> CRC check, a digital signature, some metainformation. Perhaps I want to
> bring in a number of files - all the files in a directory, without
> having to list them all manually. Perhaps i want to convert the files
> in some way. Perhaps I don't want to include files at all, but just
> generate some data tables that would be inefficient on the target
> system. This is all simple when these files are read in with a
> high-level language (I use Python - there are many alternatives) which
> then generates appropriate C code. It means all this work is done at
> build time, not at run time.
How about when you just want to do:
puts(strinclude("help.txt"));
and don't want the bother of adding an extra support file to a
distribution, or the headache of finding where it's located.
No need for CRC checks or signatures. Just an alternative to having to
maintain text represented as a string constant instead of a TXT file.
I think you're just thinking of every possible reason to not use the
feature, simply to avoid admitting that this would actually be a good idea.
> It compares hopelessly with using external scripts, because it does not
> do anything even vaguely like what I need.
>
> If it does what /you/ need, then great. But it does not do what /I/ need.
See: https://stackoverflow.com/questions/43256465/include-a-file-as-a-string
Where the questioner says: "No external tool shall be used, just the
preprocessor: I am trying to get rid of my python scripts that do this."
There is also:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1040r1.html,
which says:
"Every C and C++ programmer -- at some point -- attempts to #include
large chunks of non-C++ data into their code. Of course, #include
expects the format of the data to be source code, and thusly the program
fails with spectacular lexer errors. Thusly, many different tools and
practices were adapted to handle this, as far back as 1995 with the xxd
tool. Many industries need such functionality ..."
(Followed by the usual complicated approach of C++ to such matters.)
The need /is/ there. I certainly make extensive use of it.
If there are extra requirements, then fine, do it another way. Or, as in
your case, your builds are so fantastically complicated that taking care
of this makes little difference, then keep on doing it that way.
I do feel you're burying your head in the sand about this.
And I can't really believe that if someone did want to embed a named
text file as a string, and the 'strinclude' feature was generally
supported, that they would turn up their nose at it and go and write
some clunky script instead.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-24 14:18 +0000 |
| Message-ID | <IOj2E.381745$Fi6.64433@fx12.am4> |
| In reply to | #140163 |
On 24/01/2019 14:10, Bart wrote: > There is also: > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1040r1.html, > which says: > > "Every C and C++ programmer -- at some point -- attempts to #include > large chunks of non-C++ data into their code. Of course, #include > expects the format of the data to be source code, and thusly the program > fails with spectacular lexer errors. Thusly, many different tools and > practices were adapted to handle this, as far back as 1995 with the xxd > tool. Many industries need such functionality ..." More: "The request for some form of #include_string or similar dates back quite a long time, with one of the oldest stack overflow questions asked-and-answered about it dating back nearly 10 years. Predating even that is a plethora of mailing list posts and forum posts asking how to get script code and other things that are not likely to change into the binary." Recall that my earlier post today where I added just a feature (although for text files) into a C compiler in around 20 minutes. Binary files would take a bit longer. Does the proposed std::embed feature deal with your [DB's] requirements for CRCs and file conversions? I don't know. Would you still reject it if not?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-24 15:51 +0100 |
| Message-ID | <q2cjda$qis$1@dont-email.me> |
| In reply to | #140164 |
On 24/01/2019 15:18, Bart wrote: > On 24/01/2019 14:10, Bart wrote: > >> There is also: >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1040r1.html, >> which says: >> >> "Every C and C++ programmer -- at some point -- attempts to #include >> large chunks of non-C++ data into their code. Of course, #include >> expects the format of the data to be source code, and thusly the >> program fails with spectacular lexer errors. Thusly, many different >> tools and practices were adapted to handle this, as far back as 1995 >> with the xxd tool. Many industries need such functionality ..." > > More: > > "The request for some form of #include_string or similar dates back > quite a long time, with one of the oldest stack overflow questions > asked-and-answered about it dating back nearly 10 years. Predating even > that is a plethora of mailing list posts and forum posts asking how to > get script code and other things that are not likely to change into the > binary." > > Recall that my earlier post today where I added just a feature (although > for text files) into a C compiler in around 20 minutes. Binary files > would take a bit longer. > > Does the proposed std::embed feature deal with your [DB's] requirements > for CRCs and file conversions? I don't know. Would you still reject it > if not? It would cover some of my needs, and not others. If it is implemented, then I might well use it in some cases, but it does not cover everything I need. (Of course, an actual real implementation may have additional features and cover my requirements.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-24 15:44 +0100 |
| Message-ID | <q2cj0a$o5t$1@dont-email.me> |
| In reply to | #140163 |
On 24/01/2019 15:10, Bart wrote:
> On 24/01/2019 12:58, David Brown wrote:
>> On 24/01/2019 12:55, Bart wrote:
>
>> Compiling my C code relies on dozens of tools - shells, OS's, editors,
>> compiler, assembler, linker, etc. I don't have to manually run extra
>> processes to make sure that the latest version of my files get included
>> - it happens automatically when I type "make" (or press "ctrl-B"), which
>> is a shorter and simpler command than you use to run your compiler.
>>
>> People have been using tools since our ancestors climbed down from the
>> trees. I wonder if you'd complain that nails are a bad idea, because
>> they are sore to hammer in with your forehead.
>
> I build my C compiler (which includes 40 embedded files) with one
> command: mm cc. 'mm' is a compiler.
And I build my projects using one command "make". Most people doing
real programming know about modularisation, and split their work into an
appropriate number of files. You have this obsession within making life
hard for yourself due to your bizarre idea that "make" (and other build
tools) are impossibly difficult for you to use. You would have us
believe you are a veteran programmer with decades of experience of
different languages and tools, capable of designing and implementing
your own language and compilers, and yet "make" is beyond you. It is
absurd.
>
> I build my other compilers, which also include embedded library files,
> also with one command each: mm mc or mm qc.
>
> Since they all build entirely from source, they will automatically get
> the latest versions of everything.
>
> There might still be scripts for some things, but only for those that
> belong outside the core of the executable. (Sometimes, extra support
> files are added to the executable to still form one .exe file. Eg.
> install scripts.)
>
> But core executables are done with a bare compiler. It really does sound
> as though your tools are that ancient.
>
>>> If this feature is rare, then I think it does make it more capable. (Not
>>> even my idea, I think it came from something that BGB once said.)
>>>
>>
>> If it is rare, it is because few others think it is a useful feature -
>> or they think it is not worth the effort.
>
> It is likely rare because it is next to impossible to add a feature like
> this into a language. It would take years, then a further couple of
> decades until support is widespread enough to rely on it.
Bollocks from start to finish.
>
> And there would be opposite from people like you who have already
> invested in their own workarounds.
>
We are talking about a 20 line script for a simple include generator.
>> It would not have the features I need. I have given examples of these
>> before, but let me try again. Sometimes I want to modify the file I
>> bring in. Perhaps I want to add extra information to it - the size, a
>> CRC check, a digital signature, some metainformation. Perhaps I want to
>> bring in a number of files - all the files in a directory, without
>> having to list them all manually. Perhaps i want to convert the files
>> in some way. Perhaps I don't want to include files at all, but just
>> generate some data tables that would be inefficient on the target
>> system. This is all simple when these files are read in with a
>> high-level language (I use Python - there are many alternatives) which
>> then generates appropriate C code. It means all this work is done at
>> build time, not at run time.
>
> How about when you just want to do:
>
> puts(strinclude("help.txt"));
I don't believe I have ever needed to do that.
$ cat makehelp.py
file("help.txt.h", "w").write("\n".join(['"' + x.rstrip() + '"' for x
in file("help.txt").readlines()]))
In the C code:
puts(
#include "help.txt.h"
);
That is not how I would prefer to write it, and does not handle things
like quotation marks in the help file, but it shows how simple it can be.
>
> and don't want the bother of adding an extra support file to a
> distribution, or the headache of finding where it's located.
>
If this is all extra work and a headache for you, you need to re-think
your distribution method. Perhaps you want to consider "zip" - it's
been around for 30 years.
> No need for CRC checks or signatures. Just an alternative to having to
> maintain text represented as a string constant instead of a TXT file.
>
> I think you're just thinking of every possible reason to not use the
> feature, simply to avoid admitting that this would actually be a good idea.
>
No, I am giving examples of features I need and use. I have /never/ had
to include a text file directly in my code. But I /have/ used all the
features I mentioned.
>> It compares hopelessly with using external scripts, because it does not
>> do anything even vaguely like what I need.
>>
>> If it does what /you/ need, then great. But it does not do what /I/
>> need.
>
> See:
> https://stackoverflow.com/questions/43256465/include-a-file-as-a-string
>
> Where the questioner says: "No external tool shall be used, just the
> preprocessor: I am trying to get rid of my python scripts that do this."
>
So you are not alone in making stupid and unnecessary requirements to
make live difficult. This sort of thing sounds like a school maths
question - "Divide three pizzas equally between 8 people using no more
than three cuts. You may not use a calculator, and you are not allowed
to pick off the anchovies even though no one likes them".
> There is also:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1040r1.html,
> which says:
>
> "Every C and C++ programmer -- at some point -- attempts to #include
> large chunks of non-C++ data into their code. Of course, #include
> expects the format of the data to be source code, and thusly the program
> fails with spectacular lexer errors. Thusly, many different tools and
> practices were adapted to handle this, as far back as 1995 with the xxd
> tool. Many industries need such functionality ..."
>
> (Followed by the usual complicated approach of C++ to such matters.)
>
> The need /is/ there. I certainly make extensive use of it.
>
Yes - and as far back as 1995, there have been tools like xxd for
solving this so that you don't need to put it in the language.
I have never said that people don't need to include extra data in their
C code. All I have said is that they can do so fine today with a
minimum of effort, and that often a simplistic solution like yours would
not be good enough anyway.
Since you mention C++, however, it is worth pointing out that with
modern C++ the feature could be more useful. That is because C++ can do
compile-time work. I could, for example, use a "binary include"
mechanism in C++ and have C++ code to calculate a CRC check at compile
time, rather than doing it with external code. It would still not cover
everything I need, but it would cover more than your solution.
> If there are extra requirements, then fine, do it another way. Or, as in
> your case, your builds are so fantastically complicated that taking care
> of this makes little difference, then keep on doing it that way.
>
My builds are often reasonably simple, and very rarely "fantastically
complicated".
> I do feel you're burying your head in the sand about this.
>
> And I can't really believe that if someone did want to embed a named
> text file as a string, and the 'strinclude' feature was generally
> supported, that they would turn up their nose at it and go and write
> some clunky script instead.
>
I agree that if there were such a feature in the language (or at least
in the compiler being used), and if such a feature were sufficient for
the persons need, then there is little point in using an external script
to do the job.
But that feature is not in the language or tools, and the feature would
not be sufficient for my needs, so I use scripts. Why is /that/ so hard
for you to comprehend?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-24 17:32 +0000 |
| Message-ID | <aFm2E.274925$3si.175399@fx08.am4> |
| In reply to | #140165 |
On 24/01/2019 14:44, David Brown wrote:
> On 24/01/2019 15:10, Bart wrote:
>> I build my C compiler (which includes 40 embedded files) with one
>> command: mm cc. 'mm' is a compiler.
>
> And I build my projects using one command "make".
So, taking a fiddly build sequence of dozens of steps, involving running
utilities, scripts in multiple languages and having extra dependencies,
wrapping it all up in a makefile script then invoking the lot using
'make' is just the same as one genuinely simple step using nothing extra?
If you believe that, then carry on believing it if you want.
> Most people doing
> real programming know about modularisation, and split their work into an
> appropriate number of files.
What makes you think my project isn't modular?
My 'mm cc' builds a project of 27 source modules and 42 embedded text
files. cc.m is the lead module. It doesn't need anything extra because
it's all done with language features (two specifically: 'import' and
'strinclude').
> You have this obsession within making life
> hard for yourself due to your bizarre idea that "make" (and other build
> tools) are impossibly difficult for you to use.
What is bizarre is thinking that what I do is making life more difficult
for me; why on earth would I do it if that was the case. If gcc could do
what my 'mm' could do, then you would just build a project using:
gcc cc.c
That is, a project of dozens of modules and embedded files.
I think everyone else is making life difficult for themselves.
> We are talking about a 20 line script for a simple include generator.
That requires an 80MB Python installation of 4500 files.
I'm talking about a feature that is a no-brainer, that is trivial to
implement and makes it a piece of cake to do a simple inclusion of any
text file as a string constant, without needing to write programs in
another language to accomplish.
> file("help.txt.h", "w").write("\n".join(['"' + x.rstrip() + '"' for x
> in file("help.txt").readlines()]))
>
> In the C code:
>
> puts(
> #include "help.txt.h"
> );
>
> That is not how I would prefer to write it, and does not handle things
> like quotation marks in the help file, but it shows how simple it can be.
Then it's making a half-arsed attempt at it. You might as well just
paste the text using an editor, and add quotes at either end.
> If this is all extra work and a headache for you, you need to re-think
> your distribution method. Perhaps you want to consider "zip" - it's
> been around for 30 years.
Ok. You unzip the files into /A. The exe files might be in /A/bin, the
help files are in /A/docs for version 1.3, but /A/help in 1.4. Somebody
runs /A/bin/prog.exe from /B.
This means locating the directory where the executable was started from
(which apparently is not easy in Linux), forming a relative path, then
attempting to load the file and dealing with errors.
That apparently is preferable to just writing:
puts(strinclude("help.txt"));
The only circumstances in which that makes more sense is where
programmers are paid by the hour and are creating extra work for themselves.
> No, I am giving examples of features I need and use. I have /never/ had
> to include a text file directly in my code. But I /have/ used all the
> features I mentioned.
That makes sense. You've never needed such feature, so no one else can
have it!
> Yes - and as far back as 1995, there have been tools like xxd for
> solving this so that you don't need to put it in the language.
So why don't /you/ use xxd?
> But that feature is not in the language or tools, and the feature would
> not be sufficient for my needs, so I use scripts. Why is /that/ so hard
> for you to comprehend?
Because you are scathing of the feature. This is not one of Rick's crazy
ideas that no one can see the point of, but something more fundamental.
It's a way of managing longer, multi-line string constants that are more
convenient to manage in their own file, or that belong in a separate
file. Or maybe that external file is shared and maintained by someone
else or belongs to some other project. Or maybe that external file is
initialised with text in a specific language.
(The word Luddite comes to mind; I've no idea why...)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-01-24 19:07 +0000 |
| Message-ID | <r1o2E.60382$gL3.45519@fx27.iad> |
| In reply to | #140174 |
Bart <bc@freeuk.com> writes: >On 24/01/2019 14:44, David Brown wrote: >> On 24/01/2019 15:10, Bart wrote: > >>> I build my C compiler (which includes 40 embedded files) with one >>> command: mm cc. 'mm' is a compiler. >> >> And I build my projects using one command "make". > >So, taking a fiddly build sequence of dozens of steps, involving running >utilities, scripts in multiple languages and having extra dependencies, >wrapping it all up in a makefile script then invoking the lot using >'make' is just the same as one genuinely simple step using nothing extra? > >If you believe that, then carry on believing it if you want. I believe it. Your solution is incompatible with the real world, where applications often have several hundred thousands of lines of code spread across hundreds of source files, often using generated header files or specialized pre-processors.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-24 20:14 +0000 |
| Message-ID | <e_o2E.395001$kk4.221231@fx36.am4> |
| In reply to | #140183 |
On 24/01/2019 19:07, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> On 24/01/2019 14:44, David Brown wrote: >>> On 24/01/2019 15:10, Bart wrote: >> >>>> I build my C compiler (which includes 40 embedded files) with one >>>> command: mm cc. 'mm' is a compiler. >>> >>> And I build my projects using one command "make". >> >> So, taking a fiddly build sequence of dozens of steps, involving running >> utilities, scripts in multiple languages and having extra dependencies, >> wrapping it all up in a makefile script then invoking the lot using >> 'make' is just the same as one genuinely simple step using nothing extra? >> >> If you believe that, then carry on believing it if you want. > > I believe it. Your solution is incompatible with the real world, where > applications often have several hundred thousands of lines of code spread across hundreds of > source files, often using generated header files or specialized pre-processors. The subject was the utility of a feature like 'strinclude', or '#include_string' in the proposal I linked to. Your view supposedly is that helping to reduce some of that complexity is not worth the trouble of having such features. BTW a few months ago I managed to compile a run and version of Seed7, which was 122 modules totalling 475Kloc (of scanned code), including a generated header file, using my C compiler and nothing more complex than a .bat file, and an @ file containing a list of module names. The process [compiling 122 modules to .exe] took 0.9 seconds (on a machine which I now know to be slow). I did the same with Lua (35 modules), again no make files. So /my/ view is still that a lot of this stuff can be massively simpler than it is.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-24 22:24 +0100 |
| Message-ID | <q2dadm$fae$1@dont-email.me> |
| In reply to | #140174 |
On 24/01/2019 18:32, Bart wrote:
> On 24/01/2019 14:44, David Brown wrote:
>> On 24/01/2019 15:10, Bart wrote:
>
>>> I build my C compiler (which includes 40 embedded files) with one
>>> command: mm cc. 'mm' is a compiler.
>>
>> And I build my projects using one command "make".
>
> So, taking a fiddly build sequence of dozens of steps, involving running
> utilities, scripts in multiple languages and having extra dependencies,
> wrapping it all up in a makefile script then invoking the lot using
> 'make' is just the same as one genuinely simple step using nothing extra?
>
I am a /programmer/. Writing lots of fiddly lines that non-initiates
can't understand, but where the result can be used simply and reliably,
is what programmers do!
The makefiles I use are complex. That is because they do a good deal
automatically, and thus save time and effort in use, and increase
reliability. Sure, it took a bit of time to get the hang of writing
them. It took a bit of web research to find useful examples. The
result of that investment is a much smoother development system - one
that I can rely on to get the compilations right even for large projects
with many parts. Perhaps for your unstructured projects with single
monstrous C files, one compilation command is enough. But not for
anyone writing structured code of any size. (I have also told you a
number of times that my compile lines have a large number of flags and
options - and that this is necessary for the targets I use.)
Having made the investment, building is done with "make". I have
projects where that builds half a dozen different programs or variants
for different systems, builds binaries into flash programming files,
automatically downloads to test cards, etc. All from "make".
> If you believe that, then carry on believing it if you want.
>
>> Most people doing
>> real programming know about modularisation, and split their work into an
>> appropriate number of files.
>
> What makes you think my project isn't modular?
>
Your obsession with single giant files, along with your dismissal of
sensible development tools and editors.
> My 'mm cc' builds a project of 27 source modules and 42 embedded text
> files. cc.m is the lead module. It doesn't need anything extra because
> it's all done with language features (two specifically: 'import' and
> 'strinclude').
>
>> You have this obsession within making life
>> hard for yourself due to your bizarre idea that "make" (and other build
>> tools) are impossibly difficult for you to use.
>
> What is bizarre is thinking that what I do is making life more difficult
> for me; why on earth would I do it if that was the case. If gcc could do
> what my 'mm' could do, then you would just build a project using:
>
> gcc cc.c
How is it that you think it's fine to give lists of modules to compile
in a C file (or "mm" file, or whatever language you use) but if the list
is in a file called "Makefile", you'd rather poke your eyes out with a
sharp stick? A makefile is part of the project source code. It is
written in a different language - just as linker files are, and perhaps
assembly files, Python scripts, and any other parts of the code.
>
> That is, a project of dozens of modules and embedded files.
>
> I think everyone else is making life difficult for themselves.
When you think everyone else is out of tune except you, it is perhaps
time to look up from your navel and wonder if there is something you
have missed.
>
>> We are talking about a 20 line script for a simple include generator.
>
> That requires an 80MB Python installation of 4500 files.
Which is installed anyway, and thus has a cost of zero.
>
> I'm talking about a feature that is a no-brainer, that is trivial to
> implement and makes it a piece of cake to do a simple inclusion of any
> text file as a string constant, without needing to write programs in
> another language to accomplish.
It may be a no-brainer to you, who are writing a one-man compiler for a
one-man language that has no need for documentation, testing, quality
control, or anything else. Adding features to serious languages and
serious development tools is a much bigger issue. But even if it were a
no-brainer, it is no more than a limited solution at best. It wouldn't
be the slightest help to me, for example.
>
>> file("help.txt.h", "w").write("\n".join(['"' + x.rstrip() + '"' for x
>> in file("help.txt").readlines()]))
>>
>> In the C code:
>>
>> puts(
>> #include "help.txt.h"
>> );
>>
>> That is not how I would prefer to write it, and does not handle things
>> like quotation marks in the help file, but it shows how simple it can be.
>
> Then it's making a half-arsed attempt at it. You might as well just
> paste the text using an editor, and add quotes at either end.
>
The quotes need to go on every line. But the main difference between
this and pasting with an editor, as you are so fond of noting, is that
it gets the right version of the text file every build.
>
>> If this is all extra work and a headache for you, you need to re-think
>> your distribution method. Perhaps you want to consider "zip" - it's
>> been around for 30 years.
>
> Ok. You unzip the files into /A. The exe files might be in /A/bin, the
> help files are in /A/docs for version 1.3, but /A/help in 1.4. Somebody
> runs /A/bin/prog.exe from /B.
>
> This means locating the directory where the executable was started from
> (which apparently is not easy in Linux), forming a relative path, then
> attempting to load the file and dealing with errors.
>
> That apparently is preferable to just writing:
>
> puts(strinclude("help.txt"));
>
> The only circumstances in which that makes more sense is where
> programmers are paid by the hour and are creating extra work for
> themselves.
>
What part of "your solution does not work for what I need" is confusing you?
My suggestion for zip files was how /you/ could deal with your personal
horror of distributing more than one file.
>> No, I am giving examples of features I need and use. I have /never/ had
>> to include a text file directly in my code. But I /have/ used all the
>> features I mentioned.
>
> That makes sense. You've never needed such feature, so no one else can
> have it!
Was that creative snipping so that you could project your own views on
me? I am not the one who thinks one limited little trick should be good
enough for everyone else.
>
>> Yes - and as far back as 1995, there have been tools like xxd for
>> solving this so that you don't need to put it in the language.
>
> So why don't /you/ use xxd?
The primary reason is that I hadn't heard of it until very recently. I
could use it in some cases, but not for everything I need.
>
>> But that feature is not in the language or tools, and the feature would
>> not be sufficient for my needs, so I use scripts. Why is /that/ so hard
>> for you to comprehend?
>
> Because you are scathing of the feature. This is not one of Rick's crazy
> ideas that no one can see the point of, but something more fundamental.
I have nothing against the feature. It's fine, as far as it goes. The
only crazy thing is your idea that it is good enough for people doing a
bit more complex file embedding, or that it replaces the use of other
code generators for specialised purposes, or that it is particularly
innovative or useful, or that it is so fantastically better than using
external scripts. If it were a feature of C (or at least of the
compilers I use), and were sufficient for particular use-cases, then I
certainly would use it.
>
> It's a way of managing longer, multi-line string constants that are more
> convenient to manage in their own file, or that belong in a separate
> file. Or maybe that external file is shared and maintained by someone
> else or belongs to some other project. Or maybe that external file is
> initialised with text in a specific language.
>
> (The word Luddite comes to mind; I've no idea why...)
>
That word doesn't even begin to describe you - after all, the technology
you reject is decades old.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-24 22:46 +0000 |
| Message-ID | <4fr2E.149191$iL2.146583@fx17.am4> |
| In reply to | #140203 |
On 24/01/2019 21:24, David Brown wrote: > On 24/01/2019 18:32, Bart wrote: >> What makes you think my project isn't modular? >> > > Your obsession with single giant files, along with your dismissal of > sensible development tools and editors. You don't seem to understand how a module system works in this kind of language. When you write 'python prog.py' then it will automatically seek out and load any dependencies of prog.py, you don't need to list them all in an auxiliary file. The same with my languages. I don't use giant files except for C distributions, where they are a by-product of how my translator works. Most build systems will take N source files and produce 1 .exe or .dll file. My compiler will take N source files and produce 1 .exe or .dll file, or sometimes 1 .c file. So the principle is no different. But my compiler will do it all in one go and without needing any extra information, by making use of its module system. That means it's more sophisticated that your tools. >> gcc cc.c > > How is it that you think it's fine to give lists of modules to compile > in a C file (or "mm" file, or whatever language you use) but if the list > is in a file called "Makefile", you'd rather poke your eyes out with a > sharp stick? The vital information needed to build, is primarily a list of modules. My language can work that out. C can't (except for specially written programs using my experimental -auto option, the idea proposed by Anton Shepelev). So it needs an explicit list of modules. That's fine. But no makefile I've seen has ever been that simple. This is the @ file I use to build Seed7: s7.c runerr.c option.c primitiv.c actlib.c arrlib.c biglib.c binlib.c blnlib.c bstlib.c chrlib.c cmdlib.c conlib.c dcllib.c drwlib.c enulib.c fillib.c fltlib.c hshlib.c intlib.c itflib.c kbdlib.c lstlib.c pcslib.c pollib.c prclib.c prglib.c reflib.c rfllib.c sctlib.c setlib.c soclib.c sqllib.c strlib.c timlib.c typlib.c ut8lib.c exec.c doany.c objutl.c act_comp.c prg_comp.c analyze.c syntax.c token.c parser.c name.c type.c expr.c atom.c object.c scanner.c literal.c numlit.c findid.c error.c infile.c libpath.c symbol.c info.c stat.c fatal.c match.c syvarutl.c traceutl.c actutl.c executl.c blockutl.c entutl.c identutl.c chclsutl.c arrutl.c arr_rtl.c bln_rtl.c bst_rtl.c chr_rtl.c cmd_rtl.c con_rtl.c dir_rtl.c drw_rtl.c fil_rtl.c flt_rtl.c hsh_rtl.c int_rtl.c itf_rtl.c pcs_rtl.c set_rtl.c soc_rtl_dummy.c sql_rtl.c str_rtl.c tim_rtl.c ut8_rtl.c heaputl.c numutl.c sigutl.c striutl.c sql_base.c sql_lite.c sql_my.c sql_oci.c sql_odbc.c sql_post.c big_rtl.c big_gmp.c cmd_win.c dir_win.c dll_win.c fil_win.c pcs_win.c pol_sel_dummy.c stat_win.c tim_win.c gkb_rtl.c drw_win.c gkb_win.c kbd_rtl.c con_win.c typ_data.c rfl_data.c ref_data.c listutl.c flistutl.c typeutl.c datautl.c msvcrt.dll user32.dll kernel32.dll gdi32.dll shell32.dll There is nothing to understand about this, it's just a list. The same list can work for different compilers. And I could chose to submit the list by hand. Or invoke the compiler one at a time for each .c file. It is not an obstacle or hindrance to overcome like a makefile file. This information /HAD TO BE PAINFULLY EXTRACTED FROM AN ACTUAL MAKEFILE/. (And there were 17 variations to choose from. Think about it - why were there 17 variations? Aren't they just script files and therefore ultimately flexible?). > That word doesn't even begin to describe you - after all, the technology > you reject is decades old. Yes, it is. Maybe that's why I reject it.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-01-25 12:34 +1300 |
| Message-ID | <gav0cdFfhgbU2@mid.individual.net> |
| In reply to | #140211 |
On 25/01/2019 11:46, Bart wrote: > On 24/01/2019 21:24, David Brown wrote: >> On 24/01/2019 18:32, Bart wrote: > >>> What makes you think my project isn't modular? >>> >> >> Your obsession with single giant files, along with your dismissal of >> sensible development tools and editors. > > You don't seem to understand how a module system works in this kind of > language. > > When you write 'python prog.py' then it will automatically seek out and > load any dependencies of prog.py, you don't need to list them all in an > auxiliary file. > > The same with my languages. > > I don't use giant files except for C distributions, where they are a > by-product of how my translator works. > > Most build systems will take N source files and produce 1 .exe or .dll file. > > My compiler will take N source files and produce 1 .exe or .dll file, or > sometimes 1 .c file. So the principle is no different. But my compiler > will do it all in one go and without needing any extra information, by > making use of its module system. Many project builds involve a lot more than just compiling. Pre-build code generation is a common step, building for multiple targets is a common step, building multiple languages is a common step. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-25 01:01 +0000 |
| Message-ID | <Ndt2E.145647$592.89156@fx16.am4> |
| In reply to | #140217 |
On 24/01/2019 23:34, Ian Collins wrote:
> On 25/01/2019 11:46, Bart wrote:
>> On 24/01/2019 21:24, David Brown wrote:
>>> On 24/01/2019 18:32, Bart wrote:
>>
>>>> What makes you think my project isn't modular?
>>>>
>>>
>>> Your obsession with single giant files, along with your dismissal of
>>> sensible development tools and editors.
>>
>> You don't seem to understand how a module system works in this kind of
>> language.
>>
>> When you write 'python prog.py' then it will automatically seek out and
>> load any dependencies of prog.py, you don't need to list them all in an
>> auxiliary file.
>>
>> The same with my languages.
>>
>> I don't use giant files except for C distributions, where they are a
>> by-product of how my translator works.
>>
>> Most build systems will take N source files and produce 1 .exe or .dll
>> file.
>>
>> My compiler will take N source files and produce 1 .exe or .dll file, or
>> sometimes 1 .c file. So the principle is no different. But my compiler
>> will do it all in one go and without needing any extra information, by
>> making use of its module system.
>
> Many project builds involve a lot more than just compiling. Pre-build
> code generation is a common step, building for multiple targets is a
> common step, building multiple languages is a common step.
But a core part, when constructing one or the only executable file, /is/
to compile N source files to that one file?
Here's how I would build one compiler on and for Windows 64:
mm mc
Here's here I would build 5 different versions on Windows:
mm -x64 -windows mc -out:mc64.exe
mm -c64 -windows -c mc -out:mc_win64.c
mm -c32 -windows -c mc -out:mc_win32.c
mm -c64 -linux -c mc -out:mc_lin64.c
mm -c32 -linux -c mc -out:mc_lin32.c
This creates one actual .exe, and four single-file C versions. Those
need to be processed by a C compiler, two on Linux, but being a single
file, each is just one invocation:
gcc mc_lin64.c -omc64 -lm
See how with these larger building blocks, scripting is still possible,
but the steps are fewer. Each mm step involves 22 modules and 13
embedded text files, but these details are taken care of.
It's also quick: running all those five lines takes 3/4 of a second.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-01-25 14:15 +1300 |
| Message-ID | <gav68mFfhgbU3@mid.individual.net> |
| In reply to | #140220 |
On 25/01/2019 14:01, Bart wrote: > On 24/01/2019 23:34, Ian Collins wrote: >> On 25/01/2019 11:46, Bart wrote: >>> On 24/01/2019 21:24, David Brown wrote: >>>> On 24/01/2019 18:32, Bart wrote: >>> >>>>> What makes you think my project isn't modular? >>>>> >>>> >>>> Your obsession with single giant files, along with your dismissal of >>>> sensible development tools and editors. >>> >>> You don't seem to understand how a module system works in this kind of >>> language. >>> >>> When you write 'python prog.py' then it will automatically seek out and >>> load any dependencies of prog.py, you don't need to list them all in an >>> auxiliary file. >>> >>> The same with my languages. >>> >>> I don't use giant files except for C distributions, where they are a >>> by-product of how my translator works. >>> >>> Most build systems will take N source files and produce 1 .exe or .dll >>> file. >>> >>> My compiler will take N source files and produce 1 .exe or .dll file, or >>> sometimes 1 .c file. So the principle is no different. But my compiler >>> will do it all in one go and without needing any extra information, by >>> making use of its module system. >> >> Many project builds involve a lot more than just compiling. Pre-build >> code generation is a common step, building for multiple targets is a >> common step, building multiple languages is a common step. > > But a core part, when constructing one or the only executable file, /is/ > to compile N source files to that one file? The core part is but one part of the build. The compile part of a makefile is often a single rule. The stuff that becomes before and after makes the build process and the makefile interesting. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-25 10:05 +0100 |
| Message-ID | <q2ejgf$cor$2@dont-email.me> |
| In reply to | #140220 |
On 25/01/2019 02:01, Bart wrote: > On 24/01/2019 23:34, Ian Collins wrote: >> On 25/01/2019 11:46, Bart wrote: >>> On 24/01/2019 21:24, David Brown wrote: >>>> On 24/01/2019 18:32, Bart wrote: >>> >>>>> What makes you think my project isn't modular? >>>>> >>>> >>>> Your obsession with single giant files, along with your dismissal of >>>> sensible development tools and editors. >>> >>> You don't seem to understand how a module system works in this kind of >>> language. >>> >>> When you write 'python prog.py' then it will automatically seek out and >>> load any dependencies of prog.py, you don't need to list them all in an >>> auxiliary file. >>> >>> The same with my languages. >>> >>> I don't use giant files except for C distributions, where they are a >>> by-product of how my translator works. >>> >>> Most build systems will take N source files and produce 1 .exe or >>> .dll file. >>> >>> My compiler will take N source files and produce 1 .exe or .dll file, or >>> sometimes 1 .c file. So the principle is no different. But my compiler >>> will do it all in one go and without needing any extra information, by >>> making use of its module system. >> >> Many project builds involve a lot more than just compiling. Pre-build >> code generation is a common step, building for multiple targets is a >> common step, building multiple languages is a common step. > > But a core part, when constructing one or the only executable file, /is/ > to compile N source files to that one file? > > Here's how I would build one compiler on and for Windows 64: > > mm mc > > Here's here I would build 5 different versions on Windows: > > mm -x64 -windows mc -out:mc64.exe > mm -c64 -windows -c mc -out:mc_win64.c > mm -c32 -windows -c mc -out:mc_win32.c > mm -c64 -linux -c mc -out:mc_lin64.c > mm -c32 -linux -c mc -out:mc_lin32.c > > This creates one actual .exe, and four single-file C versions. Those > need to be processed by a C compiler, two on Linux, but being a single > file, each is just one invocation: > > gcc mc_lin64.c -omc64 -lm > > See how with these larger building blocks, scripting is still possible, > but the steps are fewer. Each mm step involves 22 modules and 13 > embedded text files, but these details are taken care of. > > It's also quick: running all those five lines takes 3/4 of a second. > It is also crying out for a makefile. At the very least, it is crying out for a shell script or batch file. That way, when the source is changed you know that /all/ your output files are updated appropriately - not just the ones you happen to have remembered to compile.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-25 14:51 +0000 |
| Message-ID | <tnF2E.140585$RE1.65322@fx32.am4> |
| In reply to | #140223 |
On 25/01/2019 09:05, David Brown wrote:
> On 25/01/2019 02:01, Bart wrote:
>> Here's here I would build 5 different versions on Windows:
>>
>> mm -x64 -windows mc -out:mc64.exe
>> mm -c64 -windows -c mc -out:mc_win64.c
>> mm -c32 -windows -c mc -out:mc_win32.c
>> mm -c64 -linux -c mc -out:mc_lin64.c
>> mm -c32 -linux -c mc -out:mc_lin32.c
>>
>> This creates one actual .exe, and four single-file C versions. Those
>> need to be processed by a C compiler, two on Linux, but being a single
>> file, each is just one invocation:
>>
>> gcc mc_lin64.c -omc64 -lm
>>
>> See how with these larger building blocks, scripting is still possible,
>> but the steps are fewer. Each mm step involves 22 modules and 13
>> embedded text files, but these details are taken care of.
> It is also crying out for a makefile. At the very least, it is crying
> out for a shell script or batch file.
Those five lines /were/ in a batchfile. Putting linear sequences of
commands into a script, or lists of filenames into a file, is not
something I have a problem with. Unfortunately makefiles never look like
that.
What I actually want from a makefile is the build information in a form
I can understand. Eg. in English. Then I can make my own arrangements.
I do use batch files even with my mm projects, but they are usually
simple. Here's the one I use to build a production version of itself:
\m\mm mc -ext -out:mm.exe
copy mm.exe \m
(The -ext option makes it use external library files, not the ones
built-in to the current mm.exe. Some updates may rely on changes to hose
files. Backing up the original mm.exe is something done separately.
This can't be done in one line, as the original mm.exe must terminate
before I can overwrite it.
So two lines. Still small....)
Here it is in action (the file is called putmm, and here it is timed):
C:\mx>timeit putmm
C:\mx>\m\mm mc -ext -out:mm.exe
Compiling mc.m to mm.exe
C:\mx>copy mm.exe \m
1 file(s) copied.
putmm 0.21
C:\mx>
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@wont.tell> |
|---|---|
| Date | 2019-01-25 09:48 +0000 |
| Message-ID | <5c4adb7b$0$15179$426a74cc@news.free.fr> |
| In reply to | #140220 |
On Fri, 25 Jan 2019 01:01:29 +0000, Bart wrote: > Here's how I would build one compiler on and for Windows 64: > > mm mc > > Here's here I would build 5 different versions on Windows: > > mm -x64 -windows mc -out:mc64.exe mm -c64 -windows -c mc > -out:mc_win64.c mm -c32 -windows -c mc -out:mc_win32.c mm -c64 > -linux -c mc -out:mc_lin64.c mm -c32 -linux -c mc > -out:mc_lin32.c > > This creates one actual .exe, and four single-file C versions. Those > need to be processed by a C compiler, two on Linux, but being a single > file, each is just one invocation: > > gcc mc_lin64.c -omc64 -lm > > See how with these larger building blocks, scripting is still possible, > but the steps are fewer. Each mm step involves 22 modules and 13 > embedded text files, but these details are taken care of. > > It's also quick: running all those five lines takes 3/4 of a second. I see two major problems with your approach: 1. Each time you change a single byte in a big project, you need to compile everything again. And that can take a lot of time when the project is really big. A Makefile will only recompile the one little module that changed, and relink the rest. MUCH faster. 2. The "one single *.c file" you boast about is, I assume, a monolithic mess. As such, it will take forever for a C compiler to compile, and it will require humongous amounts of memory to do so (memory which may or may not be available for the task). The modular approach is by far more economical in that aspect as well. Mateusz
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2019-01-25 10:56 +0100 |
| Message-ID | <m2munpgiw6.fsf@despina.home> |
| In reply to | #140226 |
Mateusz Viste <mateusz@wont.tell> writes: > 2. The "one single *.c file" you boast about is, I assume, a monolithic > mess. As such, it will take forever for a C compiler to compile, and it > will require humongous amounts of memory to do so (memory which may or > may not be available for the task). The modular approach is by far more > economical in that aspect as well. The sources of firefox, one of the biggest program, are 50 MB. I have 32 GB of RAM in this old computer, ie. 3 order of magnitude more. -- __Pascal J. Bourguignon__ http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@wont.tell> |
|---|---|
| Date | 2019-01-25 12:08 +0000 |
| Message-ID | <5c4afc3e$0$20339$426a74cc@news.free.fr> |
| In reply to | #140227 |
On Fri, 25 Jan 2019 10:56:41 +0100, Pascal J. Bourguignon wrote: > Mateusz Viste <mateusz@wont.tell> writes: > >> 2. The "one single *.c file" you boast about is, I assume, a monolithic >> mess. As such, it will take forever for a C compiler to compile, and it >> will require humongous amounts of memory to do so (memory which may or >> may not be available for the task). The modular approach is by far more >> economical in that aspect as well. > > The sources of firefox, one of the biggest program, are 50 MB. > I have 32 GB of RAM in this old computer, ie. 3 order of magnitude more. You must certainly be aware that a compiler requires a lot more memory than source size to compile it. Few days ago I ran out of DPMI memory when trying to compile a single 400K module with DJGPP. The computer had 64 MiB of available memory, ie (as you say) orders of magnitude more. Mateusz
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-25 13:28 +0100 |
| Message-ID | <q2evdr$fi5$1@dont-email.me> |
| In reply to | #140234 |
On 25/01/2019 13:08, Mateusz Viste wrote: > On Fri, 25 Jan 2019 10:56:41 +0100, Pascal J. Bourguignon wrote: > >> Mateusz Viste <mateusz@wont.tell> writes: >> >>> 2. The "one single *.c file" you boast about is, I assume, a monolithic >>> mess. As such, it will take forever for a C compiler to compile, and it >>> will require humongous amounts of memory to do so (memory which may or >>> may not be available for the task). The modular approach is by far more >>> economical in that aspect as well. >> >> The sources of firefox, one of the biggest program, are 50 MB. >> I have 32 GB of RAM in this old computer, ie. 3 order of magnitude more. > > You must certainly be aware that a compiler requires a lot more memory > than source size to compile it. > Also, the sources for Firefox are in a great many files, not just one. (Memory becomes an issue for link-time optmised builds, as these look a lot more like monolithic builds. gcc has been making a lot of progress in scaling of LTO builds, precisely because they test on projects like Firefox and LibreOffice, and regularly use dozens of GB in the builds.) > Few days ago I ran out of DPMI memory when trying to compile a single > 400K module with DJGPP. The computer had 64 MiB of available memory, ie > (as you say) orders of magnitude more. > FreeDOS development? Is this just for fun, or do you really have to use these antiques? > Mateusz >
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@wont.tell> |
|---|---|
| Date | 2019-01-25 13:33 +0000 |
| Message-ID | <5c4b1045$0$19271$426a74cc@news.free.fr> |
| In reply to | #140236 |
On Fri, 25 Jan 2019 13:28:42 +0100, David Brown wrote: > FreeDOS development? Is this just for fun, or do you really have to use > these antiques? Not FreeDOS itself, but DOS-related toys, yes. Things like these: http://dosmid.sourceforge.net http://etherdfs.sourceforge.net http://zboy.sourceforge.net (more on my homepage) I find working with 1980-1990 technologies very refreshing. Relaxing, even. It helps one to understand what really matters in software development and focus on essentials. Sadly, nowadays many (most?) programmers display a toxic "meh, just use faster hardware" attitude. Some videos! https://youtu.be/8ssDGBTssUI https://youtu.be/aumz51RCqZ0 Mateusz
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web