Re: Coming Soon: Stable D Releases!
On Wed, 18 Jul 2012 22:20:51 -0700, Caligo iteronve...@gmail.com wrote: Just curious, if Walter is too busy to make DMD more stable, then what does he spend most of his time on? I thought we were done with adding new features to the language (at least for now)? While COFF/x64 support for is technically a new feature, it's also one required for the survival of D. x86 is dead on OS X, and dying on Windows and Linux. So i'd say that it's pretty important for Walter to get it in now. On Mon, Jul 16, 2012 at 1:29 PM, Jonathan M Davis jmdavisp...@gmx.com wrote: On Monday, July 16, 2012 13:18:55 Caligo wrote: What?! All he has to do is create a branch and call it stable, or whatever, and use cherry-pick to move small stables patches from other branches to the stable branch. What's so difficult about that? I don't get it. It takes up his time for him to do it, and I don't think that there's any chance whatsoever of him giving someone else commit access to the main dmd repository to do this (certainly not at this point). He wasn't interested in changing the versioning or branching stuff at all. He agreed to this plan (which should be minimally disruptive to him) as an experiment. Depending on how it goes, we may change how we deal with the main repo, but for now, we're trying this. And since the likely alternative was that we would continue on exactly as we have been, this is presumably an improvement for the folks who wanted a branch with bug fixes with more frequent releases. - Jonathan M Davis -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
On Thursday, July 19, 2012 00:20:51 Caligo wrote: Just curious, if Walter is too busy to make DMD more stable, then what does he spend most of his time on? I thought we were done with adding new features to the language (at least for now)? No one said anything about Walter not making dmd more stable. What he doesn't have time to spend on is managing a separate branch which includes only bug fixes. He spends lots of time on both bug fixing and new stuff, and his skills are valuable enough that his time is better spent on actually coding than dealing with branch management. Currently, he's focusing on adding COFF support for Windows, which will make it possible to link using Microsoft's linker and generate 64-bit binaries. It's not a new feature in the sense that the language itself is gaining a feature, but it _is_ new functionality for the compiler. - Jonathan M Davis
Re: Initialization of std.typecons.RefCounted objects
On 07/18/2012 03:32 PM, Christophe Travert wrote: Matthias Walter , dans le message (digitalmars.D:172673), a écrit : I looked at Bug #6153 (Array!(Array!int) failure) and found that the This exactly is what makes the following code fail: Array!(Array!int) array2d; array2d.length = 1; array2d[0].insert(1); The inner array array2d[0] was not initialized and hence the reference pointer is null. Since Array.opIndex returns by value, the 'insert' method is called on a temporary object and does not affect the inner array (still being empty) which is stored in the outer array. What do you think about this? Must the user ensure that the Array container is always initialized explicitly? If yes, how shall this happen since the only constructor takes a (non-empty) tuple of new elements. Or shall opIndex return by reference? I think opIndex should return by reference. opIndexAssign is of no help when the user want to use a function that takes a reference (here Array.insert). It is normal that Array uses default construction when someone increases the array's length. Okay, I fully agree here. Besides that point, I don't see why default-constructed Array have an uninitialised Payload. This makes uninitialised Array behaves unexpectedly, because making a copy and using the copy will not affect the original, which is not the intended reference value behavior. Well the reason is that no user-defined function is called when a struct is default-constructed and then copied into another variable (the first one is this(this) which only known the new variable). Hence no user code can be written that would initialize the payload. Do we need a paradigm to perform explicit initialization of structs? Best regards, Matthias
Re: KR-style variadic functions
On 2012-07-18 22:12, Walter Bright wrote: How would you get the arguments inside foo? I don't know, you're the compiler writer :) I don't know these kind of things, that's why I started this thread. I'm just telling you how GCC/Clang treats these code snippets. -- /Jacob Carlborg
Re: Initialization of std.typecons.RefCounted objects
On Wednesday, 18 July 2012 at 13:32:39 UTC, trav...@phare.normalesup.org (Christophe Travert) wrote: I think opIndex should return by reference. opIndexAssign is of no help when the user want to use a function that takes a reference (here Array.insert). Having already brought this up before, the answer to that is that the containers inside container are meant to be closed and not give access to the addresses of their internals, so the return by value is on purpose: Here is Andrei's post about this: http://forum.dlang.org/thread/ceftaiklanejfhodb...@forum.dlang.org?page=2#post-jthdko:24231u:241:40digitalmars.com That said, I had brought up the exact same issue here: http://forum.dlang.org/thread/bkozswmsgeibarowf...@forum.dlang.org It is normal that Array uses default construction when someone increases the array's length. Besides that point, I don't see why default-constructed Array have an uninitialised Payload. This makes uninitialised Array behaves unexpectedly, because making a copy and using the copy will not affect the original, which is not the intended reference value behavior. I think it would be better to initialize on copy, rather than default initialize. There are too many cases an empty array is created, then initialized on the next line, or passed to something else that does the initialization proper. You'd get the correct behavior, and everything else (except dupe) works fine anyways.
Re: Re-thinking D's modules
On Wednesday, 18 July 2012 at 08:08:21 UTC, Dejan Lekic wrote: There are several places for D module system to improve. One thing we discussed in the past is the versioning, and as far as I remember, we did not come to any constructive conclusion. Java has been criticised often for not having modules. Apparently Java 9 SE will have them, and in my humble opinion, Java 9 module system is going to be far more powerful (or perhaps better word would be USEFUL) than what D currently has. More about Java Jigsaw: http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01 Why is this better? - Speaking from a (senior) software engineer point of view, Java Jigsaw is engineered for large systems where versioning, module-dependency, and module-restrictions are very important. I do not like few things about Jigsaw, but most of the things they plan there simply make sense, especially the versioning and module-restrictions, which I urge D developers to take a look and come up with something similar for D2 or D3... This is extremely useful, and will be even more useful once we have shared libraries where we can have N different shared libraries that contain the same module, but different version of it... Kind regards I'd say that this is going in the wrong direction. I read an article a while ago that was really enlightening about this subject. The gist was that a module system is the wrong abstraction. Modules are an artifact of procedural thinking in that they are global. This hurts security, testability, etc. Here's the link: bracha.org/newspeak-modules.pdf
Re: Initialization of std.typecons.RefCounted objects
monarch_dodra , dans le message (digitalmars.D:172700), a écrit : I think it would be better to initialize on copy, rather than default initialize. There are too many cases an empty array is created, then initialized on the next line, or passed to something else that does the initialization proper. Not default-initializing Array has a cost for every legitimate use of an Array. I think people use Array more often than they create uninitialized ones that are not going to be used before an other Array instance is assigned to them, so Array would be more efficient if it was default initialized and never check it is initialized again. But that's just speculation. You'd get the correct behavior, and everything else (except dupe) works fine anyways. Keeping the adress of the content secret may be a valuable intention, but as long as properties and opIndex does not allow to correctly forward methods, this is completely broken. Is there even a begining of a plan to implement this? I don't see how properties or opIndex could safely forward methods that uses references and that we do not control without escaping the reference to them. That's not possible until D has a complete control of escaping references, which is not planned in the near or distant future. Not to mention that having a complete control of escaping reference break lots of code anyway, and might considerably decrease the need for ref counted utilities like... Array. Please, at least give me hope that there is light at the end of the tunnel. -- Christophe
Re: KR-style variadic functions
On Wednesday, 18 July 2012 at 20:13:10 UTC, Walter Bright wrote: On 7/18/2012 11:47 AM, Jacob Carlborg wrote: On 2012-07-18 20:43, Walter Bright wrote: On 7/18/2012 4:59 AM, Jacob Carlborg wrote: Does that mean that this C++ declaration: void foo (...); Not allowed in C or C++. When compiling in C++ mode, both Clang and GCC accepts this. How would you get the arguments inside foo? As described here, http://pubs.opengroup.org/onlinepubs/7908799/xsh/varargs.h.html
Re: KR-style variadic functions
On Thu, 19 Jul 2012 08:33:12 +0100, Paulo Pinto pj...@progtools.org
wrote:
On Wednesday, 18 July 2012 at 20:13:10 UTC, Walter Bright wrote:
On 7/18/2012 11:47 AM, Jacob Carlborg wrote:
On 2012-07-18 20:43, Walter Bright wrote:
On 7/18/2012 4:59 AM, Jacob Carlborg wrote:
Does that mean that this C++ declaration:
void foo (...);
Not allowed in C or C++.
When compiling in C++ mode, both Clang and GCC accepts this.
How would you get the arguments inside foo?
As described here,
http://pubs.opengroup.org/onlinepubs/7908799/xsh/varargs.h.html
That /requires/ an argument in the definition (AFAIKS), e.g.
execl(va_alist) - va_alist is the argument name
va_dcl - this is #define va_dcl va_list va_alist;
{
}
so, it's no different to any other old-style function, e.g.
foo(a)
int a;
{
}
Now.. the declaration may be a different story. These would be valid
declarations for the above:
void execl(); - no parameters necessary in a declaration
void foo();- no parameters necessary in a declaration
It may be that GCC allows a declaration of:
void execl(...);
But I wasn't ware that was valid ANSI C, perhaps it's a GCC/clang
feature? Can anyone find docs on it?
If we /assume/ the above declaration always refers to a function with a
definition of:
execl(va_alist)
va_dcl
{
}
Then we assume the first argument is /always/ going to be a 32 bit value
(int, or 32 bit pointer) then we could speculatively convert to this D
extern (C) void execl(int first, ...);
But, if either assumption is false this would probably crash when used.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Initialization of std.typecons.RefCounted objects
On 07/19/2012 10:14 AM, Christophe Travert wrote: monarch_dodra , dans le message (digitalmars.D:172700), a écrit : I think it would be better to initialize on copy, rather than default initialize. There are too many cases an empty array is created, then initialized on the next line, or passed to something else that does the initialization proper. Not default-initializing Array has a cost for every legitimate use of an Array. I think people use Array more often than they create uninitialized ones that are not going to be used before an other Array instance is assigned to them, so Array would be more efficient if it was default initialized and never check it is initialized again. But that's just speculation. I agree here. Additionally my question: Is it possible (at the moment) to really do initialize on copy? As far as I see it, the only way to interact here is to implement 'this(this)' which is called after bit-copying and hence cannot access the source of the copy process.
Re: Octal Literals
monarch_dodra monarchdo...@gmail.com wrote in message news:srtxvzubdafcjzwwn...@forum.dlang.org... That said, I did not know of this 0o prefix. It sounds like a good idea, and I see no reason not to add it, other than it is hard work for the compiler devs of course, who already have a lot of work. :) It's a trivial amount of work to add '0o' octal literals to the language, but it was decided that octals are not used often enough to justify a language feature.
Re: Re-thinking D's modules
On 2012-07-19 11:18, foobar wrote: I'd say that this is going in the wrong direction. I read an article a while ago that was really enlightening about this subject. The gist was that a module system is the wrong abstraction. Modules are an artifact of procedural thinking in that they are global. This hurts security, testability, etc. Here's the link: bracha.org/newspeak-modules.pdf Does it suggest a better approach? -- /Jacob Carlborg
Re: Initialization of std.typecons.RefCounted objects
On Thursday, 19 July 2012 at 08:14:25 UTC, trav...@phare.normalesup.org (Christophe Travert) wrote: monarch_dodra , dans le message (digitalmars.D:172700), a écrit : I think it would be better to initialize on copy, rather than default initialize. There are too many cases an empty array is created, then initialized on the next line, or passed to something else that does the initialization proper. Not default-initializing Array has a cost for every legitimate use of an Array. I'm back pedaling and agreeing 100% actually. Plus it keeps the implementation simpler. +1 to you. Keeping the adress of the content secret may be a valuable intention, but as long as properties and opIndex does not allow to correctly forward methods, this is completely broken. Is there even a begining of a plan to implement this? I don't see how properties or opIndex could safely forward methods that uses references and that we do not control without escaping the reference to them. That's not possible until D has a complete control of escaping references, which is not planned in the near or distant future. Not to mention that having a complete control of escaping reference break lots of code anyway, and might considerably decrease the need for ref counted utilities like... Array. Please, at least give me hope that there is light at the end of the tunnel. One of the reason the implementation doesn't let you escape a reference is that that reference may become (_unverifiably_) invalid. Ranges to Arrays, on the other hand, keep a reference to the Array itself, and always* remain valid. (always as long as the Array doesn't shrink past the range's boundaries, but in this case, at least, the range throws an exception, rather than crash the program). A reference to a dynamic array, on the other hand, will ALWAYS be valid 100% of the time, because the original data is never actually destroyed (until unreferenced). So it is perfectly safe to expose references in an array. So escaping references from an Array is something _very_ dangerous, especially in a language that kind of guarantees it won't core dump if you don't manipulate pointers (which could if arrays escaped references). While I get your point, it really feels like a lose lose situation here: You get stiffed either way...with Array... ...That said, I see no reason for the other containers (SList, I'm looking at you), not to expose references. The way I see it, Array *could* escape references, but then the whole class would have to be qualified @unsafe (if such a thing existed) or something along these lines. The current work around? Copy-Extract, manipulate, re-insert. Sucks. On Thursday, 19 July 2012 at 10:39:56 UTC, Matthias Walter wrote: On 07/19/2012 10:14 AM, Christophe Travert wrote: I agree here. Additionally my question: Is it possible (at the moment) to really do initialize on copy? As far as I see it, the only way to interact here is to implement 'this(this)' which is called after bit-copying and hence cannot access the source of the copy process. Good point. The answer is no though. A RefCounted (also known as SharedPointer in C++) needs to be initialized first if you want it aliased. Allowing such a behavior is possible, but prohibitively expensive.
Re: KR-style variadic functions
On 2012-07-19 11:38, Regan Heath wrote: asn't ware that was valid ANSI C, perhaps it's a GCC/clang feature? Can anyone find docs on it? Note that it only works when compiling as C++. Perhaps it works like this: If C++ is interpreting this: void foo (); As: void foo (void); Perhaps it will interpret: void foo (...); As C would interpret this: void foo (); -- /Jacob Carlborg
Re: Initialization of std.typecons.RefCounted objects
monarch_dodra , dans le message (digitalmars.D:172710), a écrit : One of the reason the implementation doesn't let you escape a reference is that that reference may become (_unverifiably_) invalid. The same applies to a dynamic array: it is undistinguishable from a sliced static array. More generally, as long as you allow variables on the stack with no escaped reference tracking, you can't ensure references remain valid. Even in safe code. If I want my references to remain valid, I use dynamic array and garbage collection. If I use Array, I accept that my references may die. Array that protects the validity of their references are awesome. But, IMHO, not at that cost. ...That said, I see no reason for the other containers (SList, I'm looking at you), not to expose references. I'm against not exposing reference, but all containers will be implemented with custom allocator someday. The current work around? Copy-Extract, manipulate, re-insert. Sucks. IMO, what sucks even more is that arr[0].insert(foo) compiles while it has no effect. arr[0] is a R-value, but applying method to R-value is allowed. I don't know the state of debates about forbiding to call non-const methods on R-values. I think this would break too much code.
Re: Octal Literals
How was the reception of the idea of binary literals as opposed to octal (I think it's an awesome feature, I think D, OCaml and Java 7 are the only ones that have it)? How long did it take to decide to implement it?
Just where has this language gone wrong?
Hi,
I'm an occasional lurker on the D forums just to see where the
language is going,but I'm a little puzzled. In another thread I
found this code
auto r = [5, 3, 5, 6, 8].sort.uniq.map!(x = x.to!string);
I don't understand whats going on here. Int array is getting
sorted, then Uniqued, then what? What type is x? What kind of
operator is =, why is x.to!string allowed template
specialization should say x.to!(string), which leads me to think
that there are multiple syntaxes for things(why I hate dynamic
languages, love compiled)
On another note, (copied from wikipedia)
foreach(item; set) {
// do something to item
}
what's with the lax syntax being allowed? Shouldn't it be at
least specified auto item?
I'm sorry I don't mean to be a criticizer, but it seems to me
that D is trying to be a dynamic-like compiled language way too
hard.
Re: Just where has this language gone wrong?
On Thursday, 19 July 2012 at 14:21:47 UTC, Petr Janda wrote:
Hi,
I'm an occasional lurker on the D forums just to see where the
language is going,but I'm a little puzzled. In another thread I
found this code
auto r = [5, 3, 5, 6, 8].sort.uniq.map!(x = x.to!string);
I don't understand whats going on here. Int array is getting
sorted, then Uniqued, then what? What type is x? What kind of
operator is =, why is x.to!string allowed template
specialization should say x.to!(string), which leads me to
think that there are multiple syntaxes for things(why I hate
dynamic languages, love compiled)
On another note, (copied from wikipedia)
foreach(item; set) {
// do something to item
}
what's with the lax syntax being allowed? Shouldn't it be at
least specified auto item?
I'm sorry I don't mean to be a criticizer, but it seems to me
that D is trying to be a dynamic-like compiled language way too
hard.
(arguments) = result-expression is a lambda expression; sort of
shorthand for (arguments) { return result-expression; } anonymous
function. x.to!string thingy is the new UFCS stuff which
basically allows you to transform any foo(x, y, z) to x.foo(y, z)
(so instead of calling a(b(c(d(e(f) you can just call
a.b.c.d.e.f())
dynamic languages are awesome, they have their pros and cons, for
some things they're way better than static languages but for
other things static will fit better.
Re: Just where has this language gone wrong?
Am 19.07.2012 16:21, schrieb Petr Janda:
Hi,
I'm an occasional lurker on the D forums just to see where the language
is going,but I'm a little puzzled. In another thread I found this code
auto r = [5, 3, 5, 6, 8].sort.uniq.map!(x = x.to!string);
I don't understand whats going on here. Int array is getting sorted,
then Uniqued, then what? What type is x? What kind of operator is =,
why is x.to!string allowed template specialization should say
x.to!(string), which leads me to think that there are multiple syntaxes
for things(why I hate dynamic languages, love compiled)
On another note, (copied from wikipedia)
foreach(item; set) {
// do something to item
}
what's with the lax syntax being allowed? Shouldn't it be at least
specified auto item?
I'm sorry I don't mean to be a criticizer, but it seems to me that D is
trying to be a dynamic-like compiled language way too hard.
= → New Lambda Syntax
.sort.uniq.map(…) → UFCS (Uniform Function Call Syntax, iirc)
Array gets sorted, then doubles are removed (uniq) and then everything
is converted to a string (map).
Everything was recently introduced around 2.059.
Re: Just where has this language gone wrong?
btw - as for your complains - I would blame poor D documentation more than the feature itself; as for what type is x, it's inferred from the prototype of the called function; type inference is a standard feature in many static languages.
Re: Just where has this language gone wrong?
On Thursday, 19 July 2012 at 14:21:47 UTC, Petr Janda wrote:
Hi,
Hi
I'm an occasional lurker on the D forums just to see where the
language is going,but I'm a little puzzled. In another thread I
found this code
auto r = [5, 3, 5, 6, 8].sort.uniq.map!(x = x.to!string);
Here's list what happens:
1) Array gets sorted
2) Duplicate elements gets removed (only unique stay)
3) Then it get's maped by delegate. It converts numbers into
strings.
`r` variable will be [3, 5, 6, 8]
What type is x?
Type of x is inferred.
What kind of operator is =
Syntatic sugar for delegates.
On another note, (copied from wikipedia)
foreach(item; set) {
// do something to item
}
Item type is inferred from `set`, it's just syntactic sugar. Of
course you can use `auto` but you don't have to.
Re: Just where has this language gone wrong?
q66 , dans le message (digitalmars.D:172716), a écrit : (so instead of calling a(b(c(d(e(f) you can just call a.b.c.d.e.f()) rather f.e.d.c.b.a, if you omit the empty parenthesis after each letter (but f).
Re: Just where has this language gone wrong?
On 19-07-2012 16:31, Petr Janda wrote: Array gets sorted, then doubles are removed (uniq) and then everything is converted to a string (map). Everything was recently introduced around 2.059. Ok, but what is map!(). What's the point of the exclamation mark, is it a template specialization? It means template instantiation. The parameter list following the exclamation mark are passed to the template, while the second parameter list contains the normal runtime arguments. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: Just where has this language gone wrong?
On Thursday, 19 July 2012 at 14:31:41 UTC, Petr Janda wrote: Array gets sorted, then doubles are removed (uniq) and then everything is converted to a string (map). Everything was recently introduced around 2.059. Ok, but what is map!(). What's the point of the exclamation mark, is it a template specialization? stuff after ! specifies template arguments, in this case a predicate; map is a standard function in many languages; what it does basically is to go over an iterable object, apply the predicate function given in the template argument to each element and returns a new iterable containing the results of the predicate call on each element.
Re: Just where has this language gone wrong?
Array gets sorted, then doubles are removed (uniq) and then everything is converted to a string (map). Everything was recently introduced around 2.059. Ok, but what is map!(). What's the point of the exclamation mark, is it a template specialization?
Re: Just where has this language gone wrong?
On Thursday, 19 July 2012 at 14:33:49 UTC, q66 wrote: On Thursday, 19 July 2012 at 14:31:41 UTC, Petr Janda wrote: Array gets sorted, then doubles are removed (uniq) and then everything is converted to a string (map). Everything was recently introduced around 2.059. Ok, but what is map!(). What's the point of the exclamation mark, is it a template specialization? stuff after ! specifies template arguments, in this case a predicate; map is a standard function in many languages; what it does basically is to go over an iterable object, apply the predicate function given in the template argument to each element and returns a new iterable containing the results of the predicate call on each element. for example, auto x = [ 5, 10, 15, 20 ]; assert(map!(x = x + 1)(x) == [ 6, 11, 16, 21 ])
Re: Just where has this language gone wrong?
Am 19.07.2012 16:31, schrieb Petr Janda: Array gets sorted, then doubles are removed (uniq) and then everything is converted to a string (map). Everything was recently introduced around 2.059. Ok, but what is map!(). What's the point of the exclamation mark, is it a template specialization? without UFCS: map!(x = to!string(x))(my_range) Map is a template which takes a function/delegate/string at compile time, basic template usage.
Re: Just where has this language gone wrong?
Petr Janda , dans le message (digitalmars.D:172719), a écrit : Array gets sorted, then doubles are removed (uniq) and then everything is converted to a string (map). Everything was recently introduced around 2.059. Ok, but what is map!(). What's the point of the exclamation mark, is it a template specialization? Yes, !(...) is template specialization. It is the equivalent of ... in c++. The parentheses can be omited if only one argument is passed after the exclamation mark. map is a template of the std.algorithm module. http://dlang.org/phobos/std_algorithm.html#map This kind of questions should go in digitalmars.D.learn. -- Christophe
Re: Just where has this language gone wrong?
On Thursday, 19 July 2012 at 14:31:53 UTC, trav...@phare.normalesup.org (Christophe Travert) wrote: q66 , dans le message (digitalmars.D:172716), a écrit : (so instead of calling a(b(c(d(e(f) you can just call a.b.c.d.e.f()) rather f.e.d.c.b.a, if you omit the empty parenthesis after each letter (but f). Ok, but the empty parenthesis is is important, it tells you about whether it's a an object or a function. It's another thing I hate about Ruby is that a parenthesis enforcement is weak.
Re: Just where has this language gone wrong?
Robik , dans le message (digitalmars.D:172718), a écrit : On Thursday, 19 July 2012 at 14:21:47 UTC, Petr Janda wrote: Hi, Hi I'm an occasional lurker on the D forums just to see where the language is going,but I'm a little puzzled. In another thread I found this code auto r = [5, 3, 5, 6, 8].sort.uniq.map!(x = x.to!string); Here's list what happens: 1) Array gets sorted 2) Duplicate elements gets removed (only unique stay) 3) Then it get's maped by delegate. It converts numbers into strings. `r` variable will be [3, 5, 6, 8] To be more precise, `r` variable is a lazy range, equivalent to this array. r.array would be this array.
Re: Just where has this language gone wrong?
On 19-07-2012 16:36, Christophe Travert wrote: Petr Janda , dans le message (digitalmars.D:172719), a écrit : Array gets sorted, then doubles are removed (uniq) and then everything is converted to a string (map). Everything was recently introduced around 2.059. Ok, but what is map!(). What's the point of the exclamation mark, is it a template specialization? Yes, !(...) is template specialization. It is the equivalent of ... in c++. The parentheses can be omited if only one argument is passed after the exclamation mark. map is a template of the std.algorithm module. http://dlang.org/phobos/std_algorithm.html#map This kind of questions should go in digitalmars.D.learn. No, please, template instantiation. Specialization is something completely different, and doesn't happen at the call site. I don't mean to be overly pedantic, but I think OP has a C++ background or similar, so wrong terminology is not going to be helpful. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: Just where has this language gone wrong?
Petr Janda , dans le message (digitalmars.D:172727), a écrit : On Thursday, 19 July 2012 at 14:31:53 UTC, trav...@phare.normalesup.org (Christophe Travert) wrote: q66 , dans le message (digitalmars.D:172716), a écrit : (so instead of calling a(b(c(d(e(f) you can just call a.b.c.d.e.f()) rather f.e.d.c.b.a, if you omit the empty parenthesis after each letter (but f). Ok, but the empty parenthesis is is important, it tells you about whether it's a an object or a function. It's another thing I hate about Ruby is that a parenthesis enforcement is weak. property (functions that behaves like fields) don't require empty parenthesis. This feature has been extended to all function, leading to the current situation. Some people would like this to disappear, and enforce strict property. To take the function object, and not its result, take its adress. f == f() : the result f : the function. Indeed, by looking at f, you can't tell if it is a function or an object. You can never tell much when you see an isolated symbol...
Re: Just where has this language gone wrong?
Alex Rønne Petersen , dans le message (digitalmars.D:172728), a écrit : On 19-07-2012 16:36, Christophe Travert wrote: Petr Janda , dans le message (digitalmars.D:172719), a écrit : Array gets sorted, then doubles are removed (uniq) and then everything is converted to a string (map). Everything was recently introduced around 2.059. Ok, but what is map!(). What's the point of the exclamation mark, is it a template specialization? Yes, !(...) is template specialization. It is the equivalent of ... in c++. The parentheses can be omited if only one argument is passed after the exclamation mark. map is a template of the std.algorithm module. http://dlang.org/phobos/std_algorithm.html#map This kind of questions should go in digitalmars.D.learn. No, please, template instantiation. Specialization is something completely different, and doesn't happen at the call site. I don't mean to be overly pedantic, but I think OP has a C++ background or similar, so wrong terminology is not going to be helpful. You are right, its my mistake (well, I can still send the mistake back to Petr...).
Re: Just where has this language gone wrong?
On 19-07-2012 16:21, Petr Janda wrote:
Hi,
I'm an occasional lurker on the D forums just to see where the language
is going,but I'm a little puzzled. In another thread I found this code
auto r = [5, 3, 5, 6, 8].sort.uniq.map!(x = x.to!string);
I don't understand whats going on here. Int array is getting sorted,
then Uniqued, then what? What type is x? What kind of operator is =,
why is x.to!string allowed template specialization should say
x.to!(string), which leads me to think that there are multiple syntaxes
for things(why I hate dynamic languages, love compiled)
On another note, (copied from wikipedia)
foreach(item; set) {
// do something to item
}
what's with the lax syntax being allowed? Shouldn't it be at least
specified auto item?
I'm sorry I don't mean to be a criticizer, but it seems to me that D is
trying to be a dynamic-like compiled language way too hard.
No, it's just trying to make the developer's life easier.
What you see here is uniform function call syntax (UFCS), type
inference, array literals, etc. These are all more or less standard
features of modern statically typed languages. See ML, C#, Scala, F#,
Rust, ...
And please, don't use a title like what has gone wrong with this
language? if you're not sure how half of the features work. I don't
blame you for not understanding, but dlang.org has plenty of
documentation on these things (and TDPL certainly, too). Don't expect to
know exactly what some piece of code from an arbitrary language does
without knowing that language first.
I suspect that you have a C++ background. If this is not accurate,
ignore the rest. But if it is accurate, my plea to you is: Learn other
languages. C++ has next to no innovative language features (even C++11's
take on lambdas is an abomination) and encourages defensive programming
to the point where it's ridiculous (I mean, no default initialization of
variables? In 2012?).
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
Re: Just where has this language gone wrong?
On 07/19/2012 04:21 PM, Petr Janda wrote:
Hi,
I'm an occasional lurker on the D forums just to see where the language
is going,but I'm a little puzzled. In another thread I found this code
auto r = [5, 3, 5, 6, 8].sort.uniq.map!(x = x.to!string);
I don't understand whats going on here. Int array is getting sorted,
then Uniqued, then what?
Then it is mapped to string representations, just as the code says.
What type is x?
'int', if you like.
What kind of operator is =,
Lambda function. It is the same as (...){ return ...; }, just without
the noise.
why is x.to!string allowed template specialization should say
x.to!(string),
Why should it say that?
which leads me to think that there are multiple syntaxes
for things
There always are 'multiple syntaxes for things' if writing code should
be productive and validating code for static correctness should be
decidable.
(why I hate dynamic languages, love compiled)
This is unrelated to dynamic vs. compiled. (those two terms do not
contradict each other anyway.)
On another note, (copied from wikipedia)
foreach(item; set) {
// do something to item
}
what's with the lax syntax being allowed?
s/lax/to the point/
Shouldn't it be at least specified auto item?
Why on earth would that be the case?
I'm sorry I don't mean to be a criticizer, but it seems to me that D is
trying to be a dynamic-like compiled language way too hard.
It's just syntax. Eliminating syntax noise is fine. Code should look
like what it does.
Re: Just where has this language gone wrong?
No, please, template instantiation. Specialization is something completely different, and doesn't happen at the call site. Sorry, my fault. I'm a non-native english speaker. What I meant is calling functionstring(args) I think it's called instantiation.
Re: Octal Literals
Dave X. dxuhu...@gmail.com wrote in message news:cokspgduvpyzcbioa...@forum.dlang.org... How was the reception of the idea of binary literals as opposed to octal (I think it's an awesome feature, I think D, OCaml and Java 7 are the only ones that have it)? How long did it take to decide to implement it? Binary literals were before my time, but AVR assembler also has them.
Re: Just where has this language gone wrong?
It's just syntax. Eliminating syntax noise is fine. Code should
look
like what it does.
Not if eliminating noise equals to making things harder to
understand.
When you say (int x) { return x; } it's clear about what it is, a
_function_ without name.
Re: Just where has this language gone wrong?
On 07/19/2012 05:03 PM, Petr Janda wrote:
It's just syntax. Eliminating syntax noise is fine. Code should look
like what it does.
Not if eliminating noise equals to making things harder to understand.
Harder to understand to whom? Optimizing stuff for beginners usually
makes it a PITA to work with.
When you say (int x) { return x; } it's clear about what it is, a
_function_ without name.
That expression looks eg. like this in Haskell:
\x-x
(If the type of x cannot be inferred to Int, then it is (\x-x)::Int-Int)
I agree that there is some non-uniformity. It should be possible to use
= in named function declarations.
Re: Initialization of std.typecons.RefCounted objects
On 07/19/2012 02:16 PM, Christophe Travert wrote: monarch_dodra , dans le message (digitalmars.D:172710), a écrit : One of the reason the implementation doesn't let you escape a reference is that that reference may become (_unverifiably_) invalid. The same applies to a dynamic array: it is undistinguishable from a sliced static array. More generally, as long as you allow variables on the stack with no escaped reference tracking, you can't ensure references remain valid. Even in safe code. If I want my references to remain valid, I use dynamic array and garbage collection. If I use Array, I accept that my references may die. Array that protects the validity of their references are awesome. But, IMHO, not at that cost. ...That said, I see no reason for the other containers (SList, I'm looking at you), not to expose references. I'm against not exposing reference, but all containers will be implemented with custom allocator someday. The current work around? Copy-Extract, manipulate, re-insert. Sucks. IMO, what sucks even more is that arr[0].insert(foo) compiles while it has no effect. arr[0] is a R-value, but applying method to R-value is allowed. I don't know the state of debates about forbiding to call non-const methods on R-values. I think this would break too much code. As it seems the issue really should be resolved by making opIndex return by reference and press thumbs hard that something like a 'scope ref' will be implemented? Furthermore, since RefCounted objects do not behave like reference types until initialized, they *must* be initialized before anything else happens and hence I propose to change std.container.Array like Christophe said: Replace 'isInitialized()' checks by assertions and add a method with which the user explicitly initialized the reference counter. Or is there a reasonable alternative? Best regards, Matthias Walter
Re: Just where has this language gone wrong?
On 07/19/2012 04:39 PM, Petr Janda wrote: On Thursday, 19 July 2012 at 14:31:53 UTC, trav...@phare.normalesup.org (Christophe Travert) wrote: q66 , dans le message (digitalmars.D:172716), a écrit : (so instead of calling a(b(c(d(e(f) you can just call a.b.c.d.e.f()) rather f.e.d.c.b.a, if you omit the empty parenthesis after each letter (but f). Ok, but the empty parenthesis is is important, It is not. it tells you about whether it's a an object or a function. (No, it does not. And even if it would, ) There is usually nothing that makes this distinction terribly important. Furthermore, to learn the meaning of a symbol, being able to look at its documentation or declaration is fully sufficient / required. It's another thing I hate about Ruby is that a parenthesis enforcement is weak. I take that to mean you dislike ruby's function call syntax. That is a very poor thing to dislike, there is no objective justification for it.
Re: Just where has this language gone wrong?
On Thu, Jul 19, 2012 at 9:03 AM, Petr Janda janda.p...@gmail.com wrote:
It's just syntax. Eliminating syntax noise is fine. Code should look
like what it does.
Not if eliminating noise equals to making things harder to understand.
When you say (int x) { return x; } it's clear about what it is, a
_function_ without name.
Nothing is stopping someone from being explicit with their types like that,
of course.
Here is the original code written in a way that is probably more familiar
to you:
auto r = map!((int x) { to!(string)(x); })(uniq(sort([5, 3, 5, 6, 8])));
Personally I find the original version to be much more readable but that
does require a basic knowledge of D's syntax. People coming from other
languages are free to use the more classic way if they wish. It's better
to learn idiomatic usage of a language, though, instead of forcing it to be
a language you are more comfortable in.
Regards,
Brad Anderson
Re: Just where has this language gone wrong?
On Thu, Jul 19, 2012 at 9:20 AM, Brad Anderson e...@gnuk.net wrote:
On Thu, Jul 19, 2012 at 9:03 AM, Petr Janda janda.p...@gmail.com wrote:
It's just syntax. Eliminating syntax noise is fine. Code should look
like what it does.
Not if eliminating noise equals to making things harder to understand.
When you say (int x) { return x; } it's clear about what it is, a
_function_ without name.
Nothing is stopping someone from being explicit with their types like
that, of course.
Here is the original code written in a way that is probably more familiar
to you:
auto r = map!((int x) { to!(string)(x); })(uniq(sort([5, 3, 5, 6, 8])));
Ehm...forgot the return:
auto r = map!((int x) { return to!(string)(x); })(uniq(sort([5, 3, 5, 6,
8])));
Personally I find the original version to be much more readable but that
does require a basic knowledge of D's syntax. People coming from other
languages are free to use the more classic way if they wish. It's better
to learn idiomatic usage of a language, though, instead of forcing it to be
a language you are more comfortable in.
Regards,
Brad Anderson
Re: Just where has this language gone wrong?
On 07/19/2012 05:20 PM, Brad Anderson wrote:
On Thu, Jul 19, 2012 at 9:03 AM, Petr Janda janda.p...@gmail.com
mailto:janda.p...@gmail.com wrote:
It's just syntax. Eliminating syntax noise is fine. Code should look
like what it does.
Not if eliminating noise equals to making things harder to understand.
When you say (int x) { return x; } it's clear about what it is, a
_function_ without name.
Nothing is stopping someone from being explicit with their types like
that, of course.
Here is the original code written in a way that is probably more
familiar to you:
auto r = map!((int x) { to!(string)(x); })(uniq(sort([5, 3, 5, 6, 8])));
^
return
Personally I find the original version to be much more readable but that
does require a basic knowledge of D's syntax. People coming from other
languages are free to use the more classic way if they wish. It's
better to learn idiomatic usage of a language, though, instead of
forcing it to be a language you are more comfortable in.
Regards,
Brad Anderson
Re: reference to 'self' inside a function
On 07/19/2012 04:54 AM, Mehrdad wrote: On Tuesday, 17 July 2012 at 16:56:17 UTC, angel wrote: I propose to introduce a reference to the current function, much like 'this' in a class method. Call it 'self' or 'thisFunc', or whatever ... What might this be good for ? For implementing recursion in a lambda function. Writing in functional style, one creates many functions, and looking for reasonable names for these functions becomes unnecessarily painful. Recursive lambdas? o.O Instead of changing the language, I'd say your situation merits using the Y combinator... maybe define Y(f) to be (g = g(g))(g = f(x = g(g)(x))) then if you need to define factorial, just say... fact = Y(fact = n = n 0 ? n * fact(n - 1) : 1); - D does/can not have full type inference, because the type system with templates is Turing complete. - There is no way this is going to type check even with explicit type annotations, because there are no recursive function types. - Allocation of closures for control flow is not going to work efficiently with the current GC. - D actually has named functions, there is no need to use the anonymous lambda based y combinator to make up for the lack of them.
Re: Just where has this language gone wrong?
On Thursday, 19 July 2012 at 14:51:59 UTC, Timon Gehr wrote:
On another note, (copied from wikipedia)
foreach(item; set) {
// do something to item
}
what's with the lax syntax being allowed?
s/lax/to the point/
Shouldn't it be at least specified auto item?
Why on earth would that be the case?
I'm sorry I don't mean to be a criticizer, but it seems to me
that D is
trying to be a dynamic-like compiled language way too hard.
It's just syntax. Eliminating syntax noise is fine. Code should
look
like what it does.
Additionally, allowing to omit auto is actually consistent with
the rest of the language, which also allows you to not explicitly
write it if the code doesn't become ambiguous (for example, you
don't need to do immutable auto).
David
Object Pool
Does something to manage object pooling exists (thread safe)? Something like: auto pool = new Pool!MyObj; auto obj = pool.get; ... ... ... pool.release(obj); // or maybe obj.release; In a thread-safe way.
Re: Octal Literals
On Thursday, 19 July 2012 at 14:13:06 UTC, Dave X. wrote: How was the reception of the idea of binary literals as opposed to octal (I think it's an awesome feature, I think D, OCaml and Java 7 are the only ones that have it)? How long did it take to decide to implement it? If they were introduced today, I guess they might well be implemented as a template too, similar to octal. David
Re: Just where has this language gone wrong?
On 07/19/2012 08:03 AM, Petr Janda wrote:
It's just syntax. Eliminating syntax noise is fine. Code should look
like what it does.
Not if eliminating noise equals to making things harder to understand.
When you say (int x) { return x; } it's clear about what it is, a
_function_ without name.
Others beat me to it but the anonymous function can be written more
completely as
function string(int x) { return x.to!string(); }
(Or 'delegate' depending on the situation.)
Allow me to add a take(..., 2) to the entire expression, which is to me
the strongest reason why UFCS can be great:
writeln(take(map!(function string(int x) { return x.to!string();
})(uniq(sort([5, 3, 5, 6, 8]))), 2));
The problem is, the 2 is related to take() but they are too far apart
above. UFCS puts them together:
a_long_expression.take(2)
I don't like UFCS everywhere but it is very helpful in many cases.
Ali
Re: Making generalized Trie type in D
Am Mon, 04 Jun 2012 23:18:31 +0400 schrieb Dmitry Olshansky dmitry.o...@gmail.com: Compiler is like a nasty stepchild it will give up on generating good old jump tables given any reason it finds justifiable. (but it may use few small jump tables + binary search, could be fine... if not in a tight loop!) Looks, like you are back in control. From http://gcc.gnu.org/gcc-4.7/changes.html : ** General Optimizer Improvements ** Support for a new parameter --param case-values-threshold=n was added to allow users to control the cutoff between doing switch statements as a series of if statements and using a jump table. -- Marco
Re: Re-thinking D's modules
On Thu, Jul 19, 2012 at 01:34:31PM +0200, Jacob Carlborg wrote: On 2012-07-19 11:18, foobar wrote: I'd say that this is going in the wrong direction. I read an article a while ago that was really enlightening about this subject. The gist was that a module system is the wrong abstraction. Modules are an artifact of procedural thinking in that they are global. This hurts security, testability, etc. Here's the link: bracha.org/newspeak-modules.pdf Does it suggest a better approach? [...] I skimmed the paper briefly. Correct me if I'm misreading it, but the approach it proposes is based on identifying classes with modules, and requires that class names be dynamically bound; in particular, superclasses are dynamically bound. I don't think this will work in D's framework. T -- Дерево держится корнями, а человек - друзьями.
Re: Just where has this language gone wrong?
On Thu, 19 Jul 2012 14:44:20 + (UTC) trav...@phare.normalesup.org (Christophe Travert) wrote: Petr Janda , dans le message (digitalmars.D:172727), a écrit : On Thursday, 19 July 2012 at 14:31:53 UTC, trav...@phare.normalesup.org (Christophe Travert) wrote: q66 , dans le message (digitalmars.D:172716), a écrit : (so instead of calling a(b(c(d(e(f) you can just call a.b.c.d.e.f()) rather f.e.d.c.b.a, if you omit the empty parenthesis after each letter (but f). Ok, but the empty parenthesis is is important, it tells you about whether it's a an object or a function. It's another thing I hate about Ruby is that a parenthesis enforcement is weak. property (functions that behaves like fields) don't require empty parenthesis. This feature has been extended to all function, leading to the current situation. Some people would like this to disappear, and enforce strict property. That's already happening. It's just that for the moment you have to pass -property into DMD. Then it'll enforce Function calls always need parens, propertied always omit parens. Supposedly, this behavior will become the default at some point.
Re: Octal Literals
On Thu, 19 Jul 2012 16:13:05 +0200 Dave X. dxuhu...@gmail.com wrote: How was the reception of the idea of binary literals as opposed to octal (I think it's an awesome feature, I think D, OCaml and Java 7 are the only ones that have it)? How long did it take to decide to implement it? Binary literals have been there since way back around the beginning of D, just like hex literals, decimal literals and the now-dead old-style octal literals. Back when *everything* in D was a new feature. If octal literals had been like 0o123 or 0c123 instead of 0123 from the beginning, then I doubt we would have ever replaced them with octal!123 (since 0o123 or 0c123 aren't absolutely horrible like 0123 is).
Re: Just where has this language gone wrong?
On 2012-07-19 16:39, Petr Janda wrote: It's another thing I hate about Ruby is that a parenthesis enforcement is weak. I love that :) -- /Jacob Carlborg
Re: Just where has this language gone wrong?
Am 19.07.2012 22:43, schrieb Jacob Carlborg: On 2012-07-19 16:50, Alex Rønne Petersen wrote: I suspect that you have a C++ background. If this is not accurate, ignore the rest. But if it is accurate, my plea to you is: Learn other languages. C++ has next to no innovative language features (even C++11's take on lambdas is an abomination) and encourages defensive programming to the point where it's ridiculous (I mean, no default initialization of variables? In 2012?). In C++ it's even better (irony). It depends on what kind of variable is declared. I.e. a global variable, a local, instance or a class variable (static). Some of these are default initialized, some are not. I have no idea which are initialized and which are not. That is why any C or C++ project should have static analysis tools integrated in the continuous integration build system, plus compiling all warnings as errors. -- Paulo
Re: Just where has this language gone wrong?
On 2012-07-19 16:50, Alex Rønne Petersen wrote: I suspect that you have a C++ background. If this is not accurate, ignore the rest. But if it is accurate, my plea to you is: Learn other languages. C++ has next to no innovative language features (even C++11's take on lambdas is an abomination) and encourages defensive programming to the point where it's ridiculous (I mean, no default initialization of variables? In 2012?). In C++ it's even better (irony). It depends on what kind of variable is declared. I.e. a global variable, a local, instance or a class variable (static). Some of these are default initialized, some are not. I have no idea which are initialized and which are not. -- /Jacob Carlborg
Re: Just where has this language gone wrong?
On 2012-07-19 17:03, Petr Janda wrote:
It's just syntax. Eliminating syntax noise is fine. Code should look
like what it does.
Not if eliminating noise equals to making things harder to understand.
When you say (int x) { return x; } it's clear about what it is, a
_function_ without name.
It's equally clear when you see: =.
--
/Jacob Carlborg
Re: Just where has this language gone wrong?
What the _fuck_ guys? How did you get this many posts on what is essentially this looks weird and I can't be fucked reading the documentation?.
Re: Random sampling in D -- blog post
On Wednesday, 18 July 2012 at 14:55:18 UTC, Joseph Rushton Wakeling wrote: Hello all, My patches to RandomSample were accepted earlier this month (thanks to both Jonathan and Andrei:-) so I thought I'd write a short blog post (which turned into a very long blog post...) about random sampling, the algorithms concerned, and its implementation in D. http://braingam.es/2012/07/sampling-d/ If anyone's interested I may write up something more extended on the algorithms (if I can find a decent maths-notation solution for WordPress...) and on the D framework for random sampling (it could be fun to put up some creative examples of how to use it with different kinds of input). Best wishes, -- Joe Algorithm D in D. :D
Just where has this thread gone wrong? (n/t)
On 07/19/12 23:03, Bernard Helyer wrote: What the _fuck_ guys? How did you get this many posts on what is essentially this looks weird and I can't be fucked reading the documentation?. In other words, see subject.
Re: Random sampling in D -- blog post
On 7/18/12 7:55 AM, Joseph Rushton Wakeling wrote: Hello all, My patches to RandomSample were accepted earlier this month (thanks to both Jonathan and Andrei:-) so I thought I'd write a short blog post (which turned into a very long blog post...) about random sampling, the algorithms concerned, and its implementation in D. http://braingam.es/2012/07/sampling-d/ You should know Chrome displays quite a weird stub while loading that page over a slow connection. Anyway, vote up! http://www.reddit.com/r/programming/comments/wu7tx/random_sampling_in_the_d_programming_language/ If anyone's interested I may write up something more extended on the algorithms (if I can find a decent maths-notation solution for WordPress...) and on the D framework for random sampling (it could be fun to put up some creative examples of how to use it with different kinds of input). That would be awesome, and we'd put it on the website. Andrei
#d_lang ---- #dlang on Twitter?
Whaddaya think? Andrei
Re: #d_lang ---- #dlang on Twitter?
On Thursday, 19 July 2012 at 21:35:19 UTC, Andrei Alexandrescu wrote: Whaddaya think? Andrei #dlang is what people have been using on G+. You'll have to convince the Japanese guys to switch. It's mostly them (Kenji, SHOO, Mr. Fiber) and Bernard using #d_lang on Twitter. I prefer #dlang myself.
Re: Random sampling in D -- blog post
Zim desktop 'wiki.' Sounds rather stupid but it is very nice for informal style. It uses Markdown by default and comes with inline support for 'naked' LaTeX. It outputs to HTML, and doesn't look half bad for a five-minute learning curve. On Wed, 18 Jul 2012 09:55:06 -0500, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: Hello all, My patches to RandomSample were accepted earlier this month (thanks to both Jonathan and Andrei:-) so I thought I'd write a short blog post (which turned into a very long blog post...) about random sampling, the algorithms concerned, and its implementation in D. http://braingam.es/2012/07/sampling-d/ If anyone's interested I may write up something more extended on the algorithms (if I can find a decent maths-notation solution for WordPress...) and on the D framework for random sampling (it could be fun to put up some creative examples of how to use it with different kinds of input). Best wishes, -- Joe -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Just where has this language gone wrong?
On Thu, 19 Jul 2012 22:45:10 +0200 Paulo Pinto pj...@progtools.org wrote: Am 19.07.2012 22:43, schrieb Jacob Carlborg: On 2012-07-19 16:50, Alex Rønne Petersen wrote: I suspect that you have a C++ background. If this is not accurate, ignore the rest. But if it is accurate, my plea to you is: Learn other languages. C++ has next to no innovative language features (even C++11's take on lambdas is an abomination) and encourages defensive programming to the point where it's ridiculous (I mean, no default initialization of variables? In 2012?). In C++ it's even better (irony). It depends on what kind of variable is declared. I.e. a global variable, a local, instance or a class variable (static). Some of these are default initialized, some are not. I have no idea which are initialized and which are not. That is why any C or C++ project should have static analysis tools integrated in the continuous integration build system, plus compiling all warnings as errors. No, this is why any C/C++ project should be replaced by D ;) I'm knee-deep in a C++ project right now, and the language is such a pedantic, anachronistic turd. C++'s *only* saving graces are: - It's a systems language (ie, native compiled with low-level access). - It isn't PHP, JS, a JS-derivitive (ex, ActionScript), or Son-Of-Flash (aka Corona). - D isn't mature on all platforms yet.
Re: Just where has this language gone wrong?
I suspect that you have a C++ background. If this is not accurate, ignore the rest. But if it is accurate, my plea to you is: Learn other languages. C++ has next to no innovative language features (even C++11's take on lambdas is an abomination) and encourages defensive programming to the point where it's ridiculous (I mean, no default initialization of variables? In 2012?). Actually, C# has no default initialization* of local variables, and I love it. Instead, it is a compile-time error to read a variable if the compiler cannot guarantee that you have initialized it. IMO this is much better than D's let's initialize doubles to NaN so that something fishy will happen at runtime if you forget to initialize it :) * technically the compiler asks the runtime to bitwise 0-fill everything, but that's just an implementation detail required for the .NET verifier, and the optimizer can ignore the request to preinitialize.
Re: #d_lang ---- #dlang on Twitter?
On Thursday, 19 July 2012 at 21:35:19 UTC, Andrei Alexandrescu wrote: Whaddaya think? I've been using #d_lang so far, but now that dlang.org exists, #dlang certainly seems like the better choice. David
Re: #d_lang ---- #dlang on Twitter?
On 7/19/12 3:42 PM, David Nadlinger wrote: On Thursday, 19 July 2012 at 21:35:19 UTC, Andrei Alexandrescu wrote: Whaddaya think? I've been using #d_lang so far, but now that dlang.org exists, #dlang certainly seems like the better choice. David Yah, that's the new thing motivating the change. Andrei
Re: Just where has this language gone wrong?
On Fri, 20 Jul 2012 00:32:03 +0200 David Piepgrass qwertie...@gmail.com wrote: I suspect that you have a C++ background. If this is not accurate, ignore the rest. But if it is accurate, my plea to you is: Learn other languages. C++ has next to no innovative language features (even C++11's take on lambdas is an abomination) and encourages defensive programming to the point where it's ridiculous (I mean, no default initialization of variables? In 2012?). Actually, C# has no default initialization* of local variables, and I love it. Instead, it is a compile-time error to read a variable if the compiler cannot guarantee that you have initialized it. IMO this is much better than D's let's initialize doubles to NaN so that something fishy will happen at runtime if you forget to initialize it :) * technically the compiler asks the runtime to bitwise 0-fill everything, but that's just an implementation detail required for the .NET verifier, and the optimizer can ignore the request to preinitialize. I've always wished D worked that way, too.
Re: #d_lang ---- #dlang on Twitter?
On Thursday, 19 July 2012 at 21:35:19 UTC, Andrei Alexandrescu wrote: Whaddaya think? Andrei #dlang is more obvious and what people would likely use if they were guessing / didn't carefully read, especially now with dlang.org.
Re: Just where has this language gone wrong?
On 20/07/2012 00:49, Nick Sabalausky wrote: On Fri, 20 Jul 2012 00:32:03 +0200 David Piepgrass qwertie...@gmail.com wrote: I suspect that you have a C++ background. If this is not accurate, ignore the rest. But if it is accurate, my plea to you is: Learn other languages. C++ has next to no innovative language features (even C++11's take on lambdas is an abomination) and encourages defensive programming to the point where it's ridiculous (I mean, no default initialization of variables? In 2012?). Actually, C# has no default initialization* of local variables, and I love it. Instead, it is a compile-time error to read a variable if the compiler cannot guarantee that you have initialized it. IMO this is much better than D's let's initialize doubles to NaN so that something fishy will happen at runtime if you forget to initialize it :) * technically the compiler asks the runtime to bitwise 0-fill everything, but that's just an implementation detail required for the .NET verifier, and the optimizer can ignore the request to preinitialize. I've always wished D worked that way, too. vote++
Re: Just where has this language gone wrong?
On Thursday, 19 July 2012 at 22:32:04 UTC, David Piepgrass wrote: I suspect that you have a C++ background. If this is not accurate, ignore the rest. But if it is accurate, my plea to you is: Learn other languages. C++ has next to no innovative language features (even C++11's take on lambdas is an abomination) and encourages defensive programming to the point where it's ridiculous (I mean, no default initialization of variables? In 2012?). Actually, C# has no default initialization* of local variables, and I love it. Instead, it is a compile-time error to read a variable if the compiler cannot guarantee that you have initialized it. IMO this is much better than D's let's initialize doubles to NaN so that something fishy will happen at runtime if you forget to initialize it :) * technically the compiler asks the runtime to bitwise 0-fill everything, but that's just an implementation detail required for the .NET verifier, and the optimizer can ignore the request to preinitialize. It would be great if D did do this, surely it would not be all that difficult! and wouldn't it also help in finding unused variables?
Re: Just where has this language gone wrong?
On 07/19/2012 10:21 AM, Petr Janda wrote: ... I think the other points have been adequately covered. ... auto r = [5, 3, 5, 6, 8].sort.uniq.map!(x = x.to!string); ... I'm sorry I don't mean to be a criticizer, but it seems to me that D is trying to be a dynamic-like compiled language way too hard. Everything in that snippet is statically (and probably strongly too?) typed at compile-time. What's going on is a lot of type inference and syntax sugar that allows for very terse code. You'll still get immediate compiler errors if you screw up the types and you try to treat r like it isn't a range of strings. There won't be any bugs introduced in your programs due to breaches of type safety. This is the beauty of it: the code is terse, does what it says it does, potentially very optimized, and also heavily verified at compile-time. The anonymous function is even passed at compile-time for easy inlining (not sure how aggressively dmd handles that right now though). It's hard to get that combo of (development speed)|(correctness)|(execution speed) in other places, in my not-so-humble opinion. ;)
Re: Add CTFE execute function
On Tuesday, 29 May 2012 at 09:46:54 UTC, Don Clugston wrote: On 28/05/12 03:40, Chang Long wrote: On Saturday, 26 May 2012 at 15:56:38 UTC, Chang Long wrote: CTFE execute will be very useful on web develop, for example It is very hard to create a CTFE version template engine with rich feature. But we can use execute call to transe template file to d code string, then mixed it to application. The vibed project is very cool and I want to add my Jade template to this, but I can't find other way to do it. You can do a lot with import(filename); Maybe we also need a compiler option to enable this CTFE io operate because security. Let me make myself more clear, what I suggestion is something like this: mixin( std.process.execute(/usr/bin/template_engine template_file_path.htm) ); When translate the template code to D code, need a lot D type arguments information. And one Web application may need very many page, and the type may change frequently. If I am not doing it on the CTFE will geometric increase workload. If D want to be participants in the web field, I think that this feature sooner or later will be needed.
Re: #d_lang ---- #dlang on Twitter?
On Thursday, 19 July 2012 at 21:35:19 UTC, Andrei Alexandrescu wrote: Whaddaya think? Andrei No, problem. Our official website is dlang.org :) If hashtag changed to #dlang, I announce this change to other Japanese programmers.
Re: #d_lang ---- #dlang on Twitter?
On Thursday, 19 July 2012 at 21:39:24 UTC, Brad Anderson wrote: On Thursday, 19 July 2012 at 21:35:19 UTC, Andrei Alexandrescu wrote: Whaddaya think? Andrei #dlang is what people have been using on G+. You'll have to convince the Japanese guys to switch. It's mostly them (Kenji, SHOO, Mr. Fiber) and Bernard using #d_lang on Twitter. I prefer #dlang myself. My ears are burning. I thought it was 'ze standard'. I'll switch to #dlang in the future.
Re: Re-thinking D's modules
On Wednesday, 18 July 2012 at 11:21:08 UTC, Paulo Pinto wrote: * dynamically loadable plugins/extensions From the security point of view loadable plugins are not good. Better make use of IPC to communicate between plugins. Since we kind of have a never recover from error-policy that's the only way to have plugins in D too, if you want to have plugins crash your main application.
Re: #d_lang ---- #dlang on Twitter?
On 7/19/12 7:33 PM, Masahiro Nakagawa wrote: On Thursday, 19 July 2012 at 21:35:19 UTC, Andrei Alexandrescu wrote: Whaddaya think? Andrei No, problem. Our official website is dlang.org :) If hashtag changed to #dlang, I announce this change to other Japanese programmers. Let's make it so. Thanks, Masahiro! Andrei
Preview LLVM Deimos bindings
Hi, I've written some Deimos interface for LLVM. https://github.com/jkm/deimos-llvm/commits/master I'd like to get some feedback on those. Firstly to finish these and secondly to finish some guidelines that I'd like to propose to be published on dlang.org. Jens
Re: Getting a range over a const Container
On 07/19/12 06:39, Francisco Soulignac wrote:
it's been a while since this question, and I don't know how to solve
it either. The following code passes all the test using the last
version of dmd (2.059).
import std.container, std.algorithm;
//non const case
void assertequal(T)(SList!(T) l, int[] r) {
assert(equal(l[], r));
}
//const case
void const_assertequal(T)(const SList!(T) l, int[] r) {
assert(equal(l[], r));
}
unittest{
SList!(int) l;
l.insertFront(2);
l.insertFront(1);
assertequal (l, [1,2]);
assert(!__traits(compiles, const_assertequal(l, [1,2])));
}
The conflict with the last assertion is that opSplice can't be
applied to const. So, I looked at the container module, and made a
minimal example of a list myself (emulating SList).
struct List {
struct Node {
Node* next;
int val;
}
private Node* first;
struct Range {
//sorry about actual, it should have been current
private Node* actual;
this(Node* first) {actual = first;}
@property front() {return actual.val;}
@property empty() const {return !actual;}
void popFront() {assert(!empty); actual = actual.next;}
Range save() {return this;}
}
unittest{static assert(isForwardRange!(Range));}
void add(int v) {
Node * next = first;
first = new Node;
first.val = v;
first.next = next;
}
Range opSlice() {
return Range(first);
}
}
void assertequal(L : List)(L l, int[] r) {
assert(equal(l[], r));
}
void assertequal_const(L : List)(L l, int[] r) {
assert(equal(l[], r));
}
unittest{
List l;
l.add(2);
l.add(1);
assert(equal(l[], [1,2]));
assertequal (l, [1,2]);
assert(!__traits(compiles, const_assertequal(l, [1,2])));
}
As far as I know, the problem comes with the transitivity of const.
In assertequal_const, l.first has type const(Node*), thus it can't
be converted to Node* in Range's constructor. I can't manage to
find a workaround here, because l.first will always have type
const(Node*), but for traversing the list I require to copy l.first
into some node, say actual, whose type is Node* so that I can move
it doing actual = actual.next. I would be happy to do
actual = cast(Node*)(l.first)
actual = actual.next;
but that code is suppose to be undefined, isn't it?
(http://dlang.org/const3.html : Removing Immutable With A Cast).
So, my question is how can I (correctly) traverse a const SList,
const DList, etc?
import std.algorithm, std.range;
struct List {
static struct Node {
Node* next;
int val;
}
private Node* first;
static struct Range(E) {
private E* current;
this(FE:const E)(FE* first) {current = first;}
@property front() {return current.val;}
@property empty() const {return !current;}
void popFront() {assert(!empty); current = current.next;}
@property Range save() {return this;}
}
static assert(isForwardRange!(Range!Node));
void add(int v) {
Node * next = first;
first = new Node;
first.val = v;
first.next = next;
}
Range!Node opSlice() { return Range!Node(first); }
Range!(const Node) opSlice() const { return Range!(const Node)(first); }
}
void assertequal(L : List)(L l, int[] r) {
assert(equal(l[], r));
}
void assertequal_const(L : List)(const L l, int[] r) {
assert(equal(l[], r));
}
void main() {
List l;
l.add(2);
l.add(1);
assert(equal(l[], [1,2]));
assertequal (l, [1,2]);
assertequal_const(l, [1,2]);
}
artur
Re: Getting a range over a const Container
On 07/19/2012 06:44 AM, Jonathan M Davis wrote: On Thursday, July 19, 2012 04:39:26 Francisco Soulignac wrote: So, my question is how can I (correctly) traverse a const SList, const DList, etc? Right now? I'm pretty sure that that's impossible. Hopefully that will change, but getting const and ranges to work together can be rather difficult, and std.container needs more work in that regard. Well it doesn't work yet. But in principle it could since we can always copy a const pointer to a non-const one to const data: Node* actual; // but 'this' is const and hence the type is const(Node*) const(Node)* i_will_traverse = actual; Best regards, Matthias
Re: Magic type return
Or template inference based on return type like
T hello(T)()
{
static if (is(T ==))
}
string v = hello();
Il giorno mer, 18/07/2012 alle 17.38 +0100, Regan Heath ha scritto:
On Tue, 17 Jul 2012 15:23:05 +0100, bearophile bearophileh...@lycos.com
wrote:
Andrea Fontana:
class Known
{
void* data; // external data by c api
int type; // 0 for int, 1 for string, etc. ..
}
How can I implement a method like this?
Known known; // -- suppose known.type == 1;
string s = known.value(); // -- automatic
To do this Known.value() needs to return different types according to
the run-time value of Known.type. This is not possible in a statically
typed language... You need to find other solutions.
Unless we had overload based on return type, right?
e.g.
class Known
{
string value()
{
if (type != 1)
throw..;
return cast(string)data;
}
int value()
{
if (type != 0)
throw ..;
return cast(int)data;
}
}
The compiler could produce the correct code/call for the line
string s = known.value();
then, but it's not a feature we're likely to see any time soon.
R
WinAPI LowLevel Keyboard Hooks
Hello everyone, I had this great idea of writing a Program that intercepts all keyboard presses and modifies them in certain cases. I want to use it as some kind of global makro program to run in the background and for example allow me to easily post unicode smileys. This is where the probelms begin. If I understood the WinAPI doc correctly, I need to install a LowLevel Keyboard Hook using SetWindowsHookEx(). Unfortunately there are two versions of this function, SetWindowsHookExW and SetWindowsHookExA. What's the difference? The function to get called is passed as a parameter, but apparently it needs to be located in a .dll if using global hooks. So I need to first load my .dll file using LoadLibraryA( ) or LoadLibraryW( ), locate my function using GetProcAddress( ) and then set the hook using SetWindowsHookExW (or *-A)). Unfortunately for me, even the LoadLibrary function fails, returning Module could not be found. Now I'm 99% sure my .dll is crap because this is the first time I ever wrote one, but it DOES have a DllMain(), initializes the D Runtime and also has the other function I want to install the hook for. I'm hoping some bright minds here could help me out because google didn't, and I'm out of my depth. If you want me to, I'll post the source code, but I didn't want this post to get too big, which still did, but anyway.
~= call copy ctor?
I have a 2 questions.
I have this code:
[code]
import std.stdio;
struct Test {
public:
this(int i = 0) {
writeln(Test CTor.);
}
this(this) {
writeln(Test Copy CTor);
}
~this() {
writeln(Test DTor);
}
}
Test[] _arr;
void copy_save(Test t) {
_arr ~= t;
}
void by_ref_save(ref Test t) {
_arr ~= t;
}
[/code]
Why get i with
[code]
void main() {
Test t = 42;
by_ref_save(t);
}
[/code]
this output:
Test CTor.
Test Copy CTor
Test DTor
?
Why t is copied?
And the same if i have this:
[code]
void main() {
Test t = 42;
copy_save(t);
}
[/code]
t is already a clone. Why it is copied again?
Thanks in advance. :)
Re: ~= call copy ctor?
On 07/19/2012 02:27 PM, Namespace wrote:
I have a 2 questions.
I have this code:
[code]
import std.stdio;
struct Test {
public:
this(int i = 0) {
writeln(Test CTor.);
}
this(this) {
writeln(Test Copy CTor);
}
~this() {
writeln(Test DTor);
}
}
Test[] _arr;
void copy_save(Test t) {
_arr ~= t;
}
void by_ref_save(ref Test t) {
_arr ~= t;
}
[/code]
Why get i with
[code]
void main() {
Test t = 42;
by_ref_save(t);
}
[/code]
this output:
Test CTor.
Test Copy CTor
Test DTor
As you mentioned in the subject the copy constructor is not called while
the struct is passed by reference but on array concatenation.
But this must occur since the array has its memory region and the
original variable t in main() also has. Since they are different, at
some point the struct must be copied from t in main() into the array.
The ref only ensures that it is passed via reference (a pointer to the
memory of t in main()) to the function by_ref_save().
And the same if i have this:
[code]
void main() {
Test t = 42;
copy_save(t);
}
[/code]
t is already a clone. Why it is copied again?
Here it is once copied from t in main() into the local variable t in
copy_save() and then copied (as in your 1st example) into the array.
Imagine the copy_save routine is in a different module and only its
signature is exposed to main. When calling the function, the compiler
does not know what happens inside copy_save but it must put the variable
onto the stack at the position of the first parameter (well, in this
case it is probably put into a CPU register, but that doesn't matter here).
Then, when copy_save is invoked it only knows the local variable which
it then copies into the array memory (after enlarging the array).
It *may* be the when you enable compiler optimizations (-O -inline) that
copy_save gets inlined and hence the compiler can optimize one of the
copy calls away. But that I don't know for sure.
Best regards,
Matthias
Re: ~= call copy ctor?
Is there any way to avoid the implizit copy ctor by array concatenation? Or is the only way to use a pointer?
Re: ~= call copy ctor?
On 07/19/2012 03:00 PM, Namespace wrote: Is there any way to avoid the implizit copy ctor by array concatenation? Or is the only way to use a pointer? Yes, in some way you have to. If you want to not copy a lot of data (or avoid additional on-copy effort) you either have to you pointers explicitly (Test*[]) or implicitly. The latter works e.g. by making Test a class which means that the variable actually does store a pointer to the instance. Note that for struct pointers you should not escape them, i.e. have a variable local in a function, puts its address into some array and returning that array. Since the local variable is gone, the pointer is invalid as well. (Nothing happens if you do not access it). Best regards, Matthias
Re: ~= call copy ctor?
Ok, so if a put a struct into an array, it will copied into the
array. But then? How it is deleted?
For exmaple, i have this code:
[code]
import std.stdio;
struct Test {
public:
static uint _counter;
this(int i = 0) {
writeln(Test CTor.);
_counter++;
}
this(this) {
writeln(Test Copy CTor);
_counter++;
}
~this() {
writeln(Test DTor);
if (_counter 0) {
_counter--;
}
}
}
void main() {
{
Test[] _arr;
void copy_save(Test t) {
_arr ~= t;
}
void by_ref_save(ref Test t) {
_arr ~= t;
}
Test t = 42;
//copy_save(t);
by_ref_save(t);
writeln(end scope);
}
writefln(Counter: %d, Test._counter);
}
[/code]
_counter is still 1 but the scope is released. How is that
possible?
Even with _arr.clear(); at the end of the scope, _counter is
still 1.
I see one CTor and one Copy CTor but only one DTor.
Re: ~= call copy ctor?
Use std.algorithm.move if you want to avoid the copy ctor call.
Re: WinAPI LowLevel Keyboard Hooks
Unfortunately there are two versions of this function, SetWindowsHookExW and SetWindowsHookExA. What's the difference? The W-Function is the Unicode version and the A is the ANSI version. Showing the code of your DLL might help.
Re: ~= call copy ctor?
On Thursday, 19 July 2012 at 14:31:02 UTC, Timon Gehr wrote: Use std.algorithm.move if you want to avoid the copy ctor call. With move I see the lost DTor call, but not without. Ist that a bug? o.O
Re: WinAPI LowLevel Keyboard Hooks
But what are the differences of loading the Unicode version vs.
the ANSI version? I called the Unicode one because I figured that
would be the sensible choice, since Unicode is the default for D
(if I remember correctly). I have no clue what the actual effects
of calling the wrong version would be.
Anyway, here's the of my .dll:
-- Code begin --
import std.c.windows.windows;
import core.sys.windows.dll;
import core.runtime;
extern (C) void gc_init();
extern (C) void gc_term();
extern (C) void _minit();
extern (C) void _moduleCtor();
extern (C) void _moduleDtor();
extern (Windows) struct KBDLLHOOKSTRUCT {
DWORD vkCode;
DWORD scanCode;
DWORD flags;
DWORD time;
ULONG_PTR dwExtraInfo;
};
extern (Windows) LRESULT CallNextHookEx(
int function() hhk,
int nCode,
WPARAM wParam,
LPARAM lParam
);
__gshared HINSTANCE g_hInst;
extern (Windows) BOOL DllMain(HINSTANCE hInstance, ULONG
ulReason, LPVOID pvReserved) {
return true;
switch (ulReason) {
case DLL_PROCESS_ATTACH:
g_hInst = hInstance;
Runtime.initialize;
//dll_process_attach( hInstance, true );
break;
case DLL_PROCESS_DETACH:
dll_process_detach( hInstance, true );
break;
case DLL_THREAD_ATTACH:
dll_thread_attach( true, true );
break;
case DLL_THREAD_DETACH:
dll_thread_detach( true, true );
break;
default:
return true;
}
return true;
}
extern (Windows) LRESULT LowLevelKeyboardProc(int code, WPARAM
wParam, LPARAM lParam)
{
KBDLLHOOKSTRUCT* details = cast(KBDLLHOOKSTRUCT*) lParam;
MessageBoxA(null, cast(char *)WHOA, Error,
MB_OK | MB_ICONEXCLAMATION);
if(code == 0 wParam == WM_KEYDOWN)
{
if(details.vkCode == 0x41)
{
return 1;
}
}
return CallNextHookEx(null, code, wParam, lParam);
}
-- Code End --
Lots of copypaste was used. I injected some senseless code to
try and check if a specific function ever gets called, though I
now realise the DllLoad itself is what fails. Haven't cleaned it
back up yet, though.
The .def file contains the following: (including newlines)
-- .DEF BEGIN --
LIBRARY keydll.dll
EXETYPE NT
SUBSYSTEM WINDOWS
CODE PRELOAD
DATA PRELOAD
-- .DEF END --
I compiled the dll using:
dmd -ofkeydll.dll -L/IMPLIB keydll.d keydll.def
No linker/compiler errors.
Re: ~= call copy ctor?
On Thursday, 19 July 2012 at 15:36:01 UTC, Namespace wrote: _counter is still 1 but the scope is released. How is that possible? Even with _arr.clear(); at the end of the scope, _counter is still 1. I see one CTor and one Copy CTor but only one DTor. _arr is actually a dynamic array, which allocates from the garbage collector. When _arr goes out of scope, you are only destroying the Slice that is looking at the data, but not the data itself. You have to wait until the Garbage Collector runs and collects. Either that, or use a stack allocated static array, but I wouldn't recommend it. Furthermore, D does not actually guarantee that all your objects are destroyed (eg. destructors called) when the program ends. D's approach is The program has ended, ergo anything left in memory is moot. Just let the OS clear it. If you really need RAII, you can use RefCounted objects, such as RefCounted! directly, or by using Array.
Re: WinAPI LowLevel Keyboard Hooks
On Thursday, 19 July 2012 at 15:49:48 UTC, DLimited wrote:
But what are the differences of loading the Unicode version vs.
the ANSI version? I called the Unicode one because I figured
that would be the sensible choice, since Unicode is the default
for D (if I remember correctly). I have no clue what the actual
effects of calling the wrong version would be.
Anyway, here's the of my .dll:
-- Code begin --
import std.c.windows.windows;
import core.sys.windows.dll;
import core.runtime;
extern (C) void gc_init();
extern (C) void gc_term();
extern (C) void _minit();
extern (C) void _moduleCtor();
extern (C) void _moduleDtor();
extern (Windows) struct KBDLLHOOKSTRUCT {
DWORD vkCode;
DWORD scanCode;
DWORD flags;
DWORD time;
ULONG_PTR dwExtraInfo;
};
extern (Windows) LRESULT CallNextHookEx(
int function() hhk,
int nCode,
WPARAM wParam,
LPARAM lParam
);
__gshared HINSTANCE g_hInst;
extern (Windows) BOOL DllMain(HINSTANCE hInstance, ULONG
ulReason, LPVOID pvReserved) {
return true;
switch (ulReason) {
case DLL_PROCESS_ATTACH:
g_hInst = hInstance;
Runtime.initialize;
//dll_process_attach( hInstance, true );
break;
case DLL_PROCESS_DETACH:
dll_process_detach( hInstance, true );
break;
case DLL_THREAD_ATTACH:
dll_thread_attach( true, true );
break;
case DLL_THREAD_DETACH:
dll_thread_detach( true, true );
break;
default:
return true;
}
return true;
}
extern (Windows) LRESULT LowLevelKeyboardProc(int code, WPARAM
wParam, LPARAM lParam)
{
KBDLLHOOKSTRUCT* details = cast(KBDLLHOOKSTRUCT*) lParam;
MessageBoxA(null, cast(char *)WHOA, Error,
MB_OK | MB_ICONEXCLAMATION);
if(code == 0 wParam == WM_KEYDOWN)
{
if(details.vkCode == 0x41)
{
return 1;
}
}
return CallNextHookEx(null, code, wParam, lParam);
}
-- Code End --
Lots of copypaste was used. I injected some senseless code to
try and check if a specific function ever gets called, though I
now realise the DllLoad itself is what fails. Haven't cleaned
it back up yet, though.
The .def file contains the following: (including newlines)
-- .DEF BEGIN --
LIBRARY keydll.dll
EXETYPE NT
SUBSYSTEM WINDOWS
CODE PRELOAD
DATA PRELOAD
-- .DEF END --
I compiled the dll using:
dmd -ofkeydll.dll -L/IMPLIB keydll.d keydll.def
No linker/compiler errors.
I guess you have to 'export' the function:
extern (Windows) export LRESULT LowLevelKeyboardProc(int code,
WPARAM
wParam, LPARAM lParam)
and include
EXPORTS
LowLevelKeyboardProc
in the .DEF file
Re: WinAPI LowLevel Keyboard Hooks
I guess you have to 'export' the function: extern (Windows) export LRESULT LowLevelKeyboardProc(int code, WPARAM wParam, LPARAM lParam) and include EXPORTS LowLevelKeyboardProc in the .DEF file Thanks, I changed that. Also, I changed LoadLibraryW( ) to LoadLibraryA( ) in the main program and now it works (kinda). I feel stupid now, although I still don't get why it wouldn't work with LoadLibraryW.
Re: WinAPI LowLevel Keyboard Hooks
On Thursday, 19 July 2012 at 16:38:19 UTC, DLimited wrote:
I guess you have to 'export' the function:
extern (Windows) export LRESULT LowLevelKeyboardProc(int code,
WPARAM
wParam, LPARAM lParam)
and include
EXPORTS
LowLevelKeyboardProc
in the .DEF file
Thanks, I changed that. Also, I changed LoadLibraryW( ) to
LoadLibraryA( ) in the main program and now it works (kinda). I
feel stupid now, although I still don't get why it wouldn't work
with LoadLibraryW.
Acutally, that was only the half-truth. The .dll seems to get
loaded correctly ( GetLastError returns 0), but my
keyboard-presses aren't captured at all.
My system seems to freeze up for ~5sec, after which everything
resumes. Any keyboard input seems to get buffered and is
processed by my terminal after my program closes.
Also I'm unsure about types because the often-used HHOOK is not
defined with my imports, so I'm left guessing what it is. I used
the type int function() instead (my best guess).
Here's the code:
--- CODE BEGIN -
import std.c.windows.windows;
import std.stdio;
import core.thread;
extern (C) void gc_init();
extern (C) void gc_term();
extern (C) void _minit();
extern (C) void _moduleCtor();
extern (C) void _moduleDtor();
extern (C) void _moduleUnitTests();
extern (Windows) int function() SetWindowsHookExA( int idHook,
HOOKPROC lpfn,
HINSTANCE hMod,
DWORD dwThreadId );
extern (Windows) struct KBDLLHOOKSTRUCT {
DWORD vkCode;
DWORD scanCode;
DWORD flags;
DWORD time;
ULONG_PTR dwExtraInfo;
};
extern (Windows) LRESULT CallNextHookEx(
int function() hhk,
int nCode,
WPARAM wParam,
LPARAM lParam
);
extern (Windows) bool UnhookWindowsHookEx(
int function() hhk
);
extern (Windows) HMODULE LoadLibraryA(
LPCTSTR lpFileName
);
extern (Windows)
int WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow)
{
int result;
gc_init(); // initialize garbage collector
_minit(); // initialize module constructor table
try
{
_moduleCtor(); // call module constructors
//_moduleUnitTests(); // run unit tests (optional)
result = myWinMain(hInstance, hPrevInstance, lpCmdLine,
nCmdShow);
_moduleDtor(); // call module destructors
}
catch (Exception o) // catch any uncaught exceptions
{
MessageBoxA(null, cast(char *)o.toString(), Error,
MB_OK | MB_ICONEXCLAMATION);
result = 0; // failed
}
gc_term(); // run finalizers; terminate garbage collector
return result;
}
int myWinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow)
{
HOOKPROC hkprcSysMsg;
HINSTANCE hinstDLL;
extern (Windows) int function() hhookSysMsg;
hinstDLL =
LoadLibraryA(cast(LPCTSTR)correct_absolute_path\\keydll.dll);
writeln(GetLastError()); //returns 0
hkprcSysMsg = cast(HOOKPROC)GetProcAddress(hinstDLL,
LowLevelKeyboardProc);
writeln(GetLastError()); //return 0
hhookSysMsg = SetWindowsHookExA(
13,
hkprcSysMsg,
hinstDLL,
0);
writeln(GetLastError()); // returns 0 aswell
Thread.sleep( dur!(seconds)(10) );
UnhookWindowsHookEx( hhookSysMsg );
return 0;
}
Re: WinAPI LowLevel Keyboard Hooks
You don't see the WHOA message? Try this alias HANDLE HHOOK;
Re: WinAPI LowLevel Keyboard Hooks
On Thursday, 19 July 2012 at 17:35:29 UTC, dnewbie wrote: You don't see the WHOA message? Try this alias HANDLE HHOOK; No, I don't get any message after key-presses. I changed int function() to HANDLE, sadly it still doesn't work.
Re: WinAPI LowLevel Keyboard Hooks
On Thursday, 19 July 2012 at 17:48:06 UTC, DLimited wrote: On Thursday, 19 July 2012 at 17:35:29 UTC, dnewbie wrote: You don't see the WHOA message? Try this alias HANDLE HHOOK; No, I don't get any message after key-presses. I changed int function() to HANDLE, sadly it still doesn't work. For some reason, it doesn't work with 'Thread.sleep' This works: http://dpaste.dzfl.pl/1e6e5960
Re: WinAPI LowLevel Keyboard Hooks
On Thursday, 19 July 2012 at 18:40:15 UTC, dnewbie wrote: On Thursday, 19 July 2012 at 17:48:06 UTC, DLimited wrote: On Thursday, 19 July 2012 at 17:35:29 UTC, dnewbie wrote: You don't see the WHOA message? Try this alias HANDLE HHOOK; No, I don't get any message after key-presses. I changed int function() to HANDLE, sadly it still doesn't work. For some reason, it doesn't work with 'Thread.sleep' This works: http://dpaste.dzfl.pl/1e6e5960 It doesn't work for me. I can 1 Message Box from the Code in MyWinMain, but none for the Keystrokes. I registered a hook for Keyboard input, and that code is supposed to produce a message box aswell. The function for that is called LowLevelKeyboardProc and located in above-mentioned .dll file. The registering of the hook seems to pass, but the function never actually gets called.
