Re: Are structs saved in multi-thread delegate call?
On Saturday, 23 April 2016 at 01:11:49 UTC, Ramon wrote: mmm, I figured the problem, but don't know how to solve it. my struct has a destructor which clears itself: struct json_value { ~this() { .ValueClear(&data); } } so how I can I put a struct in the heap? (not in the stack, as is the default..) new or make with arg or new or make then opAssign or this(this). but have you tried __ghsared immutable json_value cbk = json_value(prms.argv[3]); ? without __gshared cbk might be on the TLS. (see with -vtls switch on DMD)
Re: Rust piece on integer safety
On Saturday, 30 April 2016 at 23:11:20 UTC, Laeeth Isharc wrote: All the design/discussion/implementation of this scheme for handling integer overflow would be wasted if it didn’t actually find any bugs in practice. I personally have had quite a few bugs found nearly as I write them, with expressions like cmp::max(x - y, z) (they never hit the internet, so no links for them), especially when combined with testing infrastructure like quickcheck. The overflow checks have found bugs through out the ecosystem; for instance, (not exhaustive!) the standard library the compiler the built-in benchmark harness Servo image url webrender Beyond Rust, there’s a lot of evidence for the dangers of integer overflow and desire for detecting/protecting against them. It was on the CWE/SANS list of top 25 errors in 2011, languages like Swift will unconditionally check for overflow, and others like Python 3 and Haskell will avoid overflow entirely by default, via arbitrary precision integers. Furthermore, in C, several compilers have options to both make signed overflow defined as two’s complement wrapping (-fwrapv) and to catch it when it does happen (-fsanitize=signed-integer-overflow). http://huonw.github.io/blog/2016/04/myths-and-legends-about-integer-overflow-in-rust/ I wonder if Rust uses the built-in "LLVM integer overflow checking". Recently this has been posted to r/programming: http://blog.regehr.org/archives/1384 Since LLVM is used as backend the Rust article might talk exactly about the same thing. (to be verified, actually I know nothing about Rust).
Re: question about passing associative array to a function
On Sunday, 11 May 2014 at 14:46:35 UTC, rbutler wrote: I have searched and can not understand something about passing AAs to a function. I have reduced the gist of the question to a tiny program below. If I put "ref" in the function stmt it works, i.e.: ref int[int] aa My confusion is that AAs are supposed to be passed as refs anyway, so I do not understand why I should have to use ref to make it work. Related, it also works if I UN-comment the lined[9] = 9; Thanks for any helpful comments you can make. --rbutler import std.stdio; void test(int[int] aa, int x) { aa[x] = x; aa[8] = 8; } void main() { int[int] d; writeln(d.length); // d[9] = 9; test(d, 0); writeln(d); } The AA is passed by value but its underlying data is referenced, making the copy cheap. The snippet below also shows the same behaviour even when the AA has data in it before calling the function. --- void func(string[int] aa) { writefln("[FUNC1]&aa:%s=%s", &aa, aa); // Reassign the data here in func()'s copy and // main never sees it aa = [2:"two"]; writefln("[FUNC2]&aa:%s=%s", &aa, aa); } void main() { string[int] aa; aa[1] = "one"; writefln("[MAIN1]&aa:%s=%s", &aa, aa); func(aa); writefln("[MAIN2]&aa:%s=%s", &aa, aa); } --- It is the same as passing a C++ shared_ptr<> by value. Cheers, ed
Template delegate/function ptr struct member
I'm porting some C++ code to D and a struct has the following member: struct S { // ... //void* (*createMethod)(); void* function() createMethod; } I'd like to extend this as little to accept delegates for future use without breakage to existing code... Is it possible to template this so "createMethod" can be a delegate() or function() of any type *and* have the compiler infer the type from ctor parameters? For example: --- struct S(F) { // ... F createMethod; this(alias F)() {createMethod = &F;} } static void* func() {return null;} void main() { auto s1 = S(&func); auto s2 = S(&Object.classinfo.create); // s1 is S!(void* function()) // s2 is S!(Object delegate() const); } --- Is this a good idea or am I way off? Thanks, ed
Re: DFL is the best UIcontrols for D,compare it to dwt, tkd,dtk,dlangui,anchovy......
On Tuesday, 13 May 2014 at 15:20:36 UTC, FrankLike wrote: DFL is just a thin wrapper around Win32, no surprise. I've found my apps written using DFL work quite fine in Linux via Wine, so I use them from both OSes. In Linux?The exe was compiled in win32? Don't play jokes on it. He's not joking, it is via wine. As for the DFL/DWT,GTK-d,TKd comparison you need to compare apples with apples. If you can improve DFL widgets so they: 1. support linux, windows, mac 2. support the same features as the "more complex" GUI widgets With the constraint that: 3. DFL uses less LOC and reduces code complexity comapred to GTK-d and DWT Then the comparison between DFL and other GUI libraries would be interesting. Cheers, ed
Re: DFL is the best UIcontrols for D,compare it to dwt, tkd,dtk,dlangui,anchovy......
On Wednesday, 14 May 2014 at 06:14:16 UTC, FrankLike wrote: On Tuesday, 13 May 2014 at 23:26:20 UTC, ed wrote: On Tuesday, 13 May 2014 at 15:20:36 UTC, FrankLike wrote: DFL is just a thin wrapper around Win32, no surprise. I've found my apps written using DFL work quite fine in Linux via Wine, so I use them from both OSes. In Linux?The exe was compiled in win32? Don't play jokes on it. He's not joking, it is via wine. As for the DFL/DWT,GTK-d,TKd comparison you need to compare apples with apples. If you can improve DFL widgets so they: 1. support linux, windows, mac 2. support the same features as the "more complex" GUI widgets With the constraint that: 3. DFL uses less LOC and reduces code complexity comapred to GTK-d and DWT Then the comparison between DFL and other GUI libraries would be interesting. Cheers, ed Don't you want to look for the DFL's author Christopher E. Miller? 'DFL is Copyright (C) 2004-2010 Christopher E. Miller' Not particularly as I am not that interested in DFL. But you can work on DFL without the author, i.e. make improvements, port to Linux or whatever you wish. http://dsource.org/projects/dfl/browser/trunk/win32/dfl/license.txt The DFL library is under a 3-choice license, pick one that suits you: LGPL, ZLIB, DFL license. Then go code :) Cheers, ed
Re: Kernel in D
On Saturday, 31 May 2014 at 07:28:32 UTC, Mineko wrote: So, I've gotten interested in kernel programming in D.. And as much as I like C/C++, I wanna try innovating, I'm aware that phobos/gc and any OS-specific issues are going to be a problem, but I'm willing to implement them into the kernel itself. So, I guess what I'm asking is this: What should I look out for, what should I avoid, and what should I use to my advantage? I'm not expecting this kernel to be Linux right off the bat, but I would like to see how far D can go with this. Any ideas? :P I wrote a little kernel a while back that all started when I read this wiki page: http://wiki.osdev.org/D_Bare_Bones You may be beyond this already as it is pretty basic stuff...still it's good if you're just learning like I am. There are some articles that helped me fix the 64-bit bootloader issues I was having as well. Cheers, ed
Re: Segfault in shared object when writeln
On Wednesday, 4 June 2014 at 03:49:25 UTC, Harpo wrote: Hello I am having the following problem. I am trying to turn a program I have written into a shared object. I have ran into some problems however. When I use writeln instead of printf my program segfaults. I have edited the code to just the parts causing the problem. =main.d the so import std.stdio; import core.stdc.stdio; extern (C) void main(){ writeln("Does it work?"); printf("Works"); } ==main.c the main executable== #include #include #include int main() { printf("+main()\n"); void *lh = dlopen("THE PATH EDITED FOR MY SECURITY", RTLD_LAZY); if (!lh) { fprintf(stderr, "dlopen error: %s\n", dlerror()); exit(1); } printf("libdll.so is loaded\n"); void (*fn)() = dlsym(lh, "main"); char *error = dlerror(); if (error) { fprintf(stderr, "dlsym error: %s\n", error); exit(1); } printf("dll() function is found\n"); (*fn)(); printf("unloading libdll.so\n"); dlclose(lh); printf("-main()\n"); return 0; } The compile script=== dmd -c main.d -fPIC dmd -oflibdll.so main.o -shared -defaultlib=libphobos2.so -L-rpath=/usr/lib/x86_64-linux-gnu -L-ldl -gc gcc -c main.c gcc -rdynamic main.o -o main -ldl = When I have just printf is works. When I have writeln it segfaults. This fails import std.stdio; extern (C) void main(){ writeln("Does it work?"); } This works import core.stdc.stdio; extern (C) void main(){ printf("Works"); } === Any one know whats up? Thanks! -Harpo I believe you need to initialise the D runtime in your D code before using Phobos or druntime itself in this manner. The printf call just wraps the C runtime but writeln requires the D runtime to be initialised. Check out http://dlang.org/phobos/core_runtime.html#.Runtime.initialize http://dlang.org/phobos/core_runtime.html#.Runtime.terminate Cheers, ed Cheers, ed
Re: Segfault in shared object when writeln
On Wednesday, 4 June 2014 at 04:46:59 UTC, ed wrote: On Wednesday, 4 June 2014 at 03:49:25 UTC, Harpo wrote: Hello I am having the following problem. I am trying to turn a program I have written into a shared object. I have ran into some problems however. When I use writeln instead of printf my program segfaults. I have edited the code to just the parts causing the problem. =main.d the so import std.stdio; import core.stdc.stdio; extern (C) void main(){ writeln("Does it work?"); printf("Works"); } ==main.c the main executable== #include #include #include int main() { printf("+main()\n"); void *lh = dlopen("THE PATH EDITED FOR MY SECURITY", RTLD_LAZY); if (!lh) { fprintf(stderr, "dlopen error: %s\n", dlerror()); exit(1); } printf("libdll.so is loaded\n"); void (*fn)() = dlsym(lh, "main"); char *error = dlerror(); if (error) { fprintf(stderr, "dlsym error: %s\n", error); exit(1); } printf("dll() function is found\n"); (*fn)(); printf("unloading libdll.so\n"); dlclose(lh); printf("-main()\n"); return 0; } The compile script=== dmd -c main.d -fPIC dmd -oflibdll.so main.o -shared -defaultlib=libphobos2.so -L-rpath=/usr/lib/x86_64-linux-gnu -L-ldl -gc gcc -c main.c gcc -rdynamic main.o -o main -ldl = When I have just printf is works. When I have writeln it segfaults. This fails import std.stdio; extern (C) void main(){ writeln("Does it work?"); } This works import core.stdc.stdio; extern (C) void main(){ printf("Works"); } === Any one know whats up? Thanks! -Harpo I believe you need to initialise the D runtime in your D code before using Phobos or druntime itself in this manner. The printf call just wraps the C runtime but writeln requires the D runtime to be initialised. Check out http://dlang.org/phobos/core_runtime.html#.Runtime.initialize http://dlang.org/phobos/core_runtime.html#.Runtime.terminate Cheers, ed Cheers, ed I just remembered you can do this on the C side, which is easier to manage http://dlang.org/phobos/core_runtime.html#.rt_init http://dlang.org/phobos/core_runtime.html#.rt_term Cheers, ed
Re: Kernel in D
On Thursday, 5 June 2014 at 11:07:54 UTC, 1100110 wrote: On 6/5/14, 6:05, 1100110 wrote: On 5/31/14, 7:57, ed wrote: On Saturday, 31 May 2014 at 07:28:32 UTC, Mineko wrote: So, I've gotten interested in kernel programming in D.. And as much as I like C/C++, I wanna try innovating, I'm aware that phobos/gc and any OS-specific issues are going to be a problem, but I'm willing to implement them into the kernel itself. So, I guess what I'm asking is this: What should I look out for, what should I avoid, and what should I use to my advantage? I'm not expecting this kernel to be Linux right off the bat, but I would like to see how far D can go with this. Any ideas? :P I wrote a little kernel a while back that all started when I read this wiki page: http://wiki.osdev.org/D_Bare_Bones You may be beyond this already as it is pretty basic stuff...still it's good if you're just learning like I am. There are some articles that helped me fix the 64-bit bootloader issues I was having as well. Cheers, ed Just a warning, there are a few bugs on that wiki page. Nothing major, just don't expect every example to work out of the box. (unless it has been updated in the last year of course). I thought about editing it, but I lost interest in my project before I got around to it. =C I've long since forgotten what issues I encountered though... I should also clarify that I'm just a novice and really just wanted insight into how it all worked. So anyone more experienced might simply know something that I did not. Yes I remember now I also had some issues but I've forgotten what what were exactly ... it was a while ago. I put it down to the fact I was using DMD not GDC and trying to boot from GRUB. But it could be more than that. Cheers, ed
Re: Are there desktop appications being developed in D currently?
On Saturday, 9 August 2014 at 00:34:43 UTC, Puming wrote: Hi, I bumped into a blog talking about building a (toy) browser engine in Rust: (http://limpet.net/mbrubeck/2014/08/08/toy-layout-engine-1.html) In the blog I found that the OP is in the mozilla servo team building a parallel browser for mozilla. The servo is hosted on github here: (https://github.com/servo) Yes, rust is a more infantile language compared to D, but people are already using them to create complicate applications like browser! This kind of projects would become a huge drive force to strengthen best practices in the language/lib design and attract newcomers. When I learned about Clojure, and found that an editor/ide [Light Table](http://lighttable.com) was written entirely by Clojure(script), was really intrigged. [Atom](http://atom.io) is written in nodejs/coffeescript. So I wonder, is there similar projects in D that I can take part, learn and enjoy? I see the current hotspot of D are compilers、libs、http-server and game area, but haven't encountered an application project such as an editor, music player, etc. Manu started a project a while back which you may be interested in looking at. http://forum.dlang.org/thread/mailman.470.1386845003.3242.digitalmar...@puremagic.com https://github.com/FeedBackDevs/feedback Cheers, ed
Re: Auto attributes for functions
On Wednesday, 20 August 2014 at 09:13:15 UTC, Jonathan M Davis via Digitalmars-d-learn wrote: On Wed, 20 Aug 2014 01:38:52 + uri via Digitalmars-d-learn wrote: Hi all, Bit new to D so this might be a very naive question... Can the compiler auto infer function attributes? I am often adding as many attributes as possible and use the compiler to show me where they're not applicable and take them away. It would be great if this could be achieved like so: auto function() @auto {} instead of manually writing: auto function() pure @safe nothrow @nogc const {} Currently, just templated functions get their attributes inferred. The biggest problem with inferring them for all functions is that you can declare a function without defining it in the same place (e.g. if you're using .di files), in which case the compiler has no function body to use for attribute inferrence. There have been discussions on ways to reasonably infer attributes under more circumstances, but nothing has come of them yet. However, I'd expect that there will be at least some improvements to the situation at some point given that there is a general consensus that while the attributes are quite useful, it's also rather annoying to have to keep typing them all. - Jonathan M Davis Thanks guys for the info. /uri