Re: Render SVG To Display And Update Periodically
On Monday, 17 October 2016 at 02:07:47 UTC, rikki cattermole wrote: You're going to need to find an svg rasterizer in some form or another. I don't think we have one in D and certainly not a complete one. 'cmon, you know that i have a working port of NanoSVG! and it works on top of NanoVG, so no toolkit is required. ah...
Re: Render SVG To Display And Update Periodically
On Monday, 17 October 2016 at 07:05:24 UTC, ketmar wrote: On Monday, 17 October 2016 at 02:07:47 UTC, rikki cattermole wrote: You're going to need to find an svg rasterizer in some form or another. I don't think we have one in D and certainly not a complete one. 'cmon, you know that i have a working port of NanoSVG! and it works on top of NanoVG, so no toolkit is required. ah... oops, forgot to give some links. ;-) nanovg and nanosvg ports: http://repo.or.cz/iv.d.git/tree/HEAD:/nanovg some demos: http://repo.or.cz/iv.d.git/tree/HEAD:/nanovg_demo to make it actually draw something, i'm using Adam's excellect simpledisplay from here: https://github.com/adamdruppe/arsd fetching color.d and simpledisplay.d is enough, you don't need the whole repository. ;-) it works at least in GNU/Linux and Windows. OSX is not tested.
Re: Cannot link with libphobos2.a with GCC 6.2 on Ubuntu 16.10
On Monday, 17 October 2016 at 05:55:55 UTC, tcak wrote: So, I added -defaultlib=libphobos2.so -fPIC Where did you add it? To the command-line or Makefile? And which Make variable did you change? I've tried make -f posix.mak MODEL_FLAG="-fPIC" but C++ compilations still fail with complaining about libphobos2.a not being compiled with -fPIC flag. -defaultlib is a DMD flag so that has not effect with the C++ compilations. This must be fixed in the DMD Makefiles! I you only tell me what to do I can make a PR to DMD that fixes these things.
Re: Cannot link with libphobos2.a with GCC 6.2 on Ubuntu 16.10
On Monday, 17 October 2016 at 08:39:55 UTC, Nordlöw wrote: I you only tell me what to do I can make a PR to DMD that fixes these things. It's the target `idgen` that fails for me.
Re: Is this should work?
Thanks. So something like this would be helpful in core.thread? void startThread(alias fun, P...)(P p){ new Thread({fun(p);}).start(); }
Re: Is this should work?
Dne 17.10.2016 v 11:56 markov via Digitalmars-d-learn napsal(a): Thanks. So something like this would be helpful in core.thread? void startThread(alias fun, P...)(P p){ new Thread({fun(p);}).start(); } or without delegate import std.stdio; import core.thread; void fun(alias a, alias msg)() { writefln("Hello number %d from %s", a, msg); } void main() { int a = 7; string msg = "main"; auto thr = new Thread(&fun!(a, msg)).start; thr.join; }
Re: Cannot link with libphobos2.a with GCC 6.2 on Ubuntu 16.10
On 2016-10-17 10:55, Nordlöw wrote: It's the target `idgen` that fails for me. "idgen" is a separate target [1]. It's a tool that generates some code. [1] https://github.com/dlang/dmd/blob/master/src/posix.mak#L389 -- /Jacob Carlborg
Re: Cannot link with libphobos2.a with GCC 6.2 on Ubuntu 16.10
On Thursday, 13 October 2016 at 18:35:43 UTC, Matthias Klumpp wrote: The new toolchains of Ubuntu (and Debian soon too) default to PIE code, so in order to link correctly, the project needs to be compiled with PIE/PIC to work. Please update the bug report. https://issues.dlang.org/show_bug.cgi?id=5278
Re: Speed of synchronized
Dne 16.10.2016 v 10:41 Christian Köstlin via Digitalmars-d-learn napsal(a): Hi, for an exercise I had to implement a thread safe counter. This is what I came up with: btw. I run the code with dub run --build=release Thanks in advance, Christian So I have done some testing, on my pc: Java result counter.AtomicLongCounter@7ff5e7d8 expected: 200 got: 100 in: 83ms counter.ThreadSafe2Counter@59b44e4b expected: 200 got: 100 in: 77ms counter.ThreadSafe1Counter@2e5f6b4b expected: 200 got: 100 in: 154ms counter.ThreadUnsafeCounter@762b155d expected: 200 got: 730428 in: 13ms and my D results (code: http://dpaste.com/3QFXACY ): snip.AtomicCounter: got: 100 expected: 100 in 77 ms and 783 μs snip.ThreadSafe1Counter: got: 100 expected: 100 in 287 ms, 727 μs, and 3 hnsecs snip.ThreadSafe2Counter: got: 100 expected: 100 in 281 ms, 117 μs, and 1 hnsec snip.ThreadSafe3Counter: got: 100 expected: 100 in 158 ms, 480 μs, and 2 hnsecs snip.ThreadUnsafeCounter: got: 100 expected: 100 in 6 ms, 682 μs, and 1 hnsec so atomic is same as in Java pthread_mutex is same speed as java synchronized D mutexes and D synchronized are almost same, I belive that if I could setup same attrs as in pthread version it will be around 160ms too. Unsafe is almost same for D and java. Only java ReentrantLock seems to work better. I believe there is some trick, so it will end up not using mutexes in the end at all. For example consider this change in D code: void doIt(alias counter)() { auto thg = new ThreadGroup(); for (int i=0; isnip.AtomicCounter: got: 100 expected: 100 in 22 ms, 251 μs, and 6 hnsecs snip.ThreadSafe1Counter: got: 100 expected: 100 in 46 ms, 146 μs, and 3 hnsecs snip.ThreadSafe2Counter: got: 100 expected: 100 in 44 ms, 961 μs, and 5 hnsecs snip.ThreadSafe3Counter: got: 100 expected: 100 in 42 ms, 512 μs, and 8 hnsecs snip.ThreadUnsafeCounter: got: 100 expected: 100 in 2 ms, 108 μs, and 5 hnsecs
Re: Speed of synchronized
On 17/10/16 14:09, Daniel Kozak via Digitalmars-d-learn wrote: > Dne 16.10.2016 v 10:41 Christian Köstlin via Digitalmars-d-learn napsal(a): >> Hi, >> >> for an exercise I had to implement a thread safe counter. >> This is what I came up with: >> >> >> btw. I run the code with dub run --build=release >> >> Thanks in advance, >> Christian > So I have done some testing, on my pc: > Java result > counter.AtomicLongCounter@7ff5e7d8 expected: 200 got: 100 in: 83ms > counter.ThreadSafe2Counter@59b44e4b expected: 200 got: 100 in: 77ms > counter.ThreadSafe1Counter@2e5f6b4b expected: 200 got: 100 in: > 154ms > counter.ThreadUnsafeCounter@762b155d expected: 200 got: 730428 in: 13ms > > and my D results (code: http://dpaste.com/3QFXACY ): > snip.AtomicCounter: got: 100 expected: 100 in 77 ms and 783 μs > snip.ThreadSafe1Counter: got: 100 expected: 100 in 287 ms, 727 > μs, and 3 hnsecs > snip.ThreadSafe2Counter: got: 100 expected: 100 in 281 ms, 117 > μs, and 1 hnsec > snip.ThreadSafe3Counter: got: 100 expected: 100 in 158 ms, 480 > μs, and 2 hnsecs > snip.ThreadUnsafeCounter: got: 100 expected: 100 in 6 ms, 682 > μs, and 1 hnsec > > so atomic is same as in Java pthread_mutex is same speed as java > synchronized > D mutexes and D synchronized are almost same, I belive that if I could > setup same attrs as in pthread version it will be around 160ms too. > > Unsafe is almost same for D and java. Only java ReentrantLock seems to > work better. I believe there is some trick, so it will end up not using > mutexes in the end at all. For example consider this change in D code: > > void doIt(alias counter)() { > auto thg = new ThreadGroup(); > for (int i=0; i thg.create(&threadFuncBody!(counter)); > } > thg.joinAll(); > } > > change it to > > void doIt(alias counter)() { > auto thg = new ThreadGroup(); > for (int i=0; i auto tc = thg.create(&threadFuncBody!(counter)); > tc.join(); > } > } > > and results are: > > snip.AtomicCounter: got: 100 expected: 100 in 22 ms, 251 μs, and > 6 hnsecs > snip.ThreadSafe1Counter: got: 100 expected: 100 in 46 ms, 146 > μs, and 3 hnsecs > snip.ThreadSafe2Counter: got: 100 expected: 100 in 44 ms, 961 > μs, and 5 hnsecs > snip.ThreadSafe3Counter: got: 100 expected: 100 in 42 ms, 512 > μs, and 8 hnsecs > snip.ThreadUnsafeCounter: got: 100 expected: 100 in 2 ms, 108 > μs, and 5 hnsecs > > > > > thank you for looking into it. this seems to be quite good. I did expect something in those lines, but got the mentioned numbers on my os x macbook. perhaps its a os x glitch.
Bug or case of hijacking protection ?
Is this a bug or a case of hijacking protection ? struct S { void test(void*, size_t){} } void test(ref S,void[]){} void main() { ubyte[] a; (*new S).test(a); }
Re: Bug or case of hijacking protection ?
On Monday, 17 October 2016 at 14:01:26 UTC, Basile B. wrote: Is this a bug or a case of hijacking protection ? struct S { void test(void*, size_t){} } void test(ref S,void[]){} void main() { ubyte[] a; (*new S).test(a); } In the meantime I've found this BR: https://issues.dlang.org/show_bug.cgi?id=11836 It could be closed if it's an authentic anti-hijacking case...waitaing for your expertise.
how to understand different attribute styles?
there is "@disable", using @ as prefix; there is "__gshared", using __ as prefix; there is also "align", not using prefix. I failed to summarize a rule here. Can anyone tell the underlined philosiphy?
Re: how to understand different attribute styles?
On Monday, 17 October 2016 at 14:12:33 UTC, timepp wrote: there is "@disable", using @ as prefix; there is "__gshared", using __ as prefix; there is also "align", not using prefix. I failed to summarize a rule here. Can anyone tell the underlined philosophy? It's an inconsistency of the language. see http://forum.dlang.org/post/hfmulninvghjntqkp...@forum.dlang.org
Re: Escaping ref to stack mem sometimes allowed in @safe?
On Friday, October 14, 2016 16:49:44 Nick Sabalausky via Digitalmars-d-learn wrote: > This compiles. Is it supposed to? > > @safe ubyte[] foo() > { > ubyte[512] buf; > auto slice = buf[0..$]; > // Escaping reference to stack memory, right? > return slice; > } > > Or is the escaping reference detection not intended to be 100%? Or > something else I'm missing? > > Should I file @ bugzilla? It's a long-standing bug: https://issues.dlang.org/show_bug.cgi?id=8838 But Walter has been working on @safety issues recently (particularly with regards to stuff like parameters escaping, because of DIP1000), so a fix should finally be coming. - Jonathan M Davis
Re: how to understand different attribute styles?
On Monday, October 17, 2016 14:12:33 timepp via Digitalmars-d-learn wrote: > there is "@disable", using @ as prefix; > there is "__gshared", using __ as prefix; > there is also "align", not using prefix. > > I failed to summarize a rule here. Can anyone tell the underlined > philosiphy? There really isn't one. __gshared is probably the way that it is, because it's not something much of anything but C bindings should be using (it exists solely for compatibility with C global variables). So, it's treated as a compiler thing (like __traits) rather than a normal attribute. But as for @, what that pretty much comes down to is that Walter didn't want to add more keywords. So, new ones got @ put on them (and all of this was well before user defined attributes came along). In general, folks don't like the fact that there is no consistency between what has @ and what doesn't, but no one can come up with a scheme that's actually fully consistent (at least, not without slapping @ on all attributes or having it on none), and it would break a ton of code if any of them were changed now, so it's highly unlikely that any of them will ever change. So, you just learn which ones have @ and which don't, and then it mostly doesn't matter anymore, as annoying as it may be from an aesthetic point of view. - Jonathan M Davis
Re: how to understand different attribute styles?
On 10/17/16 10:12 AM, timepp wrote: there is "@disable", using @ as prefix; there is "__gshared", using __ as prefix; there is also "align", not using prefix. I failed to summarize a rule here. Can anyone tell the underlined philosiphy? terms without adornments are keywords. They are used in parsing to anchor the parser, and can only mean what they are intended to mean by the language. This means they are reserved by the language, and can't be used by users of the language. Terms with __ are also keywords, but are marked that way because they are used in unusual circumstances, were intended to be replaced with a more formal keyword, or were chosen as not to interfere with any existing symbols (i.e. added after much D code already existed). The language tries not to add keywords any more because it breaks any code that uses it. There aren't many of these. In general, you should not use symbols with two underscores because those are expected to be reserved by the language or compiler. It's not a hard-fast rule, but I'd expect there to never be any new keywords that don't start with __. The terms with the @ sign are attributes, and can only be used as attributes. They are never storage classes, types, or keywords in general. In this space, the language has many pre-defined attributes, and you can't use them to mean something different (as attributes) once the language has defined it. Think of these as pre-defined symbols. The nice thing about these are that you can use them as regular symbols without the @ sign, and it doesn't change anything. As long as you don't intend to use them as actual attributes, you should be fine. However, I'd recommend not to do this as this can be confusing to anyone reading your code and not knowing the pre-defined attributes. Note that attributes were added much later in the language, and most of the predefined attributes were added before user defined attributes were supported. So I expect not many more language defined attributes will be added unless absolutely necessary. You may ask, why the difference between e.g. @safe and pure? Historical reasons really. It should really be @pure, but pure was a keyword from very early. So there is a bit of that. -Steve
About debugging (again)
Hello! I've met an issue related to debugging by GDB. Directly when I try to show call stack I get like this http://pastebin.com/kRFRqznq. How can I make name of methods more human readable? I see part of printed name matches to name of methods from code and I can suppose what method was called, but it would be great if I can debug application without any supposing. Sorry if my english is not clear.
Re: About debugging (again)
On Monday, 17 October 2016 at 15:43:32 UTC, ANtlord wrote: Hello! I've met an issue related to debugging by GDB. Directly when I try to show call stack I get like this http://pastebin.com/kRFRqznq. How can I make name of methods more human readable? I see part of printed name matches to name of methods from code and I can suppose what method was called, but it would be great if I can debug application without any supposing. Sorry if my english is not clear. Oh Sorry, I've forgotten about pointing technical parameters. Ubuntu 14.04 GDB 7.7.1 DMD64 D Compiler v2.071.1
Range violation with AAs
At https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d I have an array container. Everything works as expected in all unittests except for the line at https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d#L1649 that fails as core.exception.RangeError@array_ex.d(1649): Range violation and I have no clue why. Is this a know problem with AA's with container-like structs as value types?
Re: About debugging (again)
On Monday, 17 October 2016 at 15:45:56 UTC, ANtlord wrote: On Monday, 17 October 2016 at 15:43:32 UTC, ANtlord wrote: Hello! I've met an issue related to debugging by GDB. Directly when I try to show call stack I get like this http://pastebin.com/kRFRqznq. How can I make name of methods more human readable? I see part of printed name matches to name of methods from code and I can suppose what method was called, but it would be great if I can debug application without any supposing. Sorry if my english is not clear. Oh Sorry, I've forgotten about pointing technical parameters. Ubuntu 14.04 GDB 7.7.1 DMD64 D Compiler v2.071.1 redirect gdb's output to "ddemangle". This is what I do in the alpha version of Coedit's GDB commander, now in console mode I don't know the exact method.
Re: About debugging (again)
On Monday, 17 October 2016 at 17:46:05 UTC, Basile B. wrote: On Monday, 17 October 2016 at 15:45:56 UTC, ANtlord wrote: On Monday, 17 October 2016 at 15:43:32 UTC, ANtlord wrote: [...] Oh Sorry, I've forgotten about pointing technical parameters. Ubuntu 14.04 GDB 7.7.1 DMD64 D Compiler v2.071.1 redirect gdb's output to "ddemangle". This is what I do in the alpha version of Coedit's GDB commander, now in console mode I don't know the exact method. seems to be: gdb binary_name | ddemangle
Re: About debugging (again)
On Monday, 17 October 2016 at 15:45:56 UTC, ANtlord wrote: GDB 7.7.1 Use latest GDB, 7.10 has got much better D support.
Programming in D by Ali Çehreli
Hi All, As per the book named in the subject it states as below,so can some one guide me what is wrong in the below code nor correct if my understanding is wrong. Page 154 immutable(int[]) specifies that neither the slice nor its elements can be modified. So which means that a element or a slice of any array can be modified, but the below example code is not working. import std.stdio; void main() { immutable(int[]) immSlice = [ 1, 2 ]; immSlice ~= 3; immSlice[0] = 3; // Error's out at this point immSlice.length = 1; writeln(immSlice); } From, Vino.B
Re: Programming in D by Ali Çehreli
On 10/17/2016 11:10 AM, vino wrote: Hi All, As per the book named in the subject it states as below,so can some one guide me what is wrong in the below code nor correct if my understanding is wrong. Page 154 immutable(int[]) specifies that neither the slice nor its elements can be modified. So which means that a element or a slice of any array can be modified, but the below example code is not working. import std.stdio; void main() { immutable(int[]) immSlice = [ 1, 2 ]; immSlice ~= 3; immSlice[0] = 3; // Error's out at this point immSlice.length = 1; writeln(immSlice); } From, Vino.B What version is your compiler? My version is DMD64 D Compiler v2.072.0-b2. Trying the code with a recent compiler produces three compilation errors for the following three lines immSlice ~= 3; immSlice[0] = 3; immSlice.length = 1; Error: cannot modify immutable expression immSlice Error: cannot modify immutable expression immSlice[0] Error: cannot modify immutable expression immSlice Ali
Re: Programming in D by Ali Çehreli
On Monday, 17 October 2016 at 18:10:01 UTC, vino wrote: Hi All, As per the book named in the subject it states as below,so can some one guide me what is wrong in the below code nor correct if my understanding is wrong. Page 154 immutable(int[]) specifies that neither the slice nor its elements can be modified. So which means that a element or a slice of any array can be modified, but the below example code is not working. import std.stdio; void main() { immutable(int[]) immSlice = [ 1, 2 ]; immSlice ~= 3; immSlice[0] = 3; // Error's out at this point immSlice.length = 1; writeln(immSlice); } From, Vino.B I don't see what you don't understand, you said it yourself: "neither the slice nor its elements can be modified". So you can't modify the elements of an immutable array. immSlice is an immutable array of which you are trying to modify an element.
Re: Range violation with AAs
On 10/17/2016 10:43 AM, Nordlöw wrote: At https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d I have an array container. Everything works as expected in all unittests except for the line at https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d#L1649 that fails as core.exception.RangeError@array_ex.d(1649): Range violation and I have no clue why. Is this a know problem with AA's with container-like structs as value types? So, x is a user-defined type and the line that fails is x["a"] ~= 42; Unfortunately, as far as I know, that's a privilege reserved for built-in AAs. It still feels like x["a"] could return a proxy that could later add a new element and then apply ~= on it. (I haven't read the rest of your code to see whether you've already done that.) Ali
Re: Range violation with AAs
On Monday, 17 October 2016 at 17:43:19 UTC, Nordlöw wrote: At https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d I have an array container. Everything works as expected in all unittests except for the line at https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d#L1649 that fails as core.exception.RangeError@array_ex.d(1649): Range violation and I have no clue why. Is this a know problem with AA's with container-like structs as value types? In other words alias Key = string; alias A = Array!int; A[Key] x; x["a"] ~= 42; // triggers violation fails. If I initialize the value prior to append as in alias Key = string; alias A = Array!int; A[Key] x; x["a"] = A.init; x["a"] ~= 42; // no violation the violation doesn't happen. And if I replace `Array!int` with `int[]` as in alias Key = string; alias A = int[]; A[Key] x; x["a"] ~= 42; it also doesn't happen.
Re: Range violation with AAs
On Monday, 17 October 2016 at 18:22:53 UTC, Ali Çehreli wrote: Unfortunately, as far as I know, that's a privilege reserved for built-in AAs. But I *am* using a built-in AA. The problem happens when the value is an instance of an `Array!T`-container and not a slice `T[]`.
Re: Range violation with AAs
On 10/17/2016 11:28 AM, Nordlöw wrote: On Monday, 17 October 2016 at 18:22:53 UTC, Ali Çehreli wrote: Unfortunately, as far as I know, that's a privilege reserved for built-in AAs. But I *am* using a built-in AA. The problem happens when the value is an instance of an `Array!T`-container and not a slice `T[]`. Sorry... :/ As a consolation :) there are two unrelated issues in your code, which a new dmd warns about: Deprecation: Implicit string concatenation is deprecated 1) Probably a missing comma after `mark`: enum nonStateHTMLTags = [`b`, `i`, `strong`, `em`, `sub`, `sup`, `small`, `ins`, `del`, `mark` `code`, `kbd`, `samp`, `samp`, `var`, `pre`]; 2) Missng ~ here: `` ~ zexp ~ `` `` ~ Ali
Re: Range violation with AAs
On Monday, 17 October 2016 at 18:22:53 UTC, Ali Çehreli wrote: It still feels like x["a"] could return a proxy that could later add a new element and then apply ~= on it. (I haven't read the rest of your code to see whether you've already done that.) `Array` is in essence a C++-style array container (pointer, length, capacity) with C-style memory management. Nothing else. Have I done something wrong with ~= overloads perhaps?
Re: Range violation with AAs
On Monday, 17 October 2016 at 18:38:30 UTC, Ali Çehreli wrote: As a consolation :) there are two unrelated issues in your code, which a new dmd warns about: Deprecation: Implicit string concatenation is deprecated 1) Probably a missing comma after `mark`: enum nonStateHTMLTags = [`b`, `i`, `strong`, `em`, `sub`, `sup`, `small`, `ins`, `del`, `mark` `code`, `kbd`, `samp`, `samp`, `var`, `pre`]; 2) Missng ~ here: `` ~ zexp ~ `` `` ~ Thanks, anyway! Fixed!
Re: Range violation with AAs
On 10/17/2016 11:40 AM, Nordlöw wrote: On Monday, 17 October 2016 at 18:22:53 UTC, Ali Çehreli wrote: It still feels like x["a"] could return a proxy that could later add a new element and then apply ~= on it. (I haven't read the rest of your code to see whether you've already done that.) `Array` is in essence a C++-style array container (pointer, length, capacity) with C-style memory management. Nothing else. Have I done something wrong with ~= overloads perhaps? opOpAssign? (I need to stop guessing without coding. :) ) Ali
Re: Range violation with AAs
On 10/17/16 1:43 PM, Nordlöw wrote: At https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d I have an array container. Everything works as expected in all unittests except for the line at https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d#L1649 that fails as core.exception.RangeError@array_ex.d(1649): Range violation and I have no clue why. This seems like a bug. If RangeError is happening there, this means it's the AA that's complaining, not the Array!int. If this works properly with normal arrays, it means something is wrong in the way the AA behaves. Just another issue with our AA magic, I guess. -Steve
Re: Range violation with AAs
On Monday, 17 October 2016 at 17:43:19 UTC, Nordlöw wrote: At https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d I have an array container. Everything works as expected in all unittests except for the line at https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d#L1649 that fails as core.exception.RangeError@array_ex.d(1649): Range violation and I have no clue why. Is this a know problem with AA's with container-like structs as value types? The same unittest with another Array (i.e not the one from phobos-next) gives the same error, so this confirms the other answer saying that's may be a builtin AA bug. Just a question, maybe off topic, does this work: unittest { alias Key = string; alias A = Array!int; A[Key] x; x["a"] = [0]; } ?
Re: About debugging (again)
On Monday, 17 October 2016 at 17:57:19 UTC, Martin Krejcirik wrote: On Monday, 17 October 2016 at 15:45:56 UTC, ANtlord wrote: GDB 7.7.1 Use latest GDB, 7.10 has got much better D support. Tested on GDB 7.11.1. Same case :(
Re: About debugging (again)
On Monday, 17 October 2016 at 17:53:30 UTC, Basile B. wrote: On Monday, 17 October 2016 at 17:46:05 UTC, Basile B. wrote: On Monday, 17 October 2016 at 15:45:56 UTC, ANtlord wrote: On Monday, 17 October 2016 at 15:43:32 UTC, ANtlord wrote: [...] Oh Sorry, I've forgotten about pointing technical parameters. Ubuntu 14.04 GDB 7.7.1 DMD64 D Compiler v2.071.1 redirect gdb's output to "ddemangle". This is what I do in the alpha version of Coedit's GDB commander, now in console mode I don't know the exact method. seems to be: gdb binary_name | ddemangle This makes gdb useless. I can't type any command. Propably can I use demangle by another way?
Re: Programming in D by Ali Çehreli
On Monday, 17 October 2016 at 18:20:00 UTC, cym13 wrote: On Monday, 17 October 2016 at 18:10:01 UTC, vino wrote: [...] I don't see what you don't understand, you said it yourself: "neither the slice nor its elements can be modified". So you can't modify the elements of an immutable array. immSlice is an immutable array of which you are trying to modify an element. I would expect him to see the first error on `immSlice ~= 3;`.
Re: About debugging (again)
On Monday, 17 October 2016 at 19:14:49 UTC, ANtlord wrote: On Monday, 17 October 2016 at 17:57:19 UTC, Martin Krejcirik wrote: On Monday, 17 October 2016 at 15:45:56 UTC, ANtlord wrote: GDB 7.7.1 Use latest GDB, 7.10 has got much better D support. Tested on GDB 7.11.1. Same case :( redirect to ddemangle, that's its job.
Re: Range violation with AAs
On Monday, 17 October 2016 at 19:10:54 UTC, Basile B. wrote: Just a question, maybe off topic, does this work: unittest { alias Key = string; alias A = Array!int; A[Key] x; x["a"] = [0]; } ? No, that works. Thanks for your interest.
Re: Speed of synchronized
On 17/10/16 14:44, Christian Köstlin wrote: > On 17/10/16 14:09, Daniel Kozak via Digitalmars-d-learn wrote: >> Dne 16.10.2016 v 10:41 Christian Köstlin via Digitalmars-d-learn napsal(a): >>> Hi, >>> >>> for an exercise I had to implement a thread safe counter. >>> This is what I came up with: >>> >>> >>> btw. I run the code with dub run --build=release >>> >>> Thanks in advance, >>> Christian >> So I have done some testing, on my pc: >> Java result >> counter.AtomicLongCounter@7ff5e7d8 expected: 200 got: 100 in: 83ms >> counter.ThreadSafe2Counter@59b44e4b expected: 200 got: 100 in: 77ms >> counter.ThreadSafe1Counter@2e5f6b4b expected: 200 got: 100 in: >> 154ms >> counter.ThreadUnsafeCounter@762b155d expected: 200 got: 730428 in: 13ms >> >> and my D results (code: http://dpaste.com/3QFXACY ): >> snip.AtomicCounter: got: 100 expected: 100 in 77 ms and 783 μs >> snip.ThreadSafe1Counter: got: 100 expected: 100 in 287 ms, 727 >> μs, and 3 hnsecs >> snip.ThreadSafe2Counter: got: 100 expected: 100 in 281 ms, 117 >> μs, and 1 hnsec >> snip.ThreadSafe3Counter: got: 100 expected: 100 in 158 ms, 480 >> μs, and 2 hnsecs >> snip.ThreadUnsafeCounter: got: 100 expected: 100 in 6 ms, 682 >> μs, and 1 hnsec >> >> so atomic is same as in Java pthread_mutex is same speed as java >> synchronized >> D mutexes and D synchronized are almost same, I belive that if I could >> setup same attrs as in pthread version it will be around 160ms too. >> >> Unsafe is almost same for D and java. Only java ReentrantLock seems to >> work better. I believe there is some trick, so it will end up not using >> mutexes in the end at all. For example consider this change in D code: >> >> void doIt(alias counter)() { >> auto thg = new ThreadGroup(); >> for (int i=0; i> thg.create(&threadFuncBody!(counter)); >> } >> thg.joinAll(); >> } >> >> change it to >> >> void doIt(alias counter)() { >> auto thg = new ThreadGroup(); >> for (int i=0; i> auto tc = thg.create(&threadFuncBody!(counter)); >> tc.join(); >> } >> } >> >> and results are: >> >> snip.AtomicCounter: got: 100 expected: 100 in 22 ms, 251 μs, and >> 6 hnsecs >> snip.ThreadSafe1Counter: got: 100 expected: 100 in 46 ms, 146 >> μs, and 3 hnsecs >> snip.ThreadSafe2Counter: got: 100 expected: 100 in 44 ms, 961 >> μs, and 5 hnsecs >> snip.ThreadSafe3Counter: got: 100 expected: 100 in 42 ms, 512 >> μs, and 8 hnsecs >> snip.ThreadUnsafeCounter: got: 100 expected: 100 in 2 ms, 108 >> μs, and 5 hnsecs >> >> >> >> >> > thank you for looking into it. > this seems to be quite good. > I did expect something in those lines, but got the mentioned numbers on > my os x macbook. perhaps its a os x glitch. > Thanks for the hint about the OS. I rerun the tests on a linux machine, and there everything is fine! linux dlang code: app.AtomicCounter: got: 100 expected: 100 in 24 ms, 387 μs, and 3 hnsecs app.ThreadSafe1Counter: got: 100 expected: 100 in 143 ms, 534 μs, and 9 hnsecs app.ThreadSafe2Counter: got: 100 expected: 100 in 159 ms, 685 μs, and 1 hnsec app.ThreadUnsafeCounter: got: 399937 expected: 100 in 9 ms and 556 μs from example got: 156 ms, 198 μs, and 9 hnsecs linux java code: counter.CounterTest > testAtomicIntCounter STANDARD_OUT counter.AtomicIntCounter@1f2a2347 expected: 100 got: 100 in: 29ms counter.CounterTest > testAtomicLongCounter STANDARD_OUT counter.AtomicLongCounter@675ad891 expected: 100 got: 100 in: 24ms counter.CounterTest > testThreadSafe2Counter STANDARD_OUT counter.ThreadSafe2Counter@3043c6d2 expected: 100 got: 100 in: 38ms counter.CounterTest > testThreadSafeCounter STANDARD_OUT counter.ThreadSafe1Counter@bac4ba3 expected: 100 got: 100 in: 145ms counter.CounterTest > testThreadUnsafeCounter STANDARD_OUT counter.ThreadUnsafeCounter@2fe82bf8 expected: 100 got: 433730 in: 9ms Could someone check the numbers on another OS-X machine? Unfortunately I only have one available. Thanks in advance!
Re: Speed of synchronized
Dne 17.10.2016 v 23:40 Christian Köstlin via Digitalmars-d-learn napsal(a): Could someone check the numbers on another OS-X machine? Unfortunately I only have one available. Thanks in advance! Can you try it on OSX with ldc compiler: dub run --build=release --compiler=ldc
Visual Studio Linker Problem
I am working my way up to building NanoVG per my previous post. I am able to compile hello world using dmd2. I am running in cygwin because I understand bash way better than cmd.exe. I am unable to compile hello world using ldc2. I am interested in ldc because I am interested in compiling to different arch-es and I happen to be a FreeBSD guy which uses LLVM by default. I figure that what I learn in LDC under windows will be portable for me. I received this error: $ ldc2 hello.d Using Visual C++: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC LINK : fatal error LNK1104: cannot open file 'libucrt.lib' Error: `C:\Windows\system32\cmd.exe /s /c "C:\Users\jcw\Documents\Projects\Programming\dlang\ldc2-1.1.0-beta3-win64-msvc\bin\amd64.bat link.exe"` failed with status: 1104 The file "libucrt.lib" is found in several VS folders. I am sure that this is some path issue, but I'm not savvy on VisualStudio. I read some scary messages about this error in other parts of the forum from about a year ago. Hopefully the solution is easier than what I read in that thread. I see mention of a "vcvarsall.bat" file that might set my paths correctly, but this file is not found on my system. I see mention of a VCINSTALLDIR variable which is not set on my system. Regards, Jason C. Wells
Re: Programming in D by Ali Çehreli
On Monday, 17 October 2016 at 18:20:00 UTC, cym13 wrote: On Monday, 17 October 2016 at 18:10:01 UTC, vino wrote: Hi All, As per the book named in the subject it states as below,so can some one guide me what is wrong in the below code nor correct if my understanding is wrong. Page 154 immutable(int[]) specifies that neither the slice nor its elements can be modified. So which means that a element or a slice of any array can be modified, but the below example code is not working. import std.stdio; void main() { immutable(int[]) immSlice = [ 1, 2 ]; immSlice ~= 3; immSlice[0] = 3; // Error's out at this point immSlice.length = 1; writeln(immSlice); } From, Vino.B I don't see what you don't understand, you said it yourself: "neither the slice nor its elements can be modified". So you can't modify the elements of an immutable array. immSlice is an immutable array of which you are trying to modify an element. Hi, Thank you for your reply, can you address why the below code is not working import std.stdio; void main() { int[] Array = [ 1, 2, 3, 4 ]; immutable(int[]) immSlice = Array[ 0 .. 2 ]; writeln("1st : ", immSlice); immSlice ~= 3; writeln("2nd : ", immSlice); immSlice[0] = 3; writeln("3rd : ", immSlice); immSlice.length = 1; writeln("4th : ",immSlice); }
Re: Programming in D by Ali Çehreli
On Monday, 17 October 2016 at 18:17:24 UTC, Ali Çehreli wrote: On 10/17/2016 11:10 AM, vino wrote: [...] What version is your compiler? My version is DMD64 D Compiler v2.072.0-b2. Trying the code with a recent compiler produces three compilation errors for the following three lines immSlice ~= 3; immSlice[0] = 3; immSlice.length = 1; Error: cannot modify immutable expression immSlice Error: cannot modify immutable expression immSlice[0] Error: cannot modify immutable expression immSlice Ali Hi Ali, I am using DMD64 D Compiler v2.071.2-b5