Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
Writing a prgram which writes its own source to standard output is a
standard programming problem. It's called a quine.
A quine must also not process any input.
Writing a prgram which writes its own source to standard output is a
standard programming problem. It's called a quine.
And I have achieved a
quine. But a serious quine. Not contrived special purpose code, but serious codde which can be used to package up source for real.
And it's completely
portable ANSI C. So of course it can't write output to disk - that is impossible to achive portably. Instead it writes its own source to standard output using a simle XML format called FileSystem, which represents the source tree.
It's also a very superior quine, and it spits out images and binaries.
But a serious quine. Not contrived special purpose code, but
serious codde which can be used to package up source for real.
On 02/06/2024 23:17, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
Writing a prgram which writes its own source to standard output is aA quine must also not process any input.
standard programming problem. It's called a quine.
No input at compile-time or runtime?
A compiler necessarily has to have the source code of the program as input, so what are the limitations?
A C program can use #include; does that extend
to directives like #embed, or is that considered cheating?
bart <bc@freeuk.com> writes:
On 02/06/2024 23:17, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
Writing a prgram which writes its own source to standard output is aA quine must also not process any input.
standard programming problem. It's called a quine.
No input at compile-time or runtime?
The program isn't running at compile time.
A compiler necessarily has to have the source code of the program as input, >> so what are the limitations?
The compiler can do what it likes!
A C program can use #include; does that extend
to directives like #embed, or is that considered cheating?
There's nothing wrong with using either, but a C quine that uses #embed relies on knowing the name of the file in which it is stored.
It is a
"fixed point of the execution environment", but it's probably the least interesting C quine possible -- much like
1
is a quine in languages that evaluate and print an expression.
On 02/06/2024 23:17, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
Writing a prgram which writes its own source to standard output is aA quine must also not process any input.
standard programming problem. It's called a quine.
And I have achieved aYou XML-producing program may be very useful, but it's not really a
quine. But a serious quine. Not contrived special purpose code, but serious >>> codde which can be used to package up source for real.
quine, serious or otherwise.
And it's completelyThat sounds as if the program reads input (but it's not explicitly
portable ANSI C. So of course it can't write output to disk - that is
impossible to achive portably. Instead it writes its own source to standard >>> output using a simle XML format called FileSystem, which represents the
source tree.
stated) as well as not producing the program text but some XML
representation of the program text. That would make it not a quine for
two reasons.
How do you process a source tree in completely portable ANSI C?
The FileSystem XML fie is embedded with the program. It is a genuine
quine. Compile it and see.
It's also a very superior quine, and it spits out images and binaries.
On 03/06/2024 10:31, Ben Bacarisse wrote:
bart <bc@freeuk.com> writes:
On 02/06/2024 23:17, Ben Bacarisse wrote:The program isn't running at compile time.
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
Writing a prgram which writes its own source to standard output is a >>>>> standard programming problem. It's called a quine.A quine must also not process any input.
No input at compile-time or runtime?
A compiler necessarily has to have the source code of the program as input, >>> so what are the limitations?The compiler can do what it likes!
A C program can use #include; does that extendThere's nothing wrong with using either, but a C quine that uses #embed
to directives like #embed, or is that considered cheating?
relies on knowing the name of the file in which it is stored.
I assume you can use __FILE__ with #embed? (I can do that with my version
of it).
Then it doesn't need to know the actual name of the file.
It is a
"fixed point of the execution environment", but it's probably the least
interesting C quine possible -- much like
1
is a quine in languages that evaluate and print an expression.
Not really.
I've just added this line:
puts(strinclude(__FILE__));
bart <bc@freeuk.com> writes:
On 03/06/2024 10:31, Ben Bacarisse wrote:
There's nothing wrong with using either, but a C quine that uses #embed
relies on knowing the name of the file in which it is stored.
I assume you can use __FILE__ with #embed? (I can do that with my version
of it).
Then it doesn't need to know the actual name of the file.
I don't know if that is guaranteed by the standard as I've not really
looked at C23, but if is it, that would be a way to write a (rather
boring) quine in C23.
It is a
"fixed point of the execution environment", but it's probably the least
interesting C quine possible -- much like
1
is a quine in languages that evaluate and print an expression.
Not really.
What part are you objecting to?
That the above (a C quine using #embed)
in not a fixed point of the execution environment? That it's not an uninteresting quine? Or that it's not "much like" self-evaluating
expression quines?
You said "not really" in reply to a moderately complex paragraph.
I've just added this line:
puts(strinclude(__FILE__));
I think I'm missing your point. That does input at run-time (if my
guess about strinclude is correct).
Writing a prgram which writes its own source to standard output is a
standard programming problem. It's called a quine.
On Sun, 2 Jun 2024 12:54:17 +0100
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
Writing a prgram which writes its own source to standard output is a
standard programming problem. It's called a quine.
Is it named after Willard Van Orman Quine?
On 03/06/2024 12:58, Ben Bacarisse wrote:
What part are you objecting to?
That it is not very interesting. Using #embed applied to a program's
only source code I think opens up some intriguing possibilities.
Whereas a pure quine, which can require ingenuity, to me is just a puzzle.
On 03/06/2024 12:58, Ben Bacarisse wrote:
bart <bc@freeuk.com> writes:
On 03/06/2024 10:31, Ben Bacarisse wrote:
I don't know if that is guaranteed by the standard as I've not reallyThere's nothing wrong with using either, but a C quine that uses #embed >>>> relies on knowing the name of the file in which it is stored.
I assume you can use __FILE__ with #embed? (I can do that with my version >>> of it).
Then it doesn't need to know the actual name of the file.
looked at C23, but if is it, that would be a way to write a (rather
boring) quine in C23.
What part are you objecting to?It is a
"fixed point of the execution environment", but it's probably the least >>>> interesting C quine possible -- much like
1
is a quine in languages that evaluate and print an expression.
Not really.
That it is not very interesting.
Using #embed applied to a program's only
source code I think opens up some intriguing possibilities.
Whereas a pure quine, which can require ingenuity, to me is just a
puzzle.
puts(strinclude(__FILE__));
I think I'm missing your point. That does input at run-time (if my
guess about strinclude is correct).
'strinclude' is the equivalent of #embed.
bart <bc@freeuk.com> writes:
puts(strinclude(__FILE__));
I think I'm missing your point. That does input at run-time (if my
guess about strinclude is correct).
'strinclude' is the equivalent of #embed.
So this is not C. In comp.lang.c, when a line is very C-like, the fact
that it's not C should be flagged.
On 03/06/2024 14:55, Ben Bacarisse wrote:
bart <bc@freeuk.com> writes:
So this is not C. In comp.lang.c, when a line is very C-like, the factputs(strinclude(__FILE__));
I think I'm missing your point. That does input at run-time (if my
guess about strinclude is correct).
'strinclude' is the equivalent of #embed.
that it's not C should be flagged.
I mentioned that particular extension of mine quite a few times in the thread.
The program isn't running at compile time.
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
bart <bc@freeuk.com> writes:
[...]
I assume you can use __FILE__ with #embed? (I can do that with my
version of it).
Yes, but not reliably.
__FILE__ expands to "The presumed name of the current source file (a
character string literal)". That's rather vague.
With gcc and clang, it expands to the file name argument given to the
compiler, or to the argument of the #include directive. The running
program may or may not be able to access the source file using that
name. The source file might not even exist when the program runs.
I was thinking of using __FILE__ to access the source file at run time. #embed is of course handled at compile time. It's very likely, but
still not quite guaranteed, that `#embed __FILE__` will be able to
access the source file.
On Mon, 03 Jun 2024 10:31:30 +0100, Ben Bacarisse wrote:
The program isn't running at compile time.
That would depend on the language.
On 03/06/2024 14:47, Ben Bacarisse wrote:
Michael S <already5chosen@yahoo.com> writes:
On Sun, 2 Jun 2024 12:54:17 +0100In honour of rather than after since "after" is usually used for
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
Writing a prgram which writes its own source to standard output is a
standard programming problem. It's called a quine.
Is it named after Willard Van Orman Quine?
discoverers. It was Douglas Hofstadter who coined the term.
/* source for a quine */
On 03/06/2024 13:11, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:It's not therortically interesting from a computer science perspective.
On 02/06/2024 23:17, Ben Bacarisse wrote:No need; I'll take your word for it.
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
Writing a prgram which writes its own source to standard output is a >>>>> standard programming problem. It's called a quine.A quine must also not process any input.
And I have achieved aYou XML-producing program may be very useful, but it's not really a
quine. But a serious quine. Not contrived special purpose code, but serious
codde which can be used to package up source for real.
quine, serious or otherwise.
And it's completelyThat sounds as if the program reads input (but it's not explicitly
portable ANSI C. So of course it can't write output to disk - that is >>>>> impossible to achive portably. Instead it writes its own source to standard
output using a simle XML format called FileSystem, which represents the >>>>> source tree.
stated) as well as not producing the program text but some XML
representation of the program text. That would make it not a quine for >>>> two reasons.
How do you process a source tree in completely portable ANSI C?
The FileSystem XML fie is embedded with the program. It is a genuine
quine. Compile it and see.
It's also a very superior quine, and it spits out images and binaries.If it's a quine (and I don't doubt you) then is spits out its own source
code. That can, of course, include source code encodings of images.
I'm not sure why you consider that superior, but that is, after all, a
rather subjective assessment.
You can encode images as source.
But from a practical point of view, yes my quine is massively
powerful. Most graphical programs do have images as source. And they just
get zipped up into the FileSystem XML file. So any binary data can be included. Easily, Using exactly the same system.
On 04/06/2024 14:40, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
Because you've got the binary, but not the source.
I'm not getting it. Why do I want a quine in connection to a graphical
program? I want a way to include everything in the distribution, but
we've had that for ages. Why is having a program that outputs something
you already have (by defintion!) of any use?
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On 03/06/2024 13:11, Ben Bacarisse wrote:
But from a practical point of view, yes my quine is massively
powerful. Most graphical programs do have images as source. And they just
get zipped up into the FileSystem XML file. So any binary data can be
included. Easily, Using exactly the same system.
I'm not getting it. Why do I want a quine in connection to a graphical program? I want a way to include everything in the distribution, but
we've had that for ages. Why is having a program that outputs something
you already have (by defintion!) of any use?
On 04/06/2024 14:33, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:Yes. Tht's the heart of it.
On 03/06/2024 14:47, Ben Bacarisse wrote:
Michael S <already5chosen@yahoo.com> writes:
On Sun, 2 Jun 2024 12:54:17 +0100In honour of rather than after since "after" is usually used for
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
Writing a prgram which writes its own source to standard output is a >>>>>> standard programming problem. It's called a quine.
Is it named after Willard Van Orman Quine?
discoverers. It was Douglas Hofstadter who coined the term.
/* source for a quine */
There seems to be loads missing. How big it the program when it's all
there or, since it's a quine, what is the size of text it outputs?
I'll start a quine project. But I need to get the babyxfs_shell to a
rather more developed state first to really give bbx_filesystem a good
test and stabilise it.
The power of BabyXFS quines is that you can just package an arbitrary
program as a quine. Because babyxfs_dirtoxml will simply package up any source directory for passing to bbx_filesystem_quine.
So the idea is that when you have BabyXFS incorporated, it is trivially
easy to make your program into a quine, and, for open source, that is
exactly what you need.
On 04/06/2024 14:40, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On 03/06/2024 13:11, Ben Bacarisse wrote:
But from a practical point of view, yes my quine is massively
powerful. Most graphical programs do have images as source. And they just >>> get zipped up into the FileSystem XML file. So any binary data can be
included. Easily, Using exactly the same system.
I'm not getting it. Why do I want a quine in connection to a graphical
program? I want a way to include everything in the distribution, but
we've had that for ages. Why is having a program that outputs something
you already have (by defintion!) of any use?
My C compiler embeds the the standard headers it uses within the
executable. That makes for a tidy, run-anywhere application as it is a
single file.
On 2024-06-04 19:57:31 +0000, bart said:
On 04/06/2024 14:40, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On 03/06/2024 13:11, Ben Bacarisse wrote:
But from a practical point of view, yes my quine is massively
powerful. Most graphical programs do have images as source. And they
just
get zipped up into the FileSystem XML file. So any binary data can be
included. Easily, Using exactly the same system.
I'm not getting it. Why do I want a quine in connection to a graphical >>> program? I want a way to include everything in the distribution, but
we've had that for ages. Why is having a program that outputs something >>> you already have (by defintion!) of any use?
My C compiler embeds the the standard headers it uses within the
executable. That makes for a tidy, run-anywhere application as it is a
single file.
There are not run-anywhere applications. Each computer only runs
applications that are written in a language that it understands.
Many computers only understand one language and no language is
understood by every computer.
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
bart <bc@freeuk.com> writes:
[...]
I assume you can use __FILE__ with #embed? (I can do that with my
version of it).
Yes, but not reliably.
__FILE__ expands to "The presumed name of the current source file (a
character string literal)". That's rather vague.
With gcc and clang, it expands to the file name argument given to the
compiler, or to the argument of the #include directive. The running
program may or may not be able to access the source file using that
name. The source file might not even exist when the program runs.
I was thinking of using __FILE__ to access the source file at run time. #embed is of course handled at compile time. It's very likely, but
still not quite guaranteed, that `#embed __FILE__` will be able to
access the source file.
An operating system might refuse to open an already opened file.
Mikko <mikko.levanto@iki.fi> writes:
On 2024-06-04 00:35:25 +0000, Keith Thompson said:[...]
#embed is of course handled at compile time. It's very likely, but
still not quite guaranteed, that `#embed __FILE__` will be able to
access the source file.
An operating system might refuse to open an already opened file.
There is no good reason to refuse when all accesses are for read-only
but a supid operating system might think otherwise.
That seems unlikely, and would be a concern only if some real-world OS >actually behaved that way.
scott@slp53.sl.home (Scott Lurndal) writes:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
Mikko <mikko.levanto@iki.fi> writes:
On 2024-06-04 00:35:25 +0000, Keith Thompson said:[...]
#embed is of course handled at compile time. It's very likely, but
still not quite guaranteed, that `#embed __FILE__` will be able to
access the source file.
An operating system might refuse to open an already opened file.
There is no good reason to refuse when all accesses are for read-only
but a supid operating system might think otherwise.
That seems unlikely, and would be a concern only if some real-world OS
actually behaved that way.
IIRC windows has some restrictions on when a file can be opened vis
a vis other processes also having it open.
But I don't do windows and my recollection could be faulty.
My understanding is that there can be one writer or multiple readers.
That wouldn't affect `#embed __FILE__`. Allowing only one reader would
break a *lot* of functionality.
On 04/06/2024 14:33, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:Yes. Tht's the heart of it.
On 03/06/2024 14:47, Ben Bacarisse wrote:There seems to be loads missing. How big it the program when it's all
Michael S <already5chosen@yahoo.com> writes:
On Sun, 2 Jun 2024 12:54:17 +0100In honour of rather than after since "after" is usually used for
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
Writing a prgram which writes its own source to standard output is a >>>>>> standard programming problem. It's called a quine.
Is it named after Willard Van Orman Quine?
discoverers. It was Douglas Hofstadter who coined the term.
/* source for a quine */
there or, since it's a quine, what is the size of text it outputs?
I'll start a quine project.
I don't know what you are interested in, but a pure ANSI C shell would be right up your street, I would have thought.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 03:43:21 |
| Calls: | 10,386 |
| Calls today: | 1 |
| Files: | 14,057 |
| Messages: | 6,416,596 |