Discussion:
Writing own source disk
Add Reply
Malcolm McLean
2024-06-02 11:54:17 UTC
Reply
Permalink
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.

And it's very exciting and the very first program has just been written,
and its on the Baby X resource compiler guthub repository, and I
encourage eveyone to get involved. I've achieved the goal. Now
everything needs to be packaged up and presented to make it easy to use.

But this is a fantastic direction for the resource compiler.


https://github.com/MalcolmMcLean/babyxrc
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm
Ben Bacarisse
2024-06-02 22:17:04 UTC
Reply
Permalink
Post by Malcolm McLean
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.
Post by Malcolm McLean
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.
You XML-producing program may be very useful, but it's not really a
quine, serious or otherwise.
Post by Malcolm McLean
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.
That sounds as if the program reads input (but it's not explicitly
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?
--
Ben.
Malcolm McLean
2024-06-02 23:09:15 UTC
Reply
Permalink
Post by Ben Bacarisse
Post by Malcolm McLean
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.
Post by Malcolm McLean
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.
You XML-producing program may be very useful, but it's not really a
quine, serious or otherwise.
Post by Malcolm McLean
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.
That sounds as if the program reads input (but it's not explicitly
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.

You can't generate a FileSystem XML file with portable ANSI C, and you
can' write one out to a disk. But eveything else is done portably, and
it is a portable quine.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm
Lawrence D'Oliveiro
2024-06-02 23:19:25 UTC
Reply
Permalink
Post by Malcolm McLean
It's also a very superior quine, and it spits out images and binaries.
Like a self-building Linux distro does?
Ben Bacarisse
2024-06-03 12:11:24 UTC
Reply
Permalink
Post by Ben Bacarisse
Post by Ben Bacarisse
Post by Malcolm McLean
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.
Post by Malcolm McLean
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.
You XML-producing program may be very useful, but it's not really a
quine, serious or otherwise.
Post by Malcolm McLean
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.
That sounds as if the program reads input (but it's not explicitly
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.
No need; I'll take your word for it.
Post by Ben Bacarisse
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.
--
Ben.
Malcolm McLean
2024-06-03 23:41:28 UTC
Reply
Permalink
Post by Ben Bacarisse
Post by Ben Bacarisse
Post by Ben Bacarisse
Post by Malcolm McLean
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.
Post by Malcolm McLean
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.
You XML-producing program may be very useful, but it's not really a
quine, serious or otherwise.
Post by Malcolm McLean
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.
That sounds as if the program reads input (but it's not explicitly
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.
No need; I'll take your word for it.
Post by Ben Bacarisse
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.
It's not therortically interesting from a computer science perspective.
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.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm
Ben Bacarisse
2024-06-04 13:40:24 UTC
Reply
Permalink
Post by Malcolm McLean
Post by Ben Bacarisse
Post by Ben Bacarisse
Post by Ben Bacarisse
Post by Malcolm McLean
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.
Post by Malcolm McLean
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.
You XML-producing program may be very useful, but it's not really a
quine, serious or otherwise.
Post by Malcolm McLean
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.
That sounds as if the program reads input (but it's not explicitly
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.
No need; I'll take your word for it.
Post by Ben Bacarisse
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.
It's not therortically interesting from a computer science perspective.
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.
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?
--
Ben.
Malcolm McLean
2024-06-04 18:45:07 UTC
Reply
Permalink
Post by Ben Bacarisse
Post by Malcolm McLean
Post by Ben Bacarisse
Post by Ben Bacarisse
Post by Ben Bacarisse
Post by Malcolm McLean
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.
Post by Malcolm McLean
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.
You XML-producing program may be very useful, but it's not really a
quine, serious or otherwise.
Post by Malcolm McLean
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.
That sounds as if the program reads input (but it's not explicitly
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.
No need; I'll take your word for it.
Post by Ben Bacarisse
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.
It's not therortically interesting from a computer science perspective.
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.
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?
Because you've got the binary, but not the source. And whilst it is a
quine, of course it is only a quine when you pass it the -quine option.
Otherwise it is Space Invaders. But if you nedd to recompile the program
for a new target, -quine spits out the source.

BabyXFS quines are serious quines, they have a real purpose.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm
Scott Lurndal
2024-06-04 19:23:06 UTC
Reply
Permalink
Post by Malcolm McLean
Post by Ben Bacarisse
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?
Because you've got the binary, but not the source.
The binary is not portable, its limited to a specific processor
and operating system version.
bart
2024-06-04 19:57:31 UTC
Reply
Permalink
Post by Ben Bacarisse
Post by Malcolm McLean
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.

Most users will not need to see or use the discrete headers. But if
somebody does, there is an option to extract them:

mcc -writeheaders

I suppose this could have been widened to include its own source, but
that would be less useful.

In either case, I don't think 'quine' is a good term for it. Nor for
what it sounds like Malcolm has achieved.

AFAICS, pure quines are not intended to have any practical use at all.
Mikko
2024-06-05 08:13:24 UTC
Reply
Permalink
Post by bart
Post by Ben Bacarisse
Post by Malcolm McLean
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.
--
Mikko
bart
2024-06-05 08:23:21 UTC
Reply
Permalink
Post by Mikko
Post by bart
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.
I mean run anywhere within a computer's file system: any folder, any
drive, any memory stick.

For a run-anywhere cross-platform version of my C compiler, I can supply
a single .c file instead of .exe file.

Then it'll need a local build process in order to produce a suitable
binary. (But since it still targets Win64 ABI, that is not so useful for
that application.)

Alternately I can supply a IL (intermediate language) version, which can
be cross-platform with an interpreter. Then you will need a suitable
interpreter, so it's back to square one, however the interpreter is a
1/4 the size of the compiler, and it will also run multiple different
applications once ported.
bart
2024-06-02 23:10:15 UTC
Reply
Permalink
Post by Ben Bacarisse
Post by Malcolm McLean
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? A C program can use #include; does
that extend to directives like #embed, or is that considered cheating?
Malcolm McLean
2024-06-03 04:16:40 UTC
Reply
Permalink
Post by bart
Post by Ben Bacarisse
Post by Malcolm McLean
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? A C program can use #include; does
that extend to directives like #embed, or is that considered cheating?
Exactly.

It's a quine. You run the progrm, and it produces its own source, as a
FileSystem .xml file. Convert to a regular diretory, and compile, and you
You will get a program wich spits out exactly the same FileSystem xml
file. So a quine.

It's here.

https://github.com/MalcolmMcLean/babyxrc/tree/master/Examples/BabyXFS

You need the entire repository if you want a play.

Youb need the

babyxfs_ tools to manipulate the FileSystem xml files.
And you need Baby X RC to pack up the Xml file into a compilEAble
C file, conventionally called source.c

(When you comile for the first time, make sure you have the real
source.c and not the place holder).

However if you you want to compile the programs, they are quines,
but only on the second generation. source.c is the first generation.

(And of course the program must not have a file called source.c that is
not a place holder for converting to xml to produce the real source.c,
or the real source.c when you convert to the first generation).
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm
Malcolm McLean
2024-06-03 04:19:27 UTC
Reply
Permalink
Post by bart
Post by Ben Bacarisse
Post by Malcolm McLean
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? A C program can use #include; does
that extend to directives like #embed, or is that considered cheating?
No. The FileSystem xml project Baby X FS (Baby X file system) was
inspired by embed, but it is my superior alternative.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm
Ben Bacarisse
2024-06-03 09:31:30 UTC
Reply
Permalink
Post by bart
Post by Ben Bacarisse
Post by Malcolm McLean
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?
The program isn't running at compile time.
Post by bart
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!
Post by bart
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.
--
Ben.
bart
2024-06-03 10:01:34 UTC
Reply
Permalink
Post by Ben Bacarisse
Post by bart
Post by Ben Bacarisse
Post by Malcolm McLean
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?
The program isn't running at compile time.
Post by bart
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!
Post by bart
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.
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.
Post by Ben Bacarisse
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__));

to the main function of a program called sql.c (combines sqlite3.c and
shell.c). When I run it (after building with my 'bcc' compiler), it
first prints 235,577 lines of its source code.

(By making this optional, it has some real use-cases.)
Ben Bacarisse
2024-06-03 11:58:08 UTC
Reply
Permalink
Post by Ben Bacarisse
Post by bart
Post by Ben Bacarisse
Post by Malcolm McLean
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?
The program isn't running at compile time.
Post by bart
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!
Post by bart
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.
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.
Post by Ben Bacarisse
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.
puts(strinclude(__FILE__));
I think I'm missing your point. That does input at run-time (if my
guess about strinclude is correct).
--
Ben.
bart
2024-06-03 12:37:25 UTC
Reply
Permalink
Post by Ben Bacarisse
Post by Ben Bacarisse
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.
Post by Ben Bacarisse
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 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.
Post by Ben Bacarisse
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.
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. It does textual inclusion at
compile-time.

Without that line, the sql.exe executable is about 1MB. With that line
added, it's just over 9MB because that source file is just over 8MB.
bart
2024-06-03 13:50:10 UTC
Reply
Permalink
Post by bart
Post by Ben Bacarisse
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.
If I look at examples on sites like this:

https://rosettacode.org/wiki/Quine

then a common characteristic is that the a lot of source code ends up
being written twice. To me that is undesirable.

It's also not clear how easily arbitrary code (ie. that performs some
useful task) can be added.

This is one that /I/ would consider cheating:

#include <stdio.h>
main(void){printf(__FILE__);}

Here, the source must be put into a file with the same name as the
source code, that is, called:

#include <stdio.h>\nmain(void){printf(__FILE__);}

But this is also writing it twice: once inside the file, again as the
filename.
Ben Bacarisse
2024-06-03 13:55:27 UTC
Reply
Permalink
Post by bart
Post by Ben Bacarisse
Post by Ben Bacarisse
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.
Post by Ben Bacarisse
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 it is not very interesting.
Ah, OK.
Post by bart
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.
In fact, I didn't say it wasn't interesting, only that it's not an
interesting quine. Saying more about what you see as those intriguing
possibilities would be topical here.
Post by bart
Post by Ben Bacarisse
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.
--
Ben.
bart
2024-06-03 14:34:39 UTC
Reply
Permalink
Post by Ben Bacarisse
Post by bart
Post by Ben Bacarisse
Post by bart
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.
I mentioned that particular extension of mine quite a few times in the
thread. And here I said it was processed with my 'bcc' compiler, after
I'd also mentioned my version of #embed, both in connection with __FILE__.

So, it's not standard C, but I'd normally say 'not C' for examples like
this:

print strinclude($filename)

(At the moment I have one practical C compiler that supports
'strinclude', but zero that support #embed.)
Ben Bacarisse
2024-06-03 18:36:52 UTC
Reply
Permalink
Post by bart
Post by Ben Bacarisse
Post by bart
Post by Ben Bacarisse
Post by bart
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.
I mentioned that particular extension of mine quite a few times in the
thread.
I don't read all of your posts.
--
Ben.
Malcolm McLean
2024-06-03 23:35:44 UTC
Reply
Permalink
Post by bart
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.
No, it' not that hard, nce you now the trick.

The program babyfs_dirtoxml, which seem to be stable and works, writes a
directory as a FileSystem XML file. So the nautral thing to do is to use
it ot packaage up the souce, and include in inthe ptoram as a string.
However of course the string cannot include itself.

So what you do is say that there is a special file called source.c which
defines a global character pointer called "source", which points to the
source. However when you package up the directory, of course you delete
the real source.c and replace it with a small placeholder. Then you
generte the real source.c from the FileSystem XML file you havt just
created. And then you compile.

And of currsethere are tfunctions t parse an XML fileSystem file,
mnipulate the hieraxty, and write it back out.

So what you do is replace the placeholder source.c with the real one.
And then, on command, you write the source out. And it's a quine. And a
really powerful and easy to make quine. Ih's just a bit fiddly at the
moment, but I have got things working.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm
Keith Thompson
2024-06-04 00:33:14 UTC
Reply
Permalink
bart <***@freeuk.com> writes:
[...]
Post by bart
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.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+***@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
Keith Thompson
2024-06-04 00:35:25 UTC
Reply
Permalink
Post by Keith Thompson
[...]
Post by bart
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.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+***@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
David Brown
2024-06-04 07:30:53 UTC
Reply
Permalink
Post by Keith Thompson
Post by Keith Thompson
[...]
Post by bart
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.
The key question for that will be directory handling. If everything is
being done within the same directory, than I'd expect "#embed __FILE__"
to work fine. But if you are calling the compiler from a different
directory, specifying a path for the source file, that might not be
reflected in __FILE__. The result could vary between compilers.

There is also the possibility that the search path for #embed might
result in finding a different file with the same name. But I think that
would probably need specific command-line switches to specify the #embed
search path (again, this will be compiler-specific).
Mikko
2024-06-05 08:19:36 UTC
Reply
Permalink
Post by Keith Thompson
Post by Keith Thompson
[...]
Post by bart
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.
There is no good reason to refuse when all accesses are for read-only
but a supid operating system might think otherwise.
--
Mikko
Lawrence D'Oliveiro
2024-06-05 08:29:56 UTC
Reply
Permalink
Post by Mikko
An operating system might refuse to open an already opened file.
Only one in common use might do that.
Keith Thompson
2024-06-05 18:10:58 UTC
Reply
Permalink
[...]
Post by Mikko
Post by Keith Thompson
#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.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+***@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
Scott Lurndal
2024-06-05 18:23:20 UTC
Reply
Permalink
Post by Keith Thompson
[...]
Post by Mikko
Post by Keith Thompson
#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.
Keith Thompson
2024-06-05 18:26:40 UTC
Reply
Permalink
Post by Scott Lurndal
Post by Keith Thompson
[...]
Post by Mikko
Post by Keith Thompson
#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.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+***@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
David Brown
2024-06-05 19:27:19 UTC
Reply
Permalink
Post by Keith Thompson
Post by Scott Lurndal
Post by Keith Thompson
[...]
Post by Mikko
Post by Keith Thompson
#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.
Yes. It's more restrictive than on *nix systems (also on directory
deletion or renaming), but it's not unreasonable.
Post by Keith Thompson
That wouldn't affect `#embed __FILE__`. Allowing only one reader would
break a *lot* of functionality.
The only realistic issues I could imagine with "#embed __FILE__" is the
possibility of directory handling (i.e., if you compiled it as "cc
xxx/yyy.c", would __FILE__ expand to "yyy.c" or "xxx/yyy.c", and would
the correct file then be found?) or if your source was from a pipe or
shell redirection. "cat xxx.c > gcc -x c -", for example.
Lawrence D'Oliveiro
2024-06-03 23:56:43 UTC
Reply
Permalink
Post by Ben Bacarisse
The program isn't running at compile time.
That would depend on the language.
Ben Bacarisse
2024-06-04 11:10:12 UTC
Reply
Permalink
Post by Lawrence D'Oliveiro
Post by Ben Bacarisse
The program isn't running at compile time.
That would depend on the language.
I think you are trolling. Look as the question you cut to which I was
replying.
--
Ben.
Lawrence D'Oliveiro
2024-06-02 23:18:49 UTC
Reply
Permalink
Post by Malcolm McLean
But a serious quine. Not contrived special purpose code, but
serious codde which can be used to package up source for real.
apt source apt
Michael S
2024-06-03 13:04:57 UTC
Reply
Permalink
On Sun, 2 Jun 2024 12:54:17 +0100
Post by Malcolm McLean
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?
Ben Bacarisse
2024-06-03 13:47:08 UTC
Reply
Permalink
Post by Michael S
On Sun, 2 Jun 2024 12:54:17 +0100
Post by Malcolm McLean
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?
In honour of rather than after since "after" is usually used for
discoverers. It was Douglas Hofstadter who coined the term.
--
Ben.
Malcolm McLean
2024-06-04 00:18:32 UTC
Reply
Permalink
Post by Ben Bacarisse
Post by Michael S
On Sun, 2 Jun 2024 12:54:17 +0100
Post by Malcolm McLean
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?
In honour of rather than after since "after" is usually used for
discoverers. It was Douglas Hofstadter who coined the term.
/* source for a quine */

#include "bbx_filesystem.h"

int cescape_filter(FILE *fpout, FILE *fpin)
{
/* left as a little excercise for the reader */

return 0;
}

int bbx_filesystem_quine(BBX_FileSystem *bbx_fs, const char
*path_to_source, FILE *fp)
{
FILE *src_xml_fp;;
FILE *source_fp;

src_xml_fp = tmpfile();
bbx_filesystem_dump(bbx_fs, src_xml_fp);
fseek(src_xml_fp, 0, SEEK_SET);
source_fp = bbx_filesystem_fopen(bbx_fs, path_to_source, "r");
fprintf(source_fp, "char source[] = ");
cescape_filter(source_fp, src_xml_fp);
fprintf(source_fp, "\';\n");
bbx_filesystem_dump(bbx_fs, fp);
}

extern char source[];
void quine(void)
{
BBX_FileSystem *bbx_fs;

bbx_fs = bbx_filesystem();
bbx_filesystem_set(bbx_fs, source, BBX_FS_STRING);
bbx_filesystem_quine(bbx_fs, "/src/quine/source.c", stdout);
bbx_filesystem_kill(bbx_fs);
}
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm
Ben Bacarisse
2024-06-04 13:33:39 UTC
Reply
Permalink
Post by Malcolm McLean
Post by Ben Bacarisse
Post by Michael S
On Sun, 2 Jun 2024 12:54:17 +0100
Post by Malcolm McLean
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?
In honour of rather than after since "after" is usually used for
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?
--
Ben.
Malcolm McLean
2024-06-04 18:41:18 UTC
Reply
Permalink
Post by Ben Bacarisse
Post by Malcolm McLean
Post by Ben Bacarisse
Post by Michael S
On Sun, 2 Jun 2024 12:54:17 +0100
Post by Malcolm McLean
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?
In honour of rather than after since "after" is usually used for
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?
Yes. Tht's the heart of it.

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.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm
Richard Harnden
2024-06-04 20:04:30 UTC
Reply
Permalink
Post by Malcolm McLean
Post by Malcolm McLean
Post by Ben Bacarisse
Post by Michael S
On Sun, 2 Jun 2024 12:54:17 +0100
Post by Malcolm McLean
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?
In honour of rather than after since "after" is usually used for
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?
Yes. Tht's the heart of it.
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.
Sorry, but I just can't see the point. Seems like you're going tp bloat
your app just to add the quine thing.

If you want to distribute source, then there's tar, there's git clone, etc.
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
Ben Bacarisse
2024-06-06 17:00:29 UTC
Reply
Permalink
Post by Malcolm McLean
Post by Ben Bacarisse
Post by Malcolm McLean
Post by Ben Bacarisse
Post by Michael S
On Sun, 2 Jun 2024 12:54:17 +0100
Post by Malcolm McLean
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?
In honour of rather than after since "after" is usually used for
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?
Yes. Tht's the heart of it.
I'll start a quine project.
I am just more confused now. Presumably that does not matter since I
don't think you need me to know what's going on. And I am pretty sure
that whatever purpose your quine serves, it is intended to benefit users
who are not at all like me.
--
Ben.
Malcolm McLean
2024-06-06 19:24:36 UTC
Reply
Permalink
Post by Ben Bacarisse
Post by Malcolm McLean
Post by Ben Bacarisse
Post by Malcolm McLean
Post by Ben Bacarisse
Post by Michael S
On Sun, 2 Jun 2024 12:54:17 +0100
Post by Malcolm McLean
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?
In honour of rather than after since "after" is usually used for
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?
Yes. Tht's the heart of it.
I'll start a quine project.
I am just more confused now. Presumably that does not matter since I
don't think you need me to know what's going on. And I am pretty sure
that whatever purpose your quine serves, it is intended to benefit users
who are not at all like me.
I've got too much to do with the BabyXFS project.

I've got the get the shell as good as possible because it is a
FileSyatem XML file editor, and it makes the format useful. And
documentation needs writing. And I just don't have time for quines, but
there is one of the site, and you ought to be able to compile it. I got
it to work.

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.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm
Ben Bacarisse
2024-06-07 19:04:14 UTC
Reply
Permalink
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.
I wonder how you got that impression! I am happy with the wide range of
shells available to me (I've gone back to bash from zsh), and a pure C
shell is bound to be rather limited so not much fun either to use or to
write. And ANSI C (if you mean C90) has been out of date for decades.
--
Ben.
Loading...