Re: If stdout is __gshared, why does this throw / crash?
On Sunday, 6 March 2016 at 01:10:58 UTC, Anon wrote: On Saturday, 5 March 2016 at 14:18:31 UTC, Atila Neves wrote: [...] Note that `1000.iota.parallel` does *not* run 1000 threads. `parallel` just splits the work of the range up between the worker threads (likely 2, 4, or 8, depending on your CPU). I see the effect you describe with any parallel workload. Smaller numbers in place of 1000 aren't necessarily splitting things off to additional threads, which is why smaller numbers avoid the multi-threaded problems you are encountering. Err, right. [...] `File` uses ref-counting internally to allow it to auto-close. `stdout` and friends are initialized in a special way such that they have a high initial ref-count. When you assign a new file to stdout, the ref count becomes one. As soon as one of your threads exits, this will cause stdout to close, producing the odd errors you are encountering on all the other threads. I would avoid reassigning `stdout` and friends in favor of using a logger or manually specifying the file to write to if I were you. I see. Here's my problem: I want to make it so code not under my control doesn't get to write to stdout and stderr. I don't see any other way but to reassign stdout. Maybe I can manually bump up the ref count? Atila
Re: If stdout is __gshared, why does this throw / crash?
On Sunday, 6 March 2016 at 01:28:52 UTC, Marco Leise wrote: Got it now: https://issues.dlang.org/show_bug.cgi?id=15768 writeln() creates a copy of the stdout struct in a non thread-safe way. If stdout has been assigned a File struct created from a file name this copy includes a "racy" increment/decrement of a reference count to the underlying C-library FILE*. In the case that the reference count is erroneously reaching 0, the file is closed prematurely and when Glibc tries to access internal data it results in the observable SIGSEGV. Nice, good work! Atila
is module ( std.experimental.logger) thread-safe.
I want to use the filelogger to my application. is the sharedLog() global and thread-safe.
Re: Create Windows "shortcut" (.lnk) with D?
On Sunday, 6 March 2016 at 03:13:23 UTC, 岩倉 澪 wrote: IShellLinkA* shellLink; IPersistFile* linkFile; Any help would be highly appreciated as I'm new to Windows programming in D and have no idea what I'm doing wrong! In D, interfaces are references, so it should be: IShellLinkA shellLink; IPersistFile linkFile;
Had not Dllimport in D?
First, I really sorry my bad english. I just want to using Ruby dll file(msvcrt-ruby220.dll). In the case of C#, using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Runtime.InteropServices; using INT = System.Int32; namespace RubyTest01 { static class Ruby { public const string RubyDll = "msvcrt-ruby18"; [DllImport(RubyDll)] public static extern void ruby_init(); [DllImport(RubyDll)] public static extern INT rb_eval_string_protect(byte[] script, ref INT state); public static INT rb_eval_string_protect(string script, ref INT state) { return rb_eval_string_protect(Encoding.UTF8.GetBytes(script + '\0'), ref state); } } class Program { static void Main(string[] args) { INT state = 0; Ruby.ruby_init(); Ruby.rb_eval_string_protect("open('test.txt', 'w') {| fp| fp.write(\"Hello World!\\n\")}", ref state); } } I guess D had something like it, but i don't know how to do it. Thx!
Re: Had not Dllimport in D?
On Sunday, 6 March 2016 at 14:12:35 UTC, xky wrote: First, I really sorry my bad english. I just want to using Ruby dll file(msvcrt-ruby220.dll). D can import and use functions from a DLL but you are using a C# library, which is probably not going to work. D can only call functions from DLLs with a C or D interface. If you want to make your own shared libraries or use some C DLLs check these links: http://wiki.dlang.org/Win32_DLLs_in_D (native .dll -> windows) https://dlang.org/dll-linux.html (shared object .so -> linux) https://github.com/DerelictOrg/DerelictUtil (library for loading dll functions on multiple platforms)
Re: Had not Dllimport in D?
Okay, since you clearly have not worked in a native language before, lets start from scratch. You want to make some bindings to a shared library called "msvcrt-ruby18". From this I know that it is using the Microsoft Visual C runtime. That means you must build D using this as well. This is done via the -ms32coff switch for 32bit and -m64 for 64bit (which is easier all up). You will need Visual studio with all of the c/c++ stuff installed. Keep in mind you must match the version of Visual C runtime up with the shared libraries one (if you fail enjoy the segfaults!). Lastly you want some bindings. I won't cover that here. But this should help ya out http://dlang.org/spec/interfaceToC.html After this you should be able to pass the shared library directly to dmd when in -ms32coff or -m64 mode and it'll all work.
Re: Had not Dllimport in D?
On Sunday, 6 March 2016 at 14:21:55 UTC, Rikki Cattermole wrote: Okay, since you clearly have not worked in a native language before, lets start from scratch. [...] Sorry for my idiot question. Thanks.
Re: Had not Dllimport in D?
On Sunday, 6 March 2016 at 14:20:34 UTC, WebFreak001 wrote: On Sunday, 6 March 2016 at 14:12:35 UTC, xky wrote: First, I really sorry my bad english. I just want to using Ruby dll file(msvcrt-ruby220.dll). D can import and use functions from a DLL but you are using a C# library, which is probably not going to work. D can only call functions from DLLs with a C or D interface. If you want to make your own shared libraries or use some C DLLs check these links: http://wiki.dlang.org/Win32_DLLs_in_D (native .dll -> windows) https://dlang.org/dll-linux.html (shared object .so -> linux) https://github.com/DerelictOrg/DerelictUtil (library for loading dll functions on multiple platforms) DerelictUtil looks like useful for me. Thank you. :-)
Is there a standard for whar opAssign/opOpAssign should return?
In the https://dlang.org/spec/operatoroverloading.html opAssign is declared as void opAssign(S rhs); in the example. From C++ I'm used to return *this when overloading assignment operators to allow chaining of assignments (or somewhat more rarely, weird tricks for if and while statements), is that not done in D as a rule or is the example just weird? Same question for the opOpAssign family.
Re: Had not Dllimport in D?
On 07/03/16 4:19 AM, xky wrote: On Sunday, 6 March 2016 at 14:21:55 UTC, Rikki Cattermole wrote: Okay, since you clearly have not worked in a native language before, lets start from scratch. [...] Sorry for my idiot question. Thanks. Not idiot, its just where you are at and that's ok :) Sorry for making you feel like that though.
Re: Is there a standard for whar opAssign/opOpAssign should return?
On Sunday, March 06, 2016 15:25:46 HSteffenhagen via Digitalmars-d-learn wrote: > In the https://dlang.org/spec/operatoroverloading.html opAssign > is declared as > > void opAssign(S rhs); > > in the example. > > From C++ I'm used to return *this when overloading assignment > operators to allow chaining of assignments (or somewhat more > rarely, weird tricks for if and while statements), is that not > done in D as a rule or is the example just weird? Same question > for the > opOpAssign family. void opAssign(S rhs); will work, but it's not the most flexible. Ideally, the various overloaded assignment operators would return "this" by ref. e.g. ref S opAssign(S rhs) { ... return this; } which is essentially what you do in C++. Without returning by ref, you can't chain assignments, which is why return by ref is preferable even if it's not required. The example in the documentation should probably be modified to return by ref, but void will work - just not with chained assignments. - Jonathan M Davis
Re: Const vs Non const method
On Thursday, 25 February 2016 at 10:59:43 UTC, Rene Zwanenburg wrote: On Thursday, 25 February 2016 at 10:44:49 UTC, Andrea Fontana wrote: Check this simple code: http://dpaste.dzfl.pl/2772c9144f1c I can't understand how to minimize code duplication for function like get(). Of course on real case body is much bigger and complex than that. The only way I found is to move the body of function inside a mixin template: mixin template getterImpl() { auto getterImpl() { /* very long body */ return inner; } } and then: auto get() const { mixin getterImpl; return getterImpl; } auto get() { mixin getterImpl; return getterImpl; } Am I missing something? I don't think it's the right way. You can do this using inout: http://dpaste.dzfl.pl/678cac023051 That getter can be written even shorter due to a quirk in the D syntax, like: inout get() { return inner; } But I prefer to explicitly state inout for every parameter and return type. inout is kind of a wildcard for mutable, const, and immutable. You can also add it to your function parameters, for example: inout(int[]) doSomething(inout(SomeClass) c); So the constness of doSomething's return type depends on the constness of the passed argument. What would be the C++ way? Is there any comfortable way to solve this problem in a nice way like D?
Re: Create Windows "shortcut" (.lnk) with D?
On Sunday, 6 March 2016 at 11:00:35 UTC, John wrote: On Sunday, 6 March 2016 at 03:13:23 UTC, 岩倉 澪 wrote: IShellLinkA* shellLink; IPersistFile* linkFile; Any help would be highly appreciated as I'm new to Windows programming in D and have no idea what I'm doing wrong! In D, interfaces are references, so it should be: IShellLinkA shellLink; IPersistFile linkFile; That's exactly what the problem was, thank you!!