Re: Use the D dylib in my C++ program,when the D's GC(in the dylib runtime) run. will not my program stop?
On Sunday, 31 January 2016 at 05:29:06 UTC, Mike Parker wrote: On Sunday, 31 January 2016 at 05:28:02 UTC, Mike Parker wrote: need to call core.thread.attach_this [1] so that runtime is Sorry, that's core.thread.thread_attachThis ok。thanks.
Re: Use the D dylib in my C++ program,when the D's GC(in the dylib runtime) run. will not my program stop?
On Sunday, 31 January 2016 at 05:28:02 UTC, Mike Parker wrote: need to call core.thread.attach_this [1] so that runtime is Sorry, that's core.thread.thread_attachThis
Re: Use the D dylib in my C++ program,when the D's GC(in the dylib runtime) run. will not my program stop?
On Sunday, 31 January 2016 at 03:45:01 UTC, Dsby wrote: Thanks, if I use the D dylib,I should run " rt_init(); " in every thread which i used the D dylib? No. rt_init only needs to be called once for the process. You need to call core.thread.attach_this [1] so that runtime is aware of your external thread. Note that this does not apply to the thread that calls rt_init. [1] http://dlang.org/phobos/core_thread.html#.thread_attachThis
Re: C Macro deeper meaning?
On Sunday, 31 January 2016 at 03:13:46 UTC, Adam D. Ruppe wrote: On Sunday, 31 January 2016 at 02:58:28 UTC, Andrew Edwards wrote: But it cannot be that simple, so what am I missing? I'm guessing the macro was there in C to silence compiler warnings about not using a return value. So I think your translation is ok: NOTUSED(somefunction()); still calls the function, so the behavior is the same. If I'm right, the macro was just about discarding the return value in such a way as to tell the compiler warning / lint program that you intentionally wanted to ignore it. Okay, got it. Much appreciated.
Re: Use the D dylib in my C++ program,when the D's GC(in the dylib runtime) run. will not my program stop?
On Saturday, 30 January 2016 at 16:06:37 UTC, Chris Wright wrote: On Sat, 30 Jan 2016 14:41:18 +, Dsby wrote: Use the D dylib in my C++ program,when the D's GC(in the dylib runtime) run. will not my program stop? The GC will stop every thread it knows about. If you have a C++ thread that you want to run while the GC is running, you can get that by not telling the D runtime about it. This will limit your ability to interact with D from that thread somewhat -- and it will interfere more with your ability to *safely* interact with D even more. If you never allocate GC memory, of course, the GC will never run. Thanks, if I use the D dylib,I should run " rt_init(); " in every thread which i used the D dylib?
Re: C Macro deeper meaning?
On Sunday, 31 January 2016 at 02:58:28 UTC, Andrew Edwards wrote: But it cannot be that simple, so what am I missing? I'm guessing the macro was there in C to silence compiler warnings about not using a return value. So I think your translation is ok: NOTUSED(somefunction()); still calls the function, so the behavior is the same. If I'm right, the macro was just about discarding the return value in such a way as to tell the compiler warning / lint program that you intentionally wanted to ignore it.
C Macro deeper meaning?
If I understand correctly, this piece of code: enum NOTUSED(v) do { (void)(1 ? (void)0 : ( (void)(v) ) ); } while(0) can be converted to the following in D: void notUsed(T)(T v) { return cast(void)0; }; since it always returns cast(void)0 regardless of the input. But it cannot be that simple, so what am I missing? Thanks, Andrew Edwards
Re: UTF-16 endianess
On Fri, 29 Jan 2016 18:58:17 -0500, Steven Schveighoffer wrote: >>> Note the version identifiers BigEndian and LittleEndian can be used to >>> compile the correct code. >> >> This solution is of no use to me as I don't want to change the endianess in >> general. > > What I mean is that you can annotate your code with version statements like: > > version(LittleEndian) > { > // perform the byteswap > ... > } > > so your code is portable to BigEndian systems (where you would not want > to byte swap). That's a good point, thanks. -- Marek Janukowicz
Re: How do you initialize a class instance which has static storage within another class?
On Sat, 30 Jan 2016 22:02:10 +, Enjoys Math wrote: > On Saturday, 30 January 2016 at 21:52:20 UTC, Enjoys Math wrote: >> >> class A { static B b; } class B {} >> >> doing b = new B() does NOT work. >> >> Nor could I create a this() {} at module level > > More info: > > B : A > > so I can't do > > class A { >this () { > if (b is null) { > b = new B(); > } > } > } You should use a static constructor: class A { static B b; static this() { b = new B(); } }
Re: How do you initialize a class instance which has static storage within another class?
On Saturday, 30 January 2016 at 21:52:20 UTC, Enjoys Math wrote: class A { static B b; } class B {} doing b = new B() does NOT work. Nor could I create a this() {} at module level More info: B : A so I can't do class A { this () { if (b is null) { b = new B(); } } } Since it OVERFLOWS THE STACK!!
Re: How do you initialize a class instance which has static storage within another class?
On 30.01.2016 22:52, Enjoys Math wrote: class A { static B b; } class B {} doing b = new B() does NOT work. Nor could I create a this() {} at module level It works when you make b const/immutable: class A {static immutable B b = new B;} class B {} If you want/need b to be mutable, you can use a static constructor (`static this`), either in the class or the module: class A {static B b; static this() {b = new B;}} class B {} class A {static B b;} static this() {A.b = new B;} class B {} You could also set it in `main` or another function that runs before b is used, of course.
How do you initialize a class instance which has static storage within another class?
class A { static B b; } class B {} doing b = new B() does NOT work. Nor could I create a this() {} at module level
Re: Access Violation in @safe Code
On Saturday, 30 January 2016 at 13:37:43 UTC, Kagamin wrote: Alias templates require stack pointer, init probably has it set to null. Try this: FooType foo = FooType(); Yes, that fixed it. Interesting.
Re: Pipe one shell command into another
On Saturday, 30 January 2016 at 15:57:49 UTC, Griffon26 wrote: On Saturday, 30 January 2016 at 15:12:26 UTC, Andrew wrote: foreach(line; pipesLs.stdout.byLine) pipesSort.stdin.writeln(line); Because you write sort's input first and read its output later, it might end up blocking if ls generates too much data. The output pipe of sort will fill up, causing sort to block and not read data from its input pipe anymore, resulting in your program blocking when the input pipe has filled up. I have a piece of code using poll to write to two input pipes and read from one output pipe, but it's a bit more complex than what you need. However, it also uses pipeShell to specify multiple commands at once. Since your program only needs to read the output (and not generate input), you may find pipeShell useful. https://github.com/Griffon26/tdiff3/blob/87709dd51c279e9896f37ba1cef477a525e44562/source/gnudiff.d Disclaimer: I'm not an experienced D programmer. My D code may not be pretty =) pipeShell did the trick. Thank you very much! Andrew
Re: Use the D dylib in my C++ program,when the D's GC(in the dylib runtime) run. will not my program stop?
On Sat, 30 Jan 2016 14:41:18 +, Dsby wrote: > Use the D dylib in my C++ program,when the D's GC(in the dylib runtime) > run. will not my program stop? The GC will stop every thread it knows about. If you have a C++ thread that you want to run while the GC is running, you can get that by not telling the D runtime about it. This will limit your ability to interact with D from that thread somewhat -- and it will interfere more with your ability to *safely* interact with D even more. If you never allocate GC memory, of course, the GC will never run.
Re: Pipe one shell command into another
On Saturday, 30 January 2016 at 15:12:26 UTC, Andrew wrote: foreach(line; pipesLs.stdout.byLine) pipesSort.stdin.writeln(line); Because you write sort's input first and read its output later, it might end up blocking if ls generates too much data. The output pipe of sort will fill up, causing sort to block and not read data from its input pipe anymore, resulting in your program blocking when the input pipe has filled up. I have a piece of code using poll to write to two input pipes and read from one output pipe, but it's a bit more complex than what you need. However, it also uses pipeShell to specify multiple commands at once. Since your program only needs to read the output (and not generate input), you may find pipeShell useful. https://github.com/Griffon26/tdiff3/blob/87709dd51c279e9896f37ba1cef477a525e44562/source/gnudiff.d Disclaimer: I'm not an experienced D programmer. My D code may not be pretty =)
Pipe one shell command into another
Hi, I'd like to run a shell command which involves piping one thing into another and then processes the output line by line, i.e. something like "ls -l | sort -k5,5n" What I've come up so far with is: import std.process; import std.stdio; void main(){ auto pipesLs = pipeProcess(["ls", "-l"], Redirect.stdout); auto pipesSort = pipeProcess(["sort", "-k5,5n"], Redirect.all); scope (exit) wait(pipesSort.pid); foreach(line; pipesLs.stdout.byLine) pipesSort.stdin.writeln(line); pipesSort.stdin.close; foreach(line; pipesSort.stdout.byLine) writeln(line); } This seems to work on this simple example, but is there a better way to do it, and if not, is this reliable? Also, could someone explain to me the necessity of the wait command? Thanks very much Andrew
Use the D dylib in my C++ program,when the D's GC(in the dylib runtime) run. will not my program stop?
Use the D dylib in my C++ program,when the D's GC(in the dylib runtime) run. will not my program stop? My lib.so is writed in D, and I use the GC.and then I am used the dll in my program that is writed in C++. I want to know when the GC(in lib.so's runtime) start runing, will my program be stoped,until the GC stop? sorry , my english is bad. I will use chinese to describe this question: 我用D语言写了一个的动态库,其中里面的内存分配和回收用的是GC。现在我的C++程序去调用这个动态库。我想知道,当动态库所依赖的的D的运行时中GC运行的时候,是不是我的整个程序都会暂停住,知道GC回收完毕再次唤醒?
Re: Access Violation in @safe Code
Alias templates require stack pointer, init probably has it set to null. Try this: FooType foo = FooType();
Re: is(some template instantiation) is true, but the actual instantiation fails
On Saturday, 30 January 2016 at 00:16:21 UTC, Ali Çehreli wrote: > https://issues.dlang.org/show_bug.cgi?id=15623 As I noted on the bug report, they are work when moved from module scope to inside a function (e.g. main()). At least there's that workaround... Ali Thanks a lot! Now I can continue my work. :)
Re: is(some template instantiation) is true, but the actual instantiation fails
On Friday, 29 January 2016 at 23:44:56 UTC, Basile B. wrote: Haven't you seen my answer about constraint ? If you put a constraint on your function template then invalid instantiations are rejected. I mean... this language feature is not just ornamental... What do you think constraints are used for otherwise ^^ Yes, I've seen it, thanks. Requiring the user to write the constraint might indeed enforce a better style, but I want to be able to test it even if the user forgets the constraint. Otherwise she'll get cryptic error messages from some other code assuming that CallsFoo!NoFoo is a valid type.
Re: Dub packages: Best practices for windows support
On Saturday, 30 January 2016 at 01:17:13 UTC, Mike Parker wrote: On Friday, 29 January 2016 at 19:46:40 UTC, Johannes Pfau wrote: Now on windows, things are more complicated. First of all, I can't seem to simply use "libs": ["foo"] as the linker won't find the C import .lib file. Then apparently there's no way to add a library search path with the MSVC linker? So I have to use the full path: "libs": [$PACKAGE_DIR\\path\\foo]. Without $PACKAGE_DIR paths are incorrect for applications using the library because of a dub problem. And then I'll have to use different import libraries and paths for -m32, -m64 and -m32mscoff. Now you know my motivation for creating Derelict. +1, make a Derelict-style binding and never deal with import library ever again.
Re: Dub packages: Best practices for windows support
Am Sat, 30 Jan 2016 01:17:13 + schrieb Mike Parker : > On Friday, 29 January 2016 at 19:46:40 UTC, Johannes Pfau wrote: > > > Now on windows, things are more complicated. First of all, I > > can't seem > > to simply use "libs": ["foo"] as the linker won't find the C > > import .lib file. Then apparently there's no way to add a > > library search > > path with the MSVC linker? So I have to use the full path: > > "libs": [$PACKAGE_DIR\\path\\foo]. Without $PACKAGE_DIR paths > > are > > incorrect for applications using the library because of a dub > > problem. > > And then I'll have to use different import libraries and paths > > for -m32, > > -m64 and -m32mscoff. > > Now you know my motivation for creating Derelict. > > > > All this leads to the following questions: > > * Should cairoD copy the DLLs for all applications using > > cairoD? This > > way simply adding a dependency will work. However, if users > > want to > > use a self compiled cairo DLL with fewer dependencies there's > > no easy > > way to disable the file copying? > > * Should cairoD link in the .lib DLL import file? This might be > > useful > > even when not copying the DLLs. But if users want to link a > > custom > > import library that would be difficult. OTOH not copying DLLs > > and/or > > not linking the import library will make dub.json much more > > complicated for simple applications, especially if these > > applications > > want to support -m32, -m32mscoff and -m64. > > IMO, no to both of these (for now). Including all of these > dependencies is going to mean that all of your users, no matter > the platform, will pull the down with every new version of gtkd. > I recommend you provide all of the precompiled DLLs and import > libraries as a separate download and let the user do the > configuration needed to get it to link. Most Windows developers > are used to it. You can provide instructions for those who aren't. Thanks for the detailed answer. Thinking about this some more, copying the DLLs automatically is really a bad idea. The cairo dll depends on Freetype, so I'd have to ship a Freetype dll as well. But cairoD depends on DerelictFT and if DerelictFT then decided to also install DLLs automatically anything could happen. So even in this simple case installing DLLs for the user is not a good idea.
Re: d plugin for Intelij Idea debuging support
On Friday, 29 January 2016 at 12:00:25 UTC, Pavel wrote: Hello! Is there any debuging support for Intelij Idea's D plugin? Thanks! Currently only XamarinStudio/MonoDevelop and DlangIDE allow debugging on Linux through GDB. On Windows VisaulD provides debugging support for Visual Studio.
Re: Why is it a memory ERRO.
On Saturday, 30 January 2016 at 05:50:33 UTC, Dsby wrote: Ok.Thank you. and i want to know how to know when the GC start runing? See also http://dlang.org/phobos/core_memory