Re: DMD VS2017 Support
On Sunday, 21 May 2017 at 22:47:44 UTC, Jolly James wrote: On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote: Please note that the next dmd installer will also detect VS2017 and setup directories correctly in sc.ini: https://github.com/dlang/installer/pull/227 I really like this philosophy: "It does not work, a fix is available, but it won't be rolled out (for now). Who cares about those who cannot use the broken software?" Yeah great. However its actually working, one just have to set up paths manually. Just a little inconvenience.
Re: Non-x86 targets for DMD
On Wednesday, 17 May 2017 at 22:16:35 UTC, Kagamin wrote: Can't you run it in qemu? Probably I could, might even work parallel with other stuff, especially stuff that are mainly lexical (register naming, etc). So far I studied the ARM assembly language, and it seems less scary than the x86 one, also the conditional execution might be useful with the ? : operators (if thumb isn't used).
Re: [WEKA] Calling fork() and D runtime
On Monday, 15 May 2017 at 11:33:29 UTC, Jonathan Shamir wrote:
Hey,
This is my first time writing in the D forums!
I have an application written in D that runs as a linux daemon
(some python service script is in charge of running and
daemonizing it).
This "agent" works similar to docker - a service that accepts
commands and runs in the background, and starts our application
container. The container is itself a daemon (ppid = 1) with
unshared namespaces etc.
So, normally, implementing such an application would look
something like:
1. Main "agent" process runs fork() to create a child process
(child_1). All memory is copy-on-write.
2. Child_1 malloc()s a stack, and calls clone() to create yet
another child (child_2), which will eventually become the
container pid 1.
3. Child_2 initializes the container (mounts, unshare, chroot,
etc) then eventually exec()s into the container init process.
4. child_1 exit()s, which causes child_2 to become a daemon.
5. The agent main process should wait() on the forked pid since
it's impolite to leave zombies (I do this in a thread).
The problem I encounter is with the forked process (child_1).
Here is the code I wrote handling the fork() (Note: this
functionality should really be provided by core.threads or
something, for unix environments).
```private void deferToForkProcess(int delegate() entryPoint,
Timeout timeout = Timeout.infinite) {
import core.runtime : Runtime;
import core.sys.posix.unistd : fork, pid_t;
import core.sys.posix.sys.wait;
import core.stdc.stdlib : exit;
int rc = theReactor.deferToThread({
pid_t pid = fork();
errnoEnforce(pid >= 0, "Fork failed");
// child process
if (pid == 0) {
try {
int rc = entryPoint();
exit(rc);
} catch (Throwable ex) {
try {
LOG_ERROR(ex.toString);
} catch (Throwable) {}
exit(1);
}
//assert(false);
}
// parent - wait for child to exit
int status = 0;
do {
errnoEnforce(waitpid(pid, &status, 0) != -1,
"Waitpid failed");
} while (!WIFEXITED(status));
int rc = WEXITSTATUS(status);
return rc;
}, timeout);
enforce(rc == 0, "Child process failed (rc =
%d)".format(rc));
}
```
entryPoint() returns 0, but the exit(0) raises an
OutOfMemoryError:
```0x4e6472
exit
??:0
0x4e6428
__run_exit_handlers
??:0
0x4df976
__libc_csu_fini
??:0
0x40327e
ldc.register_dso
crtstuff.c:0
0x4caee4
_d_dso_registry
??:0
0x4ccdba
_D2rt4util9container6common8xreallocFNbNiPvmZPv
??:0
0x4b873d
onOutOfMemoryError
??:0```
I tried to call Runtime.initialize() and Runtime.terminate()
surrounding the call to entryPoint(), but this didn't help. I
suspect calling initialize() was a no-op since the forked
process shares (copy-on-write) the VM space with it's parent,
that already initialized the runtime. (Note: confirmed,
initialize() returns true indicating it was already inited).
What is the correct way to handle fork() with the D runtime?
Some links to related discussions:
https://issues.dlang.org/show_bug.cgi?id=14205
http://forum.dlang.org/thread/ksqubftqniwznqbmu...@forum.dlang.org
https://issues.dlang.org/show_bug.cgi?id=14770
https://issues.dlang.org/show_bug.cgi?id=16006
https://github.com/dlang/phobos/pull/4294
https://github.com/dlang/druntime/pull/1569
Re: DMD VS2017 Support
On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote: Please note that the next dmd installer will also detect VS2017 and setup directories correctly in sc.ini: https://github.com/dlang/installer/pull/227 I really like this philosophy: "It does not work, a fix is available, but it won't be rolled out (for now). Who cares about those who cannot use the broken software?"
Re: Socket missing option: SO_REUSEPORT
On Wednesday, 21 December 2016 at 16:49:53 UTC, Damian wrote: SO_REUSEPORT is not supported on Windows. Is is supported on linux. On Windows the behavior of SO_REUSEPORT is included in SO_REUSEADDR. I submitted an issue to get this fixed for Linux. https://issues.dlang.org/show_bug.cgi?id=17416
Re: Value closures (no GC allocation)
On Sunday, 21 May 2017 at 20:25:14 UTC, Adam D. Ruppe wrote: Blah. Well, let's go ahead and formally propose the C++ syntax, our library solutions are all fat. :)
Re: Value closures (no GC allocation)
On Sunday, 21 May 2017 at 20:09:14 UTC, Stanislav Blinov wrote: is a function that is generated by the template. It accesses the frame of create(). Am I missing something? It does access the frame, but only long enough to copy the values into the struct there's no reason for that to allocate And, indeed it doesn't if you pass the object directly to another function; only when you return it does the compiler complain (which I didn't try before posting, just passing it down the function chain like in the OP). That's annoying. The mixin will have to be moved up a level. Blah. Well, let's go ahead and formally propose the C++ syntax, our library solutions are all fat.
Re: Value closures (no GC allocation)
On Sunday, 21 May 2017 at 19:43:32 UTC, Adam D. Ruppe wrote:
On Sunday, 21 May 2017 at 19:11:46 UTC, Stanislav Blinov wrote:
Looks cool, but it'd still want a GC closure, won't it?
No, it just generates the same struct you'd write manually.
That should work fine with @nogc now.
auto create() @nogc {
auto y = 11;
return lambda!(y, q{ (int x) => x+y } )();
}
Error: function create is @nogc yet it allocates closures with
the GC
This:
anon lambda() {
anon a;
// copy the values in
a.tupleof = Args[0 .. $-1];
return a;
}
is a function that is generated by the template. It accesses the
frame of create(). Am I missing something?
How recent of "now" do you mean? I've tested that with
v2.075.0-master-5222639.
Re: Value closures (no GC allocation)
On Sunday, 21 May 2017 at 19:11:46 UTC, Stanislav Blinov wrote: Looks cool, but it'd still want a GC closure, won't it? No, it just generates the same struct you'd write manually. That should work fine with @nogc now.
Re: My two cents on what D needs to be more successful...
On Sunday, 21 May 2017 at 18:29:46 UTC, Adam D. Ruppe wrote: On Sunday, 21 May 2017 at 05:52:11 UTC, Ecstatic Coder wrote: * the following *standard* libraries : Suppose I made a dmd distribution with my libraries pre-packaged (I already have libraries for most the stuff you listed)... would that work for you? Or must it come from the dlang.org site and be `std.` for it to count? I have no interest whatsoever in being in the official standard library though. Of course, using my libs is pretty trivial... download one or two files and add them to your build command, done. I understand your point, but standard libraries come along with the compiler during its installation. Let's suppose I want to use regular expressions and they would not have been not part of the std libraries. I would have to evaluate several libraries from github, after having searches on forums whether some regular expression libraries are better or more successful, or better maintained than other, etc. And I would be lucky to find a tutorial on this particular library. Moreover I would have to download this library manually along with its dependencies, etc. I know that's not that hard with dub-like tools, but this doesn't make things simpler, that's obvious. Standard libraries exist for one good reason : they are the reference implementation that everybody use by default, unless they want something especially tailored to their specific needs. So for newcomers like me, they make a HUGE difference, as they make my life simpler and easier. All tutorials use them, whether they are on the official website or not. Remember that I've programmed tens of years in C++, but just a few months of D. So I don't know anything about how to make GUI, web sites etc with D. That's new to me, and thus this gets me out of my "comfort" zone. For instance a standard GUI library would have made my life much easier. Just for the GUI, I've downloaded 7 libraries, and I've just evaluated gtkd at the moment. Dlangui seems fine too, etc. If D had a standard GUI library, and I didn't like its design, I could look for an alternative on github. But at least my first GUI program already runs without having to evaluate anything, by simply reading the official tutorials and documentations. For smarter people this wouldn't make a difference, but personally I need simplicity, especially when I have to decide to use a new language and learn its libraries to do what I can already do with my current language (C++ and Go in my case). So I fully respect your opinion, and in my case, I would have appreciated to have a default GUI library, even if it's not perfect, and even if some better alternative could exist on github. That's all I say :)
Re: Value closures (no GC allocation)
On Sunday, 21 May 2017 at 18:17:57 UTC, Adam D. Ruppe wrote:
But, using the struct stuff, we can add some artificial
sweetener now:
return bar(lambda!(x, q{ (int y) => x + y }));
You pass the captures first, then a q{} string literal of the
lambda. Here's the implementation of that lambda template:
template lambda(Args...) {
// ...
anon lambda() {
anon a;
// copy the values in
a.tupleof = Args[0 .. $-1];
return a;
}
}
Looks cool, but it'd still want a GC closure, won't it?
Re: My two cents on what D needs to be more successful...
On Sunday, 21 May 2017 at 05:52:11 UTC, Ecstatic Coder wrote: * the following *standard* libraries : Suppose I made a dmd distribution with my libraries pre-packaged (I already have libraries for most the stuff you listed)... would that work for you? Or must it come from the dlang.org site and be `std.` for it to count? I have no interest whatsoever in being in the official standard library though. Of course, using my libs is pretty trivial... download one or two files and add them to your build command, done.
Re: Value closures (no GC allocation)
On Sunday, 21 May 2017 at 04:08:04 UTC, Vittorio Romeo wrote:
This exact statement applied to C++ before C++11, but the
introduction of lambda expression significantly changed the way
people write and think about C++. Sometimes syntactic sugar can
have huge impact on a language.
Oh absolutely, make no mistake, I would be FOR this addition. I
like it and do think it would be worth it in a lot of places.
But, using the struct stuff, we can add some artificial sweetener
now:
return bar(lambda!(x, q{ (int y) => x + y }));
You pass the captures first, then a q{} string literal of the
lambda. Here's the implementation of that lambda template:
template lambda(Args...) {
import std.conv;
import std.range;
import std.string;
string evil() {
// build the functor
import std.meta;
string code = "static struct anon {";
foreach(i; aliasSeqOf!(iota(0, Args.length-1)))
code ~= "typeof(Args[" ~ to!string(i) ~
"]) " ~ Args[i].stringof ~ ";";
string func = Args[$-1];
auto idx = func.indexOf("=>");
if(idx == -1)
throw new Exception("No => in lambda");
// or we could use one of the other styles
auto args = func[0 .. idx];
auto bod = func[idx + 2 .. $];
code ~= "auto opCall(T...)" ~ args ~ "{ return "
~ bod ~ "; }";
code ~= "this(T...)(T t) {
this.tupleof = t;
};";
code ~= "}";
return code;
}
mixin(evil());
anon lambda() {
anon a;
// copy the values in
a.tupleof = Args[0 .. $-1];
return a;
}
}
Yes, the C++ syntax is still a bit better and can give MUCH nicer
error messages, but for short things, this isn't bad.
foreach(i; 0..5)
{
arr ~= () => writeln(i);
}
so that's actually a long standing bug, but it hasn't been fixed
for a long time
But to work with that, you can do a capture with a wrapper
function:
arr ~= ((i) => delegate() { writeln(i); })(i);
So you define a new function that returns the delegate and pass
the argument right there. This technique is common in Javascript.
Or, of course, using the artificial sweetener above, you can do:
arr ~= lambda!(i, q{ writeln(i); });
...assuming the imports are correct to call that library
function... so i'll grant the artificial sweetener can leave a
bitter aftertaste. (This is a good case to use in a feature
request as to why the string mixin trick isn't actually a great
replacement!)
Re: Why: error("multiple ! arguments are not allowed");
On Sunday, 21 May 2017 at 14:11:00 UTC, Stanislav Blinov wrote: On Sunday, 21 May 2017 at 13:42:50 UTC, Vladimir Panteleev wrote: On Sunday, 21 May 2017 at 13:08:18 UTC, Adam D. Ruppe wrote: foo!(x)!y I think it's the same as foo!x!y. As for the reason - I think because the order is possibly ambiguous or something? You could interpret it as either (foo!x)!y or foo!(x!y). I did encounter that a few times too, and my humble opinion is that there should not be any ambiguity, it should just be left-to-right, i.e.: foo!x!y is the same as (foo!x)!y, and foo!x!y!z!w would be (((foo!x)!y)!z)!w This is no different from foo!x.bar, which is (foo!x).bar and not foo!(x.bar) Allowing this will only help reduce boilerplate. If we do need different order, we could always explicitly instantiate beforehand. I ran into this aswell. Agreed, just an arbitrary restriction.
Re: Value closures (no GC allocation)
Hi Vittorio, wonderful to see you here after C++Now! :)
On 05/20/2017 09:08 PM, Vittorio Romeo wrote:
>consider this code:
>
> void delegate()[] arr;
>
> foreach(i; 0..5)
> {
> arr ~= () => writeln(i);
> }
>
> foreach(f; arr)
> {
> f();
> }
>
> This is going to print "4 4 4 4", which might be the desired behavior.
It's a bug. :/
https://issues.dlang.org/show_bug.cgi?id=8621
Ali
Re: CTFE Status 2
On Tuesday, 16 May 2017 at 13:44:27 UTC, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch
wrote:
[ ... ]
So ...
I just encountered more ABI issues; related to slices which are
part of structures.
struct R
{
uint[] s1;
uint[] s2;
}
like this.
R returnSlices(int[] s1, int[] s2)
{
return R(s1[], s2[]);
}
static assert(returnSlices([1,2,3], [4,5,6,7]) ==
R([1,2,3][4.5.6.7])); // works
R returnSlicedSlices(int[] s1, int[] s2)
{
return R(s1[], s2[1 .. $-1]);
}
static assert(returnSlicedSlices([1,2,3], [4,5,6,7]) ==
R([1,2,3],[5,6])); // fails
// returns R([1,2,3],null); at the moment
The reason ABI issues.
Where exactly ? No Idea.
Huh apparently I fixed this issue.
But I cannot rememberer when or how I did it.
This test will now magically work.
This concerns me.
Re: Why: error("multiple ! arguments are not allowed");
On Sunday, 21 May 2017 at 13:42:50 UTC, Vladimir Panteleev wrote: On Sunday, 21 May 2017 at 13:08:18 UTC, Adam D. Ruppe wrote: foo!(x)!y I think it's the same as foo!x!y. As for the reason - I think because the order is possibly ambiguous or something? You could interpret it as either (foo!x)!y or foo!(x!y). I did encounter that a few times too, and my humble opinion is that there should not be any ambiguity, it should just be left-to-right, i.e.: foo!x!y is the same as (foo!x)!y, and foo!x!y!z!w would be (((foo!x)!y)!z)!w This is no different from foo!x.bar, which is (foo!x).bar and not foo!(x.bar) Allowing this will only help reduce boilerplate. If we do need different order, we could always explicitly instantiate beforehand.
Re: My two cents on what D needs to be more successful...
Ok :) Thanks for the quick answer !
Re: Why: error("multiple ! arguments are not allowed");
On Sunday, 21 May 2017 at 13:08:18 UTC, Adam D. Ruppe wrote: foo!(x)!y I think it's the same as foo!x!y. As for the reason - I think because the order is possibly ambiguous or something? You could interpret it as either (foo!x)!y or foo!(x!y).
Re: Why: error("multiple ! arguments are not allowed");
On Sunday, 21 May 2017 at 13:08:18 UTC, Adam D. Ruppe wrote: If I comment that line and use the hacked dmd, it seems to work. Well, not exactly work, it didn't actually instantiate the inner template like it probably should have. So is it just not implemented correctly and became an error because y'all never got around to fixing the bugs, or is it prohibited by design? If so, why? Is it impossible to implement correctly?
Why: error("multiple ! arguments are not allowed");
Why is that prohibited? I just wrote
template foo(x) { template foo(y) {}}
and did
foo!(x)!y
and it triggered that error. If I comment that line and use the
hacked dmd, it seems to work.
So why is that error there?
Re: Please provide DMD as 64 executable
On Sunday, 21 May 2017 at 01:29:58 UTC, Laeeth Isharc wrote: There a Visual D script, but I do not know how to use that using msbuild. We had some trickiness at work regarding this. You essentially need to invoke devenv instead of msbuild if you want to script the process. Of course, now that Visual D supports D files inside a .vcxproj, it should probably be upgraded to use one of those instead of the .visualdproject file.
Re: My two cents on what D needs to be more successful...
On Sunday, 21 May 2017 at 11:27:19 UTC, Ecstatic Coder wrote:
Coedit is actually by far my favorite IDE for D testing and
debugging.
I liked it immediately after I saw that it doesn't need to
create a project if all you need it compile and test a small D
script.
I know I can create a project, but for tiny projects I don't
use it on purpose, despite I personally prefer to have only one
file per class, because projects tie the source code
compilation to a particular IDE.
All my tools can be compiled with "dmd xxx.d", which is really
as simple as it can possibly be.
I know that "dmd aaa.d bbb.d ccc.ddd ..." works too, but as
long as my scripts are just a few hundreds of lines of code
long, I'm ok with that.
My only concerns with Coedit are a few usability problems when
editing the code.
By default :
* When I copy a block of code, I have to select it from the end
of the previous line, or else the inserted code indentation
goes wrong.
Indeed.
* When doing a find and replace, Coedit replaces the next
occurrence despite I don't see it and I'm not sure I want to
replace it, instead of the one highlighted under the cursor,
which I'm totally sure I want to replace.
There's a checkbox that allows to activate prompts when a match
is found.
* A closing brace is automatically inserted at the wrong
position and with a unwanted blank line if I put enter to
insert a missing closing brace.
I'm not sure, but I think the case is the following :
{
{
{
}<- editor bugs if I put enter to manually add the
missing brace on the next line
}
This feature is still a bit dumb when you're in the middle of
existing code.
When writing new code it works fine. It can be fully deactivated
by the bye.
I encounter this issue as well but very occasionally.
* The regular expressions are always enabled by default when
searching text.
It doesn't mean that you have to fill the search field with a
REGEX. It means that you CAN type one but it's not a requirement
! Plain text will be searched in a standard way, whatever is the
state of the "Allow regex" option, which means "contains text" or
"exact text" depedning on the "whole word" option.
* When I change some preferences, Coedit only keeps them until
the next restart.
That would be surprising. Please open an issue for this or let's
talk on IRC.
I don't mind posting my usability remarks on your Github
You should really. My level of satisfaction is not universal.
Without feedback it'll stay specialized for my own usage.
Re: Please provide DMD as 64 executable
On Sunday, 21 May 2017 at 01:29:58 UTC, Laeeth Isharc wrote: On Friday, 19 May 2017 at 10:38:56 UTC, Andre Pany wrote: Should I file an issue for providing the 64 build of dmd on windows? As 64 bit is the default on the other platforms it should be available for windows too by default. Kind regards André We would find this useful too because we run out of memory on Windows. There may be a way to build dmd for win 64 as a script, but it wasn't obvious to me when I looked at it. There is a Visual D script, but I do not know how to use that using msbuild. Digger fails. I mentioned to Vladimir and Martin at dconf, but haven't had time to file an issue. Laeeth. I filed an issue https://issues.dlang.org/show_bug.cgi?id=17414 Kind regards André
Re: My two cents on what D needs to be more successful...
On Sunday, 21 May 2017 at 06:55:19 UTC, rikki cattermole wrote: On 21/05/2017 7:51 AM, Ecstatic Coder wrote: Exactly what I was talking about :D Thanks for your efforts !!! I'll download and test them right away. Keep in mind that they are not on code.dlang.org for a reason, they are not ready for general use. So take a developers mindset if you use them. You will find bugs and you will need to fix them if you wish to continue using it. Ok no problem :)
Re: My two cents on what D needs to be more successful...
Coedit is actually by far my favorite IDE for D testing and
debugging.
I liked it immediately after I saw that it doesn't need to create
a project if all you need it compile and test a small D script.
I know I can create a project, but for tiny projects I don't use
it on purpose, despite I personally prefer to have only one file
per class, because projects tie the source code compilation to a
particular IDE.
All my tools can be compiled with "dmd xxx.d", which is really as
simple as it can possibly be.
I know that "dmd aaa.d bbb.d ccc.ddd ..." works too, but as long
as my scripts are just a few hundreds of lines of code long, I'm
ok with that.
My only concerns with Coedit are a few usability problems when
editing the code.
By default :
* When I copy a block of code, I have to select it from the end
of the previous line, or else the inserted code indentation goes
wrong.
* When doing a find and replace, Coedit replaces the next
occurrence despite I don't see it and I'm not sure I want to
replace it, instead of the one highlighted under the cursor,
which I'm totally sure I want to replace.
* A closing brace is automatically inserted at the wrong position
and with a unwanted blank line if I put enter to insert a missing
closing brace.
I'm not sure, but I think the case is the following :
{
{
{
}<- editor bugs if I put enter to manually add the
missing brace on the next line
}
* The regular expressions are always enabled by default when
searching text.
* When I change some preferences, Coedit only keeps them until
the next restart.
I know that's really not much, but this bothers me enough so that
I still prefer Geany for pure coding sessions.
Only after I've finished programming the core code and prettified
it, I switch to Coedit to try compiling, testing and debugging it.
Except for these tiny annoyances when typing code, Coedit is an
exceptionally good IDE, and I really like it a lot, that's why
it's the only one I've mentioned.
I don't mind posting my usability remarks on your Github account
if you confirm me that they can indeed be considered as "bugs"...
Re: My two cents on what D needs to be more successful...
On Sunday, 21 May 2017 at 05:52:11 UTC, Ecstatic Coder wrote: Since a few months, I'm using D for all my command-line tools. For that use case, the language and its standard libraries are really perfect, making it the best scripting language I know, completely exploding JavaScript, Python, Ruby, etc. Now I would like to also use it to develop : [...] * a dedicated IDE, allowing to effortlessly open/compile/execute/debug a single ".d" file It's one of the basement of Coedit. There is the runnable module system as well as the support for DUB single file package. http://bbasile.github.io/Coedit/features_runnables. as well as an entire project. Also supported by the same product. I would be sad to learn you missed this ! http://bbasile.github.io/Coedit/features_projects [...] know that several IDE are already available. For instance, Coedit is a nice little IDE, despite its bugs and limitations. (author here) I don't get much bug reports. Usually i find the bugs myself since i'm a hardcore user of the product. Don't think too much, if you encounter a problem then report it: https://github.com/BBasile/Coedit/issues
Re: My two cents on what D needs to be more successful...
On 21/05/2017 7:51 AM, Ecstatic Coder wrote: Exactly what I was talking about :D Thanks for your efforts !!! I'll download and test them right away. Keep in mind that they are not on code.dlang.org for a reason, they are not ready for general use. So take a developers mindset if you use them. You will find bugs and you will need to fix them if you wish to continue using it.
