On Friday, 27 April 2018 at 14:57:34 UTC, BoQsc wrote:
On Friday, 27 April 2018 at 04:30:32 UTC, IntegratedDimensions
wrote:
On Thursday, 26 April 2018 at 06:18:25 UTC, BoQsc wrote:
On Wednesday, 25 April 2018 at 20:44:10 UTC, u0_a183 wrote:
On Wednesday, 25 April 2018 at 19:54:26 UTC, BoQsc wrote:
On Wednesday, 25 April 2018 at 19:43:31 UTC, Jonathan M
Davis wrote:
[...]
Thank you Jonathan for a response.
I was aware of this, and it certainly perfectly works where
command line/terminal interface is the main tool to control
the system, a good example would be linux/gnu distributions
and macOS.
However in Windows while installing D language, I noticed
that .d source file extension is not associated with
neither D compiler (dmd.exe) nor D script interpretator
(rdmd.exe)
So they can't be ran directly by clicking on those, nor
they have any icons that show that these source codes are
actually executable. This is a huge problem, because people
that are not aware of D language migh be harder to
understand that source script could be executable, at least
- without help from some more experienced user.
If the purpose is to make scripts run by clicking them you
can assign a file type to .d files.
On Windows 10.
https://www.digitaltrends.com/computing/how-to-set-default-programs-and-file-types-in-windows-10/
Doing so would make the script engine the default program
instead of a text editor so you might not want to. Or maybe
assign .dxe and changing the filename before running.
Executable has executable file type for a reason - it
self-implies that the main function of the file - is to be
executed.
The problem with making source code files executable is that,
source code files, might not always be monolithic executable
code, but a part of a bigger interconnected program.
That would lead to partily working program execution, and
most of the times guess work of whether source code file was
supposed to be executed.
This is wrong. All code must be included. All library source
code is included. If this is infeasible then simply the
binaries are included. It would be no different than dynamic
linking that already exists. It doesn't create any new
problems.
Sure certain things would need to be worked out properly to
optimize the experience, but that is obvious. One can't make
everything perfect though and one shouldn't expect it...
The clear alternative would be: .exe file on which, if
rightclicked - would open context menu showing posibility of
"edit/improve this executable". Which would not create
additional problem mentioned above.
Yes, all the source code and required source code to make
everything work must be included. And where would all the code
mentioned before should be stored?
It must be stored in a an single self extracting archive, self
executing archive, that is self-implying that it is an
executable code, which means it can't be .d file extension, but
an .exe file extension. (or any other, if anyone come up with
more common or self explaining extension name)
If we use the same .d file extension on this self-executable,
self-extracting archive, it would confused people weather it is
executable or some novice programmer's written module/script.
No, it would have to be an exe on windows. an exe is basically a
self executing container. Almost all exe's only contain the
binary but they can contain data. For example, zip files can be
saved as self-unzipping executable.
It is not a big deal to package the data in the exe and make it
all work. Initially, it is not necessary to worry about. What
happens is that the actual initial binary that will run will
essentially decide what needs to be done and unpack everything
and deal with it.
You can think of the exe as a small file system that contains all
the files necessary and a binary that handles whatever needs to
be done which is run by the OS.
Several binaries in the file would be things like the
IDE/debugger and the compiled source code. If the user just wants
to run the app like any normal app then the compiled source code
would be extracted either to a temp exe file or to memory and
ran. (so the initial process just does some unpacking and passes
control)
If debugging and modification is to be done then the initial
process will have to do more work such as compile the source with
debugging symbols, special hooks, and all that. The files would
have to be extracted in memory or on disk. The ide would be ran,
etc.
For example, android apps are actually special zip files.
All of this stuff is childs play. The real work is having a
proper design that integrates everything well. Nothing would be
technically challenging but just a lot of work to get everything
done.
I do think that apps that were designed to be used this way would
need to be structured and designed in a way that makes it
conducive to debugging and modifying easily and quickly.
