Re: Making an .exe that executes source file inside itself.
On Wednesday, 25 April 2018 at 19:19:58 UTC, BoQsc wrote: So there has been idea I've got for around few months now: making a software which executable would contain a source file. A software that anyone could modify by opening an executable and quickly change a few lines of it, rerun an executable, see the changes. Could this be easily possible with D language, considering that sources files can be ran without long slow compilation process? I had a similar idea a few months ago too, coincidence? The idea is that all apps have the source code embedded so that they can be debugged and modified by the user at will. Each app has a built in IDE and debugger(or can trigger an external one for space). When an error occurs it will jump to the debugger for debugging purposes. If some functionality is to be modified(e.g., change the size of a button or add some new feature) the user can trigger the IDE(hot key) to proceed. The point of having it all self contained is to allow future revision and debugging without having to worry about version issues. The point of the debugging is so the user can fix bugs that plague software. While on the whole most software may work for most users, it is very annoying when some minor bug prevents a program from working for a specific user. Many more people know how to program than ever and it will only become more and more common. Also, with such capabilities, the user can add additional functionality. It is very annoying when programs don't support simple stuff. A few lines of code could make the program much more effective for a user that wants to do something that was not thought of if they could just add it. e.g., even just display something, change the location of a widget, or modify how a text file is read so it can support a new format. One can argue that platforms such as Linux make this easy... but only marginally. If one get actually get the code to compile without having to waste many hours, one must also generally sift through the code to find the relevant parts then try and understand them. Usually because of the trial and error process is long this generally is a deterrent for "normal" people with "normal" lives. If apps are properly structured with such goals in mind then it would be of great benefit, although only a few of us like you and me have the wherewithal to extrapolate out. It would not be difficult to do(it is more about organization than about technological problem solving). With proper ide design, debugger, and such, one could make app writing self contained, so to speak. That is, the IDE and debugger are used directly to write the program instead of using the traditional methods such as vim, emacs, visual studio, coedit, etc. What is packaged in an binary are the IDE Debugger Profiling Source Code(with history, VCS included) Compiled Code(possibly optimized version) Debugging Data Scripting Generally, without debugging, the executable just runs the compiled code as if it were a normal app. When triggered, the ide/debugger can be brought up that takes over and displays the desired source code(triggers can be used). I believe the main issues for proper development would be the ability for quick code replacement(hot swapping, injection, etc) which is tricky since some code would require a full restart which will slow things down. Most of the other programs are just gluing everything together and providing certain mechanisms that allow for robustness such as being able to replace the IDE or debugger, extract the source code for repackaging. While it would be time consuming to implement well it would be very useful. There are many many times I have used programs that simply do not function correctly or are missing simple functionality that would take me a just a few minutes to write a few lines of code to fix. Having the above would make it possible to do. One could also then "upload" patches/fixes/enhancements to the cloud or download others. This way people can tailor applications to their own use rather than being stuck with what the developers(which generally are somewhat clueless as their main goal is to ship the product rather than provide all the functionality their users want).
Re: Making an .exe that executes source file inside itself.
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: On Wednesday, April 25, 2018 19:19:58 BoQsc via Digitalmars-d-learn wrote: So there has been idea I've got for around few months now: making a software which executable would contain a source file. A software that anyone could modify by opening an executable and quickly change a few lines of it, rerun an executable, see the changes. Could this be easily possible with D language, considering that sources files can be ran without long slow compilation process? The normal way to do that is to just write a script. In the case of D, you can just use rdmd to do it. e.g. if you're on a POSIX system, just put #!/usr/bin/env rdmd at the top of your .d file and chmod it so that it's executable, and it'll run like any other script. - Jonathan M Davis 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.
Re: Using an external Assembler with D
On Wednesday, 25 April 2018 at 15:25:42 UTC, Stefan Koch wrote: Pass stuff on the stack ;) and use extern (C) functions. Thanks! What about extern (D)? Is there a big chaos in the D ABI under x86?
Re: Sense check: construction / deconstruction
On Wednesday, 25 April 2018 at 13:52:16 UTC, Steven Schveighoffer wrote: [...] Great, thanks for you help Steve, I'll have a think about how I want to structure things. Jordan
Re: Making an .exe that executes source file inside itself.
On Wednesday, 25 April 2018 at 19:43:31 UTC, Jonathan M Davis wrote: On Wednesday, April 25, 2018 19:19:58 BoQsc via Digitalmars-d-learn wrote: So there has been idea I've got for around few months now: making a software which executable would contain a source file. A software that anyone could modify by opening an executable and quickly change a few lines of it, rerun an executable, see the changes. Could this be easily possible with D language, considering that sources files can be ran without long slow compilation process? The normal way to do that is to just write a script. In the case of D, you can just use rdmd to do it. e.g. if you're on a POSIX system, just put #!/usr/bin/env rdmd at the top of your .d file and chmod it so that it's executable, and it'll run like any other script. - Jonathan M Davis 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.
Re: Making an .exe that executes source file inside itself.
On Wednesday, April 25, 2018 19:19:58 BoQsc via Digitalmars-d-learn wrote: > So there has been idea I've got for around few months now: making > a software which executable would contain a source file. > A software that anyone could modify by opening an executable and > quickly change a few lines of it, rerun an executable, see the > changes. > > Could this be easily possible with D language, considering that > sources files can be ran without long slow compilation process? The normal way to do that is to just write a script. In the case of D, you can just use rdmd to do it. e.g. if you're on a POSIX system, just put #!/usr/bin/env rdmd at the top of your .d file and chmod it so that it's executable, and it'll run like any other script. - Jonathan M Davis
Re: Get files from directory sorted by name
On Wednesday, 25 April 2018 at 17:34:41 UTC, Dr.No wrote: Is there something implemented already to get the files from directory by name using D or I'm on my own and I have to write it myself? I didn't find how do that with dirEntries() I want to add that sorting can be done, if you just call std.algorithm.sort you'll find that file names with numbers in them will be sorted as a well strings. Newfile1.txt Newfile10.txt Newfile2.txt
Making an .exe that executes source file inside itself.
So there has been idea I've got for around few months now: making a software which executable would contain a source file. A software that anyone could modify by opening an executable and quickly change a few lines of it, rerun an executable, see the changes. Could this be easily possible with D language, considering that sources files can be ran without long slow compilation process?
Re: Get files from directory sorted by name
On Wednesday, April 25, 2018 17:34:41 Dr.No via Digitalmars-d-learn wrote: > Is there something implemented already to get the files from > directory by name using D or I'm on my own and I have to write it > myself? I didn't find how do that with dirEntries() There is nothing in the standard library for doing it, though maybe someone has something on code.dlang.org. However, the underlying OS API doesn't exactly conform well to that particular use case. AFAIK, given how the C APIs work, the only option is to get the list of files and then sort it, which could be done easily enough with dirEntries. Something as simple as auto files = dirEntries(dir, SpanMode.shallow).array(); sort!((a, b) => a.name < b.name)(files); would give you a sorted DirEntry[] of all of the directories and files directly in the directory. SpanMode.depth or SpanMode.breadth could be used instead if you want sub-directories, and std.algorithm.iteration.filter could be used if you want to do something like filter out directories. std.algorithm.iteration.map could be used if you just want the file names. So, if you wanted just the names, you could do auto files = dirEntries(dir, SpanMode.shallow).map!(a => a.name)().array(); sort(files); though you'd need to use std.path.baseName if you didn't want the full path - e.g. map!(a => a.name.baseName)(). If you wanted just files, you could do something like auto files = dirEntries(dir, SpanMode.shallow). filter!(a => a.isFile()).array(); sort!((a, b) => a.name < b.name)(files); or auto files = dirEntries(dir, SpanMode.shallow). filter!(a => a.isFile()).map!(a => a.name).array(); sort(files); Exactly which combination of functions you use depends on what you want for the end result. But the key thing is that you use std.array.array to convert the forward range into a dynamic array so that std.algorithm.sorting.sort can sort it (since it requires a random-access range). I really don't think that you're going to find any other way to do this other than someone who has written a function that just ends up doing the same thing by wrapping a call to dirEntries or the underlying C API. - Jonathan M Davis
Get files from directory sorted by name
Is there something implemented already to get the files from directory by name using D or I'm on my own and I have to write it myself? I didn't find how do that with dirEntries()
Re: Using an external Assembler with D
On Tuesday, 24 April 2018 at 21:02:07 UTC, solidstate1991 wrote: In order to make one of my own code more readable (and hopefully to avoid a lot of compiling errors under LDC, which don't happen in DMD for some reason), I'm planning to put my assembly functions into separate files for each system that needs them, mainly due to the lack of proper SIMD support, mainly due to these functions are relatively easy to implement. Here's a few questions of mine: - Can I return vectors in XMM registers and accept arguments as vectors in them? - How much is the D ABI differs on DMD and LDC for x86? I'm planning to support both (with mainly using DMD as a debug compiler for its speed), and want the most universal solution possible. Pass stuff on the stack ;) and use extern (C) functions.
Re: Are Fibers just broken in D?
On 4/24/18 10:12 PM, bitwise wrote: On Friday, 20 April 2018 at 18:58:36 UTC, Byron Moxie wrote: [...] In WIN32 it looks like its leaking memory Unless there is something I'm misunderstanding, it seems that Fibers that were not run to completion won't unroll their stack, which would mean that some destructors wouldn't be called, and possibly, some memory wouldn't be freed: https://github.com/dlang/druntime/blob/86cd40a036a67d9b1bff6c14e91cba1e5557b119/src/core/thread.d#L4142 Could this have something to do with the problem? I think that's not the case. In his pathological example deeper in this thread, he's running the fibers to completion, and getting OOM error. I think the GC isn't cleaning up the fibers because it's not out of new memory to allocate yet. But the stack space isn't using GC resources, so it consumes all the actual memory in 32-bit land before the GC is ever run. -Steve
Re: Sense check: construction / deconstruction
On 4/25/18 5:51 AM, Jordan Wilson wrote: On Tuesday, 24 April 2018 at 23:49:14 UTC, Steven Schveighoffer wrote: In the second case (b), you aren't including the db by value, so no destructor is called from the GC. But this is dangerous, because db stops existing after main exits, but b continues to exist in the GC, so this is a dangling pointer. If I set the pointer to null, before (b) is collected, would that work? More importantly, set it to null before Database goes out of scope. This is what I'd recommend (if you want to go this path): auto b = new B(); scope(exit) b.db = null; But I don't know why you wouldn't just use scoped. In the third case, scoped specifically destroys c when main exits, and you are not in the GC at that point. What the error message is telling you is you should manually clean up the database directly instead of leaving it to the GC. What is the correct path? probably the scoped!A version. Though I'm not sure what making copies of the database does in that library. Ok I'll need to read the docs on scoped I think, but I think I understand. If I wanted db to be persistent, but have temporary objects reference db without triggering GC collection of the db, you would use scoped? Or is this a situation where it's better to pass the db in function calls to objects rather than set as a member of these objects? In that case, using a pointer is OK, as long as you put the DB in thread local storage (so it doesn't go out of scope). Just put it at module level somewhere. In my projects, I have a pool of connections that is used, and the pool is in TLS. When I want a connection, I just grab the next one available, and it's reference counted, so it's released back to the pool automatically whenever anything goes out of scope. However, all my types are structs, and I don't put them on the GC. -Steve
Re: Implicit Template Parameters Cannot Decipher Aliases?
On Wednesday, 25 April 2018 at 11:26:40 UTC, Vijay Nayar wrote:
On Wednesday, 25 April 2018 at 10:25:11 UTC, Simen Kjærås wrote:
In the general case, the issue is unsolvable, since the
relationship between template parameters and alias results may
be arbitrarily complex. A simple degenerate case is this:
Ok, wow, you weren't kidding. That becomes really complex
really fast.
In that case, is the general rule of thumb that programmers
should not use aliases for templated types when specifying
template function parameters? No implicit type inference is
done on the return type or on local variables, so these alias
seem fine enough there. Or should they just be entirely avoided
to avoid these kinds of problems?
Right now, yeah, that's probably the most sensible rule to follow.
If someone were to write a DIP, the simple cases (which I'd guess
constitute >90% of realistic use cases) could be handled. It
would have to be somewhat limited, and identifying a sensible set
of limitations would be an important part of the work.
I'm not sure exactly what's the best way to implement this -
maybe a lowering from
auto foo(T)(Vector3!T arg) {}
to
auto foo(T)(Vector!(T,3) arg) {}
That would only work if there's a single overload and no static
ifs involved. For a solution that works with static ifs or
overloads, something must be done about how the matching itself
works.
On Wednesday, 25 April 2018 at 11:42:12 UTC, ag0aep6g wrote:
https://issues.dlang.org/show_bug.cgi?id=1807
Thanks. :)
--
Simen
Re: Implicit Template Parameters Cannot Decipher Aliases?
On 04/25/2018 12:25 PM, Simen Kjærås wrote: It's a known issue, and could be solved in some cases by partial template expansion, which is currently not part of the language. I believe it's in bugzilla somewhere, but a cursory search yielded no results. https://issues.dlang.org/show_bug.cgi?id=1807
Re: Warning on self assignment
On Wednesday, April 25, 2018 02:32:32 Per Nordlöw via Digitalmars-d-learn wrote: > On Wednesday, 25 April 2018 at 02:23:04 UTC, Mike Franklin wrote: > > Are people using self assignment of structs as a way of > > force-running the postblit? Is there a valid use case for that? > > > > Mike > > If they are, there should be a better way of force-running the > postblit. Under what circumstances would it be reasonable to force the postblit to run? Certainly, under any kind of normal circumstances, the postblit constructor should only be run as a result of the object being copied - which the compiler controls. - Jonathan M Davis
Re: Implicit Template Parameters Cannot Decipher Aliases?
On Wednesday, 25 April 2018 at 10:25:11 UTC, Simen Kjærås wrote: In the general case, the issue is unsolvable, since the relationship between template parameters and alias results may be arbitrarily complex. A simple degenerate case is this: Ok, wow, you weren't kidding. That becomes really complex really fast. In that case, is the general rule of thumb that programmers should not use aliases for templated types when specifying template function parameters? No implicit type inference is done on the return type or on local variables, so these alias seem fine enough there. Or should they just be entirely avoided to avoid these kinds of problems?
Re: Warning on self assignment
On Wednesday, 25 April 2018 at 03:32:09 UTC, Meta wrote: On Wednesday, 25 April 2018 at 02:32:32 UTC, Per Nordlöw wrote: On Wednesday, 25 April 2018 at 02:23:04 UTC, Mike Franklin wrote: Are people using self assignment of structs as a way of force-running the postblit? Is there a valid use case for that? Mike If they are, there should be a better way of force-running the postblit. You can call __postblit or __xpostblit (I think the latter is a postblit introduced via a mixin or template mixin). Thanks
Re: Implicit Template Parameters Cannot Decipher Aliases?
On Wednesday, 25 April 2018 at 07:39:28 UTC, Vijay Nayar wrote:
I have encountered a problem where whenever I attempt to use a
templated function with alias that partially limits the type of
the arguments, the program fails to compile. But if I avoid
using an alias, the same function can infer all arguments.
Is this working as intended or have I encountered a bug or
missing feature?
It's a known issue, and could be solved in some cases by partial
template expansion, which is currently not part of the language.
I believe it's in bugzilla somewhere, but a cursory search
yielded no results.
In the general case, the issue is unsolvable, since the
relationship between template parameters and alias results may be
arbitrarily complex. A simple degenerate case is this:
alias Foo(T) = string;
T fun(T)(Foo!T a) { return T.init; }
unittest {
// What's val's type?
auto val = fun("");
}
Since in this case Foo!T retains no information about T, it's
impossible to figure out what T should be. In a more realistic
case, where the alias template body includes static ifs, or there
are overloads, the relationship is also hard to trace:
template Foo(T) if (T.sizeof < 4) {
alias T[T.sizeof] Foo;
}
template Foo(T) if (T.sizeof >= 4) {
alias T[T.sizeof/2] Foo;
}
T fun(T)(Foo!T a) { return T.init; }
unittest {
int[2] a;
auto val = fun(a);
}
Sure, for a human it's easy to figure out which overload is the
right one, but defining the rules such that the compiler can
reliably do it is harder.
--
Simen
Re: Sense check: construction / deconstruction
On Tuesday, 24 April 2018 at 23:49:14 UTC, Steven Schveighoffer wrote: What you are missing is that Database is pass-by-value, not a class. So when you include it directly in a class like you did in A, then when A's destructor is called, db's destructor is called. Since in the first case, a is being destroyed by the GC, you get the error. Ok, this makes sense. In the second case (b), you aren't including the db by value, so no destructor is called from the GC. But this is dangerous, because db stops existing after main exits, but b continues to exist in the GC, so this is a dangling pointer. If I set the pointer to null, before (b) is collected, would that work? In the third case, scoped specifically destroys c when main exits, and you are not in the GC at that point. What the error message is telling you is you should manually clean up the database directly instead of leaving it to the GC. What is the correct path? probably the scoped!A version. Though I'm not sure what making copies of the database does in that library. -Steve Ok I'll need to read the docs on scoped I think, but I think I understand. If I wanted db to be persistent, but have temporary objects reference db without triggering GC collection of the db, you would use scoped? Or is this a situation where it's better to pass the db in function calls to objects rather than set as a member of these objects?
Re: Implicit Template Parameters Cannot Decipher Aliases?
On Wednesday, 25 April 2018 at 07:39:28 UTC, Vijay Nayar wrote: addAllWithAlias(v1); // Error! One more note, this following line works correctly. addAllWithAlias!double(v1); // OK.
Implicit Template Parameters Cannot Decipher Aliases?
I have encountered a problem where whenever I attempt to use a
templated function with alias that partially limits the type of
the arguments, the program fails to compile. But if I avoid
using an alias, the same function can infer all arguments.
Is this working as intended or have I encountered a bug or
missing feature?
Example below:
```
/**
* Demonstrate an unexpected compiler error when using implicit
template parameters
* combined with aliases to partially instantiate templates.
*/
struct Vector(ElemT, size_t SizeV) {
private:
ElemT[SizeV] _data;
public:
@property
ElemT[SizeV] data() {
return _data;
}
ElemT opIndex(size_t i) {
return _data[i];
}
}
// A helper alias to partially set a portion of compile-time
arguments.
template Vector3(ElemT) {
alias Vector3 = Vector!(ElemT, 3);
}
T addAllWithAlias(T)(Vector3!T v1) {
T sum = 0;
foreach (T v; v1.data) {
sum += v;
}
return sum;
}
T addAll(T)(Vector!(T, 3) v1) {
T sum = 0;
foreach (T v; v1.data) {
sum += v;
}
return sum;
}
void main() {
auto v1 = Vector3!double([1.0, 2.0, 3.0]);
assert(v1[1] == 2.0);
addAllWithAlias(v1); // Error!
// template.d(35): Error: template template.addAllWithAlias
cannot deduce function from
// argument types !()(Vector!(double, 3LU)), candidates are:
// template.d(24):
template.addAllWithAlias(T)(Vector3!T v1)
addAll(v1); // OK.
}
```
Re: Warning on self assignment
On Wednesday, April 25, 2018 02:23:04 Mike Franklin via Digitalmars-d-learn
wrote:
> On Wednesday, 25 April 2018 at 01:08:46 UTC, Arun Chandrasekaran
>
> wrote:
> > So I was telling my colleague that D would warn on self
> > assignment, but found that I was wrong.
> >
> > https://run.dlang.io/is/HLhtek
> >
> > ```
> > module a;
> >
> > import std.stdio;
> >
> > void main() {
> >
> > string a;
> > a = a; // Can the compiler warn at this line that
> >
> > there is no effect?
> >
> > writeln(a);
> > return;
> >
> > }
> > ```
>
> Are people using self assignment of structs as a way of
> force-running the postblit? Is there a valid use case for that?
I would be _very_ surprised if there were a valid reason to do that. That
being said, it's not necessarily true that
a = a;
has no effect. In the case of string that's basically true, but if the type
has a postblit constructor, then it definitely can have an effect (e.g. it
allocates memory or prints out that the object was copied). I don't think
that it's at all likely to have a desirable effect, and I would expect for
it to be fine for
a = a;
to be deprecated and then turned into an error on the grounds that there
isn't a reasonable reason to do it and is probably a bug - especially in
cases such as
this(A a, B b)
{
a = a;
b = b;
}
but it's likely untrue in the general case to say that that statement has no
effect.
- Jonathan M Davis
Re: Warning on self assignment
On Wednesday, April 25, 2018 03:32:09 Meta via Digitalmars-d-learn wrote: > On Wednesday, 25 April 2018 at 02:32:32 UTC, Per Nordlöw wrote: > > On Wednesday, 25 April 2018 at 02:23:04 UTC, Mike Franklin > > > > wrote: > >> Are people using self assignment of structs as a way of > >> force-running the postblit? Is there a valid use case for > >> that? > >> > >> Mike > > > > If they are, there should be a better way of force-running the > > postblit. > > You can call __postblit or __xpostblit (I think the latter is a > postblit introduced via a mixin or template mixin). I seriously question that it's ever a good idea to call either, but __postblit is the actual postblit constructor declared in the struct, and __xpostblit is the function that deals with calling the postblit constructor on all of the member variables and then calling __postblit. - Jonathan M Davis
