Re: HibernateD and DDBC - ORM and DB abstraction layer for D
On Wednesday, 17 April 2013 at 13:46:30 UTC, kdmult wrote: P.S: I've registered ddbc and hibernated in DUB repository. I have tried to generate a visuald project which depends on both. There is a couple of issues. 1. Since you use prefix hibernated (for example, hibernated.core) there should be subfolder hibernated under source. And the source code should go there. 2. In dependencies I was forced to use version ~master instead of a certain version. Is there a simple example of using hibernated with sqlite driver? I've fixed directory structure. You need to use SQLite config for both DDBC and HibernateD (USE_SQLITE version code defined). Look at unittests for sample usage (hibernated.tests module). You need sqlite .lib and .dll to build under windows.
Functional Programming in D on reddit
http://www.reddit.com/r/programming/comments/1clufn/functional_programming_with_d/ Andrei
Re: Attribute inference for auto functions?
On Thursday, 18 April 2013 at 05:59:20 UTC, kenji hara wrote:
It will break existing code.
int foo() {
typeof(return) bar() { return 1; }
return bar();
}
typeof(return) represents the return type of foo, that is int.
That is true :( Don't seem fixable.
Re: Attribute inference for auto functions?
On 4/17/2013 11:34 PM, deadalnix wrote:
On Thursday, 18 April 2013 at 05:59:20 UTC, kenji hara wrote:
It will break existing code.
int foo() {
typeof(return) bar() { return 1; }
return bar();
}
typeof(return) represents the return type of foo, that is int.
That is true :( Don't seem fixable.
It is fixable if it is special cased, but special cases stink.
Re: Attribute inference for auto functions?
On 04/18/2013 01:46 AM, Walter Bright wrote:
On 4/17/2013 3:20 PM, Timon Gehr wrote:
This is the same issue as defining a function with 'auto' in one place
and referring to it having a specific type/attribute in another. So I
think all the same arguments and reasoning discussed above apply
equally.
Why is this a valid form of reasoning? The signature of a function
that has its
return type inferred includes the function body.
Furthermore, it is not the same issue. It is the dual issue. The
distinction is
very relevant because pure and nothrow are designed in an asymmetric way,
They are the same
No. In one case you infer guarantees only. (those restrict what can be
done in the future without potentially breaking code, but that's it.)
In the other case you infer restrictions too, in an unsound way because
the inference does not take into consideration the subclasses.
- adding the attribute retains covariance.
I am sorry, but I do not understand your notion of covariance.
Covariance is a precise notion from category theory. (A mapping between
categories that conserves morphisms is called a covariant functor.)
given
inference. Attributes can force the specification in one direction
only (provide
more guarantees to callers), but not in the other one (require less from
subclasses).
Pure and nothrow provide more guarantees, hence covariance.
The concerns the latter can certainly not be dismissed by using the same
arguments and reasoning as for the former without any further
examination.
They're both the same issue of covariance.
class C{
final foo(){ ... } // - this signature is foo's signature only
auto bar(){ ... } // - this signature has to fit all overrides
}
In the first case, inference is mostly fine because you cannot unduly
restrict someone: The signature will actually match foo's implementation.
In the second case you cannot infer the attributes because you do not
know all subclasses. The signature will potentially not match all overrides.
Case in point, I just noticed the following regression on git head:
import std.stdio;
class C(T){
T foo(){ return 2; }
}
class D : C!int{
override int foo(){ writeln(super.foo()); return 3; } // error
}
Inference shouldn't be done for virtual functions.
http://d.puremagic.com/issues/show_bug.cgi?id=9952
Re: Attribute inference for auto functions?
On 4/17/2013 11:49 PM, Timon Gehr wrote:
I am sorry, but I do not understand your notion of covariance.
Overriding functions can add pure or nothrow and remain covariant.
In the second case you cannot infer the attributes because you do not know all
subclasses. The signature will potentially not match all overrides.
If you want a precise signature, don't use auto. It's the same case as
everywhere else.
Case in point, I just noticed the following regression on git head:
import std.stdio;
class C(T){
T foo(){ return 2; }
}
class D : C!int{
override int foo(){ writeln(super.foo()); return 3; } // error
}
Inference shouldn't be done for virtual functions.
http://d.puremagic.com/issues/show_bug.cgi?id=9952
This is not an auto issue.
Re: DConf 2013 official car/room sharing thread
On 17 April 2013 21:44, David Nadlinger s...@klickverbot.at wrote: On Wednesday, 17 April 2013 at 16:45:20 UTC, Iain Buclaw wrote: On 17 April 2013 17:18, Martin Nowak c...@dawg.eu wrote: On 04/11/2013 05:42 PM, Andrei Alexandrescu wrote: I'll stay at Aloft (http://goo.gl/CHmzw) and will drive a compact rental. Will gladly pick up people to and fro that hotel. Andrei That would be great, I'll also stay there from 30th April to 4th May. Cool, looks like we'll all have a great time at Aloft then. :o) Darn, if I had known this a few days earlier, I might have also booked there. I'll in a cheap Palo Alto hotel near the Caltrain station, and my plan so far was actually to just rent a bicycle (yes, crazy Europeans, I know)… David Incidentally, I only get around by bicycle (even moved 400 miles to a new home on one last year). =) -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Where should I put a `condp` like function?
On Sunday, 14 April 2013 at 23:52:37 UTC, Idan Arye wrote: Now, I've got it working(the example actually compiles and prints less then 5), and I want to make a pull request to put it in Phobos(because it's a useful function) but I don't really know where to put it. None of the existing modules seems fit, and I don't want to open a new module(std.monad?) for a single function. Nit-picky observation: there's nothing monadic about your predSwitch function, it wouldn't belong in a 'std.monad' module. Best, Graham
Re: Is there any plans to make working signals in D?
17.04.2013 15:26, Timon Gehr пишет: On 04/17/2013 12:35 PM, Denis Shelomovskij wrote: ... It will make code in Issue 9603 work. You have to argue why this is the correct way to fix it. Why would lifetime control necessarily be linked to implicit object field overhead? 0. I do like this approach, it looks straight and consistent IMO. 1. I see no other ways to fix the issue. 2. I see no important overhead in my proposal as wasting a few bytes is nothing in contrast with GC allocation process/memory overhead. 3. I think added functionality is very usable and even already required. Everyone is free to propose a better approach. By the way, almost every technical idea we know is incorrect and will be likely superceeded in the future with a better one as history shows. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Is there any plans to make working signals in D?
17.04.2013 19:47, deadalnix пишет: On Wednesday, 17 April 2013 at 10:35:08 UTC, Denis Shelomovskij wrote: Can you explain what is the problem ? Code in Issue 9603 doesn't work. That is not explaining what is the problem. This should contains at least : - Why it doesn't work. No ability to tell when a delegate will be destroyed (currently it isn't even destroyed when it should, see Issue 9602). http://d.puremagic.com/issues/show_bug.cgi?id=9602 - What is the fundamental problem. When a delegate is created information about it's outer scope is lost instead of being stored in it's ptr. - Why this fundamental problem is a language issue and not a lib one. Looks self-evident. - How does you proposition solve it. It stores the information about delegate's outer scope wasting (oh God, how many, especially in contrast to GC allocation) a few bytes. Right now, the only element you have been able to provide are : - signal accept delegate from object. - So we must make all delegate object. This is a very poor argumentation as the only reasonable answer to 1 without more input is go fix signal or raise a bug about signal. As everything I have written above is known, I still don't understand why you are telling about signal fixing as a main problem as it is just an example of problems that occurs when we throw away outer scope information without any practical reason, IMO. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Where should I put a `condp` like function?
On Wednesday, 17 April 2013 at 13:09:45 UTC, Nick Treleaven wrote:
On 15/04/2013 06:00, H. S. Teoh wrote:
Allowing arbitrary predicates and switch-as-expression allows
you to
write code that shows intent very clearly:
// In pseudo-D syntax
void fill(T)(T image, int x, int y) {
image[x,y] = switch {
case isFillable(image,x,y): fillColor;
case isBorder(image,x,y): borderColor;
default: defaultColor;
};
}
We could use a conditional operator chain:
image[x,y] = isFillable(image,x,y) ? fillColor :
isBorder(image,x,y) ? borderColor :
defaultColor;
Naturally - even as statements, a `switch` statement without a
switch expression is no better than a chain of `if`-`else`s.
Now, consider this hackish use of `predSwitch`:
https://gist.github.com/someboddy/5412843
This is actual D code(you need
https://github.com/D-Programming-Language/phobos/pull/1259 to run
it), and it prints:
*
*...*
*.+.*
*...*
*
As expected. This does have an advantage over a chain of
`if`-`else`s or ternary operators - you only need to write the
argument list once.
Re: Attribute inference for auto functions?
On Thursday, 18 April 2013 at 05:59:20 UTC, kenji hara wrote:
It will break existing code.
int foo() {
typeof(return) bar() { return 1; }
return bar();
}
typeof(return) represents the return type of foo, that is int.
Kenji Hara
It wouldn't break the code though. It would change the meaning,
but the code would compile just as it did before.
Re: Where should I put a `condp` like function?
On Thursday, 18 April 2013 at 13:04:19 UTC, Graham Fawcett wrote: On Sunday, 14 April 2013 at 23:52:37 UTC, Idan Arye wrote: Now, I've got it working(the example actually compiles and prints less then 5), and I want to make a pull request to put it in Phobos(because it's a useful function) but I don't really know where to put it. None of the existing modules seems fit, and I don't want to open a new module(std.monad?) for a single function. Nit-picky observation: there's nothing monadic about your predSwitch function, it wouldn't belong in a 'std.monad' module. Best, Graham A monad is a structure that represents computations(quote from Wikipedia). While the Turing machine branch(=the main branch) of computability theory quickly fell into the Turing tarpit and had to moved to pseudo-code, the Lambda calculus was expended using the traditional mathematical method of defining symbols that replace other symbols. That's why when in the Turing machine branch you could just write `if ... then ... else ...` and it's okay because it's pseudo-code, in Lambda calculus you actually have an IFTHENELSE defined as a lambda expression. And so on with loops, exception handling, and even type definitions and input/output. I find that `predSwitch` - a function that represents the `switch` idiom - perfectly fits into the definition of monads.
Re: Is there any plans to make working signals in D?
On Thursday, 18 April 2013 at 13:25:32 UTC, Denis Shelomovskij wrote: - What is the fundamental problem. When a delegate is created information about it's outer scope is lost instead of being stored in it's ptr. That doesn't mean anything. No information is stored into a ptr except an address in memory. - Why this fundamental problem is a language issue and not a lib one. Looks self-evident. It look self evident to me that the earth is flat when I look through the window. - How does you proposition solve it. It stores the information about delegate's outer scope wasting (oh God, how many, especially in contrast to GC allocation) a few bytes. I don't care about the cost. You have made no point in 3 pages in favor of the change you propose. Not even an invalid point I can disagree on. As everything I have written above is known, I still don't understand why you are telling about signal fixing as a main problem as it is just an example of problems that occurs when we throw away outer scope information without any practical reason, IMO. It is an example of a library interface issue (very real). To propose a language change, you must show that this limitation is in fact a symptom of a deeper cause, which it at language level (so that must be fixed at language level).
Re: Where should I put a `condp` like function?
On Thursday, 18 April 2013 at 13:58:46 UTC, Idan Arye wrote: Naturally - even as statements, a `switch` statement without a switch expression is no better than a chain of `if`-`else`s. As mentioned before in other thread, LLVM is crazy good at transforming if/else chains into switch statement, and GCC does a good job at it as well.
[no subject]
Can anyone explain this restriction to me?
Trying to extern to a C++ class.
// mirror the C++ vtable
extern (C++) interface IVirtuals
{
void virtualMethod();
}
// create a struct to pose as the C++ class
struct Test
{
// make the virtuals accessible with 'static this'
@property IVirtuals _vtable() { return cast(IVirtuals)this; }
alias _vtable this;
// class members can be defined here...
}
So that's fine. But the line I'm interested in is:
alias _vtable this;
Aliasing a property like that works fine, but why doesn't this work:
alias (){ return cast(IVirtuals)this; } this;
Or this:
alias (() = cast(IVirtuals)this) this;
Or even:
alias (cast(IVirtuals)this) this;
I don't really see how they're different than the property?
I mean, I can see how they're an expression, and in the situation that
works, I'm aliasing a symbol... but why is that a requirement? And why
isn't a literal just as good as a symbol?
Re: Attribute inference for auto functions?
On 4/18/13 2:38 AM, Walter Bright wrote:
On 4/17/2013 11:34 PM, deadalnix wrote:
On Thursday, 18 April 2013 at 05:59:20 UTC, kenji hara wrote:
It will break existing code.
int foo() {
typeof(return) bar() { return 1; }
return bar();
}
typeof(return) represents the return type of foo, that is int.
That is true :( Don't seem fixable.
It is fixable if it is special cased, but special cases stink.
Thanks Kenji for a surgical destruction.
Andrei
Re: Attribute inference for auto functions?
On 4/18/13 2:49 AM, Timon Gehr wrote: On 04/18/2013 01:46 AM, Walter Bright wrote: - adding the attribute retains covariance. I am sorry, but I do not understand your notion of covariance. I think he means subtyping. An attributed function (pure, nothrow) is a subtype of a non-attributed function. That means it can substitute the non-attributed function. Andrei
Re: Where should I put a `condp` like function?
On Thursday, 18 April 2013 at 14:26:08 UTC, deadalnix wrote: On Thursday, 18 April 2013 at 13:58:46 UTC, Idan Arye wrote: Naturally - even as statements, a `switch` statement without a switch expression is no better than a chain of `if`-`else`s. As mentioned before in other thread, LLVM is crazy good at transforming if/else chains into switch statement, and GCC does a good job at it as well. A `switch` statement is faster than a `if`-`else` chain only when it can use a lookup table, and for the lookup table a switch expression is a must. Another precondition for a lookup table is that the test expressions are known at compile-time. The given example has none - there is no switch expression(though one may argue that you can use `true` as the switch expression) and the test expressions are function calls calculated at runtime. If the compiler can translate a `if`-`else` chain to a `switch` statement - then it should have probably been a `switch` statement in the first place. That way it would have also been more readable.
Re: DConf 2013 official car/room sharing thread
On 4/18/2013 1:23 AM, Iain Buclaw wrote: Incidentally, I only get around by bicycle (even moved 400 miles to a new home on one last year). =) It's far too dangerous to commute by bike in Seattle. The streets are winding and narrow. I tried it briefly, but it wasn't worth it.
Re: Where should I put a `condp` like function?
On 04/18/2013 04:18 PM, Idan Arye wrote: On Thursday, 18 April 2013 at 13:04:19 UTC, Graham Fawcett wrote: On Sunday, 14 April 2013 at 23:52:37 UTC, Idan Arye wrote: Now, I've got it working(the example actually compiles and prints less then 5), and I want to make a pull request to put it in Phobos(because it's a useful function) but I don't really know where to put it. None of the existing modules seems fit, and I don't want to open a new module(std.monad?) for a single function. Nit-picky observation: there's nothing monadic about your predSwitch function, it wouldn't belong in a 'std.monad' module. Best, Graham A monad is a structure that represents computations(quote from Wikipedia). ... Read on.
Re: DConf 2013 official car/room sharing thread
On 18 April 2013 18:04, Walter Bright newshou...@digitalmars.com wrote: On 4/18/2013 1:23 AM, Iain Buclaw wrote: Incidentally, I only get around by bicycle (even moved 400 miles to a new home on one last year). =) It's far too dangerous to commute by bike in Seattle. The streets are winding and narrow. I tried it briefly, but it wasn't worth it. I certainly don't mind winding and narrow. Cycling isn't inherently dangerous, but the two main things that don't help are - lack of cycle paths; careless or inconsiderate drivers. -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: DConf 2013 official car/room sharing thread
On Thursday, 18 April 2013 at 17:04:49 UTC, Walter Bright wrote: On 4/18/2013 1:23 AM, Iain Buclaw wrote: Incidentally, I only get around by bicycle (even moved 400 miles to a new home on one last year). =) It's far too dangerous to commute by bike in Seattle. The streets are winding and narrow. I tried it briefly, but it wasn't worth it. Is that USA winding and narrow, or something I would recognise as winding and narrow (UK)?
Re: DConf 2013 official car/room sharing thread
On 4/18/2013 10:42 AM, Iain Buclaw wrote: I certainly don't mind winding and narrow. Cycling isn't inherently dangerous, but the two main things that don't help are - lack of cycle paths; careless or inconsiderate drivers. When you have cars brushing by your elbow at 40 mph, well, I thought that was very dangerous. When going around curves, cars routinely cut into the inside shoulder. They'll do it on blind corners, too. I'm actually surprised that a lot more bikers aren't killed around here, although many are. I walk a lot, and many times I've had to step lively off of the road.
Re: DConf 2013 official car/room sharing thread
On 4/18/2013 10:47 AM, John Colvin wrote: On Thursday, 18 April 2013 at 17:04:49 UTC, Walter Bright wrote: On 4/18/2013 1:23 AM, Iain Buclaw wrote: Incidentally, I only get around by bicycle (even moved 400 miles to a new home on one last year). =) It's far too dangerous to commute by bike in Seattle. The streets are winding and narrow. I tried it briefly, but it wasn't worth it. Is that USA winding and narrow, or something I would recognise as winding and narrow (UK)? In Seattle, the standard road is two Roman chariots wide, rather than one.
Re: DConf 2013 official car/room sharing thread
On 4/18/2013 10:50 AM, Walter Bright wrote: I'm actually surprised that a lot more bikers aren't killed around here, although many are. I walk a lot, and many times I've had to step lively off of the road. There's also a politically powerful bike lobby around here, but I don't think this is a problem that can be solved by politics.
Re: DConf 2013 official car/room sharing thread
On Thu, Apr 18, 2013 at 10:50:55AM -0700, Walter Bright wrote: On 4/18/2013 10:42 AM, Iain Buclaw wrote: I certainly don't mind winding and narrow. Cycling isn't inherently dangerous, but the two main things that don't help are - lack of cycle paths; careless or inconsiderate drivers. When you have cars brushing by your elbow at 40 mph, well, I thought that was very dangerous. When going around curves, cars routinely cut into the inside shoulder. They'll do it on blind corners, too. I'm actually surprised that a lot more bikers aren't killed around here, although many are. I walk a lot, and many times I've had to step lively off of the road. Speaking of careless drivers... not long ago up here in Canuckland (a few hours' drive from Seattle, incidentally), I almost got run over by a car *while crossing a crosswalk with flashing lights*. There was another vehicle which had come to a stop in the outer lane, which may have obscured me, but the car in the inner lane obviously didn't see me and didn't notice the big flashing lights above the crosswalk (and didn't consider why the vehicle on her right had stopped at a crosswalk with big flashing lights above). Fortunately I was keeping an eye on it (I wasn't sure if it was slowing down so I hesitated). The driver screamed (oh yeah did she scream -- I could hear it through her closed windows) and slammed the brakes when she saw me, but couldn't stop in time; I stepped back just in time as she passed in front of me about 1-2 feet at the most. Since then, I no longer assume that red lights, pedestrian walk signs, or crosswalk flashing lights mean anything to drivers. You might pay for that assumption with your life. *shudder* T -- Life is all a great joke, but only the brave ever get the point. -- Kenneth Rexroth
Port of libnoise to d
Hey guys. Just wanted to let anyone interested know that I got libnoise ported into a (barely) workable state. I actually did this last year, but got held up with other things and never got around to actually getting it working. So now I have! I've added a couple of things to it as well, the biggest one being a simplex noise generator. It's still in a very rough state but it is usable. If anyone wants to take a look or grab it it's on my github: https://github.com/kniteli/libnoise-d Building is currently a pain so I'd recommend just importing the sources directly. I'm going to get the library sorted out as I go along, as I'm playing around with coherent noise terrain generation. Oh yeah, one last thing, here's some cool formations generated with the simplex generator in a voxel engine: http://imgur.com/bhwWnny Can you believe that used to be a cube?
Re: DConf 2013 official car/room sharing thread
On 04/18/2013 07:50 PM, Walter Bright wrote: ... I'm actually surprised that a lot more bikers aren't killed around here, although many are. I walk a lot, and many times I've had to step lively off of the road. And I thought the bus factor was just a metaphor!
Re: DConf 2013 official car/room sharing thread
On Thursday, 18 April 2013 at 18:45:56 UTC, H. S. Teoh wrote: On Thu, Apr 18, 2013 at 10:50:55AM -0700, Walter Bright wrote: On 4/18/2013 10:42 AM, Iain Buclaw wrote: I certainly don't mind winding and narrow. Cycling isn't inherently dangerous, but the two main things that don't help are - lack of cycle paths; careless or inconsiderate drivers. When you have cars brushing by your elbow at 40 mph, well, I thought that was very dangerous. When going around curves, cars routinely cut into the inside shoulder. They'll do it on blind corners, too. I'm actually surprised that a lot more bikers aren't killed around here, although many are. I walk a lot, and many times I've had to step lively off of the road. Speaking of careless drivers... not long ago up here in Canuckland (a few hours' drive from Seattle, incidentally), I almost got run over by a car *while crossing a crosswalk with flashing lights*. There was another vehicle which had come to a stop in the outer lane, which may have obscured me, but the car in the inner lane obviously didn't see me and didn't notice the big flashing lights above the crosswalk (and didn't consider why the vehicle on her right had stopped at a crosswalk with big flashing lights above). Fortunately I was keeping an eye on it (I wasn't sure if it was slowing down so I hesitated). The driver screamed (oh yeah did she scream -- I could hear it through her closed windows) and slammed the brakes when she saw me, but couldn't stop in time; I stepped back just in time as she passed in front of me about 1-2 feet at the most. Since then, I no longer assume that red lights, pedestrian walk signs, or crosswalk flashing lights mean anything to drivers. You might pay for that assumption with your life. *shudder* T In quite a bit of mainland europe, red lights only apply to straight on traffic and not to people turning. The number of times I almost got killed by cars turning into me in a single week in Rome was ridiculous!
Re: DConf 2013 official car/room sharing thread
On 18 April 2013 18:50, Walter Bright newshou...@digitalmars.com wrote: On 4/18/2013 10:42 AM, Iain Buclaw wrote: I certainly don't mind winding and narrow. Cycling isn't inherently dangerous, but the two main things that don't help are - lack of cycle paths; careless or inconsiderate drivers. When you have cars brushing by your elbow at 40 mph, well, I thought that was very dangerous. When going around curves, cars routinely cut into the inside shoulder. They'll do it on blind corners, too. Been there and done that with a few buses and lorries. Also had a few near misses where the shear force of the wind almost derailed me into the vehicle passing. Other than that, I quite happily sit in the drag of a car going 40mph downhill, or scrape through the busy traffic of a city. -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: DConf 2013 official car/room sharing thread
On 18 April 2013 19:01, Walter Bright newshou...@digitalmars.com wrote: On 4/18/2013 10:50 AM, Walter Bright wrote: I'm actually surprised that a lot more bikers aren't killed around here, although many are. I walk a lot, and many times I've had to step lively off of the road. There's also a politically powerful bike lobby around here, but I don't think this is a problem that can be solved by politics. Cycle paths and routes can still be developed through state funding. One of the best things for cyclists in the UK is the national cycle network, which through experience is a great way to get around the country. -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: DConf 2013 official car/room sharing thread
On 18 April 2013 21:31, Iain Buclaw ibuc...@ubuntu.com wrote: On 18 April 2013 19:01, Walter Bright newshou...@digitalmars.com wrote: On 4/18/2013 10:50 AM, Walter Bright wrote: I'm actually surprised that a lot more bikers aren't killed around here, although many are. I walk a lot, and many times I've had to step lively off of the road. There's also a politically powerful bike lobby around here, but I don't think this is a problem that can be solved by politics. Cycle paths and routes can still be developed through state funding. One of the best things for cyclists in the UK is the national cycle network, which through experience is a great way to get around the country. ... if time is most certainly not of the essence. :o) Regards -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: DConf 2013 official car/room sharing thread
On Thursday, 18 April 2013 at 20:31:14 UTC, Iain Buclaw wrote: On 18 April 2013 19:01, Walter Bright newshou...@digitalmars.com wrote: On 4/18/2013 10:50 AM, Walter Bright wrote: I'm actually surprised that a lot more bikers aren't killed around here, although many are. I walk a lot, and many times I've had to step lively off of the road. There's also a politically powerful bike lobby around here, but I don't think this is a problem that can be solved by politics. Cycle paths and routes can still be developed through state funding. One of the best things for cyclists in the UK is the national cycle network, which through experience is a great way to get around the country. It's amazing what the netherlands have done for cycling: http://en.wikipedia.org/wiki/Cycling_in_the_Netherlands
Re: DConf 2013 official car/room sharing thread
On 4/18/2013 1:31 PM, Iain Buclaw wrote: Cycle paths and routes can still be developed through state funding. One of the best things for cyclists in the UK is the national cycle network, which through experience is a great way to get around the country. I nearly got run over several times just walking around London!
Re: DConf 2013 official car/room sharing thread
On 4/18/2013 11:44 AM, H. S. Teoh wrote: Since then, I no longer assume that red lights, pedestrian walk signs, or crosswalk flashing lights mean anything to drivers. You might pay for that assumption with your life. *shudder* The phrase is you don't want to be right - dead right. The bikers and pedestrians that resolutely expect me to dodge them amaze me. They never even look. There'll be 4 abreast walking, sticking out into the lane. To pass them, the driver is forced into the left lane. Of course they never look to see if the drivers actually will. I drove around a blind corner once (on a fairly major road) and there's a guy on a bike in the middle, stopped, towing his baby behind the bike. I couldn't believe it! I stopped and yelled at him I was so upset - he was shocked that there was anything stupid about what he was doing. Another time, a woman is pushing her baby carriage down the center of the lane. She didn't even look back as I drove up behind her. I stopped and yelled at her. She said well, if my number is up, my number is up. Unbelievable. My dad used to irritate the heck out of me by driving down residential streets at about 10 mph. I understand now why he did that.
Re: DConf 2013 official car/room sharing thread
On Thu, Apr 18, 2013 at 02:30:04PM -0700, Walter Bright wrote: On 4/18/2013 11:44 AM, H. S. Teoh wrote: Since then, I no longer assume that red lights, pedestrian walk signs, or crosswalk flashing lights mean anything to drivers. You might pay for that assumption with your life. *shudder* The phrase is you don't want to be right - dead right. Right, I'd rather be alive and wrong than *dead* right. The bikers and pedestrians that resolutely expect me to dodge them amaze me. They never even look. There'll be 4 abreast walking, sticking out into the lane. To pass them, the driver is forced into the left lane. Of course they never look to see if the drivers actually will. I grew up in a country where drivers will deliberately step on the gas if you dare jay-walk in front of them. On this continent, however, it seems the opposite prevails -- drivers are expected to go out of their way to be nice to you. Rumor has it that the rate of pedestrian-related accidents for BC residents are highest *outside* the province. Apparently people here come to take driver niceness for granted, and then they go out into the *ahem* real world and they get run over. *shrug* I drove around a blind corner once (on a fairly major road) and there's a guy on a bike in the middle, stopped, towing his baby behind the bike. I couldn't believe it! I stopped and yelled at him I was so upset - he was shocked that there was anything stupid about what he was doing. Another time, a woman is pushing her baby carriage down the center of the lane. She didn't even look back as I drove up behind her. I stopped and yelled at her. She said well, if my number is up, my number is up. Unbelievable. My dad used to irritate the heck out of me by driving down residential streets at about 10 mph. I understand now why he did that. Yeah, up here in the Great White North we also have our fair share of people who do stupid things on the road... like jay-walk across a busy street at night wearing dark clothes, or ride a bike down an unlit street at night *without* any blinkers or lights of any sort (or helmet, for that matter). Worst are those who would walk in front of a moving car and then yell at the driver for not stopping for them (this actually happened to my then-fiancée once -- I was in the car, and quite speechless at the pedestrian's audacity). Of course, back in Asia where traffic rules are only recommendations, a different kind of stupidity prevails... like zigzagging a moped through moving traffic with a baby in one hand and bulging bags of groceries in the other (and another child clinging to the back without a helmet). Well, it looks like my random signature Perl script has picked out an appropriate quote for the occasion. ;-) T -- Do not reason with the unreasonable; you lose by definition.
x64 Link Issues - Can someone please help?
Hey all,
I'm currently using D for a hook-based project that requires me
to build both a 32bit and 64bit DLL. Naturally, the 32bit DLL
builds fine, however I'm encountering linking issues for the
64bit.
I followed the instructions at
http://wiki.dlang.org/Installing_DMD_on_64-bit_Windows_7_(COFF-compatible)
for setting up 64bit building (albeit I didn't use his
environment variables - I just put the paths into sc.ini
directly), so if there's a problem with my setup, I don't see it.
Here is my build output (I'm using Xamarin Studio with Mono-D, if
that means anything):
---
Building: HookLib (Debug|x64)
Performing main compilation...
Current dictionary:
C:\Development\Projects\EyefinityMaximizer\HookLib
dmd.exe -debug -gc main.d
C:\Development\Projects\EyefinityMaximizer\EyefinityMaximizer\eyemax\WinAPI.d
HookLib.def user32.lib
-IC:\Development\Compilers\D\dmd2\src\phobos
-IC:\Development\Compilers\D\dmd2\src\druntime\src
-L/IMPLIB:C:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLib.x64.lib
-odobj\Debug
-ofC:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLib.x64.dll
-m64
HookLib.def(1) : warning LNK4017: EXETYPE statement not supported
for the target platform; ignored
HookLib.def(2) : warning LNK4017: SUBSYSTEM statement not
supported for the target platform; ignored
HookLib.x64.obj : warning LNK4197: export 'CallWndProc' specified
multiple times; using first specification
Creating library
C:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLib.x64.lib
and object
C:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLib.x64.exp
phobos64.lib(dmain2_4ac_1a5.obj) : error LNK2019: unresolved
external symbol _Dmain referenced in function main
C:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLib.x64.dll
: fatal error LNK1120: 1 unresolved externals
--- errorlevel 1120
Exit code 1120
Build complete -- 1 error, 0 warnings
---
As you can see, there appears to be an issue with my usage of
WinMain() as opposed to just main(). For 32bit building, the
documentation states that the compiler recognizes WinMain and
works accordingly - is this also the case for 64bit building?
Here is my WinMain function, in case I'm doing something wrong
with it:
---
extern(Windows) int WinMain(HINSTANCE hInstance, HINSTANCE
hPrevInstance, LPSTR lpCmdLine, int iCmdShow) {
int result;
void exceptionHandler(Throwable e) { throw e; }
// Init the D runtime
try {
Runtime.initialize(exceptionHandler);
result = myWinMain(hInstance, hPrevInstance, lpCmdLine,
iCmdShow);
Runtime.terminate(exceptionHandler);
} catch (Throwable e) {
MessageBoxA(null, e.toString().toStringz, Error, MB_OK |
MB_ICONEXCLAMATION);
result = 0;
}
return result;
}
---
Any assistance would be appreciated, as this project is stalled
until I can build 64bit binaries.
Thanks and regards,
Trey
Re: x64 Link Issues - Can someone please help?
On Friday, 19 April 2013 at 00:24:27 UTC, Trey Brisbane wrote: As you can see, there appears to be an issue with my usage of WinMain() as opposed to just main(). For 32bit building, the documentation states that the compiler recognizes WinMain and works accordingly - is this also the case for 64bit building? The entry point for DLLs is the DllMain function, not WinMain. I'm not sure why building a DLL with a WinMain entry point would succeed - I'd assume the resulting DLL wouldn't work. In the future, consider posting questions on how to use D to the digitalmars.D.learn group.
Re: DConf 2013 official car/room sharing thread
On Thursday, 18 April 2013 at 21:30:06 UTC, Walter Bright wrote: On 4/18/2013 11:44 AM, H. S. Teoh wrote: Since then, I no longer assume that red lights, pedestrian walk signs, or crosswalk flashing lights mean anything to drivers. You might pay for that assumption with your life. *shudder* The phrase is you don't want to be right - dead right. The bikers and pedestrians that resolutely expect me to dodge them amaze me. They never even look. There'll be 4 abreast walking, sticking out into the lane. To pass them, the driver is forced into the left lane. Of course they never look to see if the drivers actually will. I drove around a blind corner once (on a fairly major road) and there's a guy on a bike in the middle, stopped, towing his baby behind the bike. I couldn't believe it! I stopped and yelled at him I was so upset - he was shocked that there was anything stupid about what he was doing. Another time, a woman is pushing her baby carriage down the center of the lane. She didn't even look back as I drove up behind her. I stopped and yelled at her. She said well, if my number is up, my number is up. Unbelievable. My dad used to irritate the heck out of me by driving down residential streets at about 10 mph. I understand now why he did that. I agree with your sentiment. People are nightmarishly illogical. Maybe they feel more like Achilles, whose destiny was greatness, followed by death, than, say, Socrates, who got killed because he made too much sense. If *I* have to go down, I hope will be more like Socrates than Achilles.
Re: x64 Link Issues - Can someone please help?
On Friday, 19 April 2013 at 00:53:28 UTC, Vladimir Panteleev
wrote:
On Friday, 19 April 2013 at 00:24:27 UTC, Trey Brisbane wrote:
As you can see, there appears to be an issue with my usage of
WinMain() as opposed to just main(). For 32bit building, the
documentation states that the compiler recognizes WinMain and
works accordingly - is this also the case for 64bit building?
The entry point for DLLs is the DllMain function, not WinMain.
I'm not sure why building a DLL with a WinMain entry point
would succeed - I'd assume the resulting DLL wouldn't work.
In the future, consider posting questions on how to use D to
the digitalmars.D.learn group.
You're completely right. It seems I copy+pasted from the wrong
source file by mistake.
My DLLMain (not WinMain) is as follows:
---
extern (Windows) BOOL DllMain(HINSTANCE hInstance, ULONG
ulReason, LPVOID pvReserved) {
// Main DLL switch
switch (ulReason) {
case DLL_PROCESS_ATTACH:
g_hInst = hInstance;
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:
break;
}
return true;
}
---
With regards to digitalmars.D.learn - I had considered posting
there, but considering this isn't really a question about
learning D, but rather about getting an existing D project to
build, I decided against it. If that is however the preferred
location for such a question, I will post there next time as you
suggested. :)
Re: Zero timeout receive
On Tuesday, 16 April 2013 at 21:38:39 UTC, Sean Kelly wrote: On Apr 15, 2013, at 7:22 PM, James Wirth jwir...@suddenlink.net wrote: Special casing receiveTimeout would introduce less name bloat but might impact other receive performance. As a Java programmer I tend to ignore slowdowns of 2:1 and as a Python programmer even 70:1 - but I could see that system programmers might disagree. Currently, receiveTimeout will call Condition.wait(n) for any wait time passed. For a wait time of 0, this will be equivalent to a yield(), so the calling thread will be suspended for a context switch if there are other threads waiting to run. I could special case this to not wait at all, but am inclined to say that the yield() effect is a good thing here, as it helps concurrency. Many Thanks, I appreciate the hand holding. Will use receiveTimeout(0,...) without fear henceforth. I think yielding in the windows event thread will indeed benefit the application.
dbghelp in wine
Am developing MS application using D via Wine. Is working pretty good. However, I get a stderr message: err:dbghelp_msc:codeview_process_info Unknown CODEVIEW signature ... during the throw of an Exception subclass which is being caught and the application is running blissfully on. Is the dbghelp a Wine feature or a D Phobos feature? I seem to get hits searching for dbghelp both ways. I am using the -g flag in the DMD compile, did not think -gc was appropriate??? Yes - I realize developing D for MS via Wine is crazy - its a long story.
Re: DConf 2013 official car/room sharing thread
On 19 April 2013 03:42, Iain Buclaw ibuc...@ubuntu.com wrote: On 18 April 2013 18:04, Walter Bright newshou...@digitalmars.com wrote: On 4/18/2013 1:23 AM, Iain Buclaw wrote: Incidentally, I only get around by bicycle (even moved 400 miles to a new home on one last year). =) It's far too dangerous to commute by bike in Seattle. The streets are winding and narrow. I tried it briefly, but it wasn't worth it. I certainly don't mind winding and narrow. Cycling isn't inherently dangerous, but the two main things that don't help are - lack of cycle paths; careless or inconsiderate drivers. I presume you've been to the states before right? ;)
Re: mysql
On Tuesday, 16 April 2013 at 21:09:42 UTC, gedaiu wrote: On Monday, 15 April 2013 at 19:25:19 UTC, simendsjo wrote: On Monday, 15 April 2013 at 17:34:07 UTC, gedaiu wrote: Hi, Can anyone help me to connect to mysql from D? Thanks! You can use Steve Teales native library. The most up-to-date version is here: https://github.com/rejectedsoftware/mysql-native It relies on vibes async sockets though. You'll have to grab an earlier version or modify it yourself if you want to use phobos sockets. Thanks for the tip! I would like to use vibe, but i don't know how to install it.. I am using ubuntu. I ran the setup-linux.sh script, it worked perfectly, but my d procram does not see the mdules... Thanks, Bogdan Install it with dub. Registry.rejectedsoftware.com iirc
Re: Copying reference types by value
On 04/17/2013 10:29 PM, Ali Çehreli wrote: Yes but as I said I am not sure how useful or needed this whole thing is. The language handles copy, move, and assignment for structs. takeOver() seems to be a primitive operation for classes. Could you expand a bit on that? Just that I'm not sure I understand your meaning completely, and I'm curious. :-) That's what I meant by a wrapper function. But I think move is a more fundamental operation that elides a copy. If we had only copyFrom(), then the following would indeed need to copy: // foo() returns a class object a.copyFrom(foo()); On the other hand, takeOver() would have the ability to move the members of the returned rvalue object without needing to copy. OK, clear. In fact seems possible that copying vs. takeover might be useful to define separately and use whichever is optimal for the given use-case. Agreed. I'd assumed this problem would be some fairly straightforward aspect of the language that I just wasn't familiar with, so I'm quite struck by the fact that it actually seems a non-trivial problem.
Why are fixed length arrays passed by value while variable are passed by reference?
I know this will not be changed, I just want to understand why it is as it is. My naive thought is that consistency is the best scheme and that everything should have been passed by value or everything by reference unless the user specifies otherwise. I have read a comment by Andrei that they tried making fixed length arrays into reference types but it did not work well. Did the current situation arise through the reality of language development or is there a reason for the inconsistency?
Re: Why are fixed length arrays passed by value while variable are passed by reference?
On 2013-04-18 15:37, ixid wrote:
I know this will not be changed, I just want to understand why it is as
it is.
My naive thought is that consistency is the best scheme and that
everything should have been passed by value or everything by reference
unless the user specifies otherwise.
I have read a comment by Andrei that they tried making fixed length
arrays into reference types but it did not work well. Did the current
situation arise through the reality of language development or is there
a reason for the inconsistency?
An array is represent using a struct with a pointer to the array data
and the length, like this:
struct Array
{
void* ptr;
size_t length;
}
The struct is passed by value, but since it contains a pointer to the
data it will be passed by reference. Note that if you do:
void foo (int[] a)
{
a ~= 3;
}
auto b = [3, 4];
foo(b);
The caller will not see the change made by foo.
Don't know if this explanation helped you to understand.
--
/Jacob Carlborg
Re: Why are fixed length arrays passed by value while variable are passed by reference?
An array is represent using a struct with a pointer to the
array data and the length, like this:
struct Array
{
void* ptr;
size_t length;
}
The struct is passed by value, but since it contains a pointer
to the data it will be passed by reference. Note that if you do:
void foo (int[] a)
{
a ~= 3;
}
auto b = [3, 4];
foo(b);
The caller will not see the change made by foo.
Don't know if this explanation helped you to understand.
What does a fixed length array look like when passed, doesn't it
have a similar payload of data and length? I take it you mean the
struct method is the variable length array.
Re: Why are fixed length arrays passed by value while variable are passed by reference?
On 2013-04-18, 16:20, ixid wrote:
An array is represent using a struct with a pointer to the array data
and the length, like this:
struct Array
{
void* ptr;
size_t length;
}
The struct is passed by value, but since it contains a pointer to the
data it will be passed by reference. Note that if you do:
void foo (int[] a)
{
a ~= 3;
}
auto b = [3, 4];
foo(b);
The caller will not see the change made by foo.
Don't know if this explanation helped you to understand.
What does a fixed length array look like when passed, doesn't it have a
similar payload of data and length? I take it you mean the struct method
is the variable length array.
The fixed length array is much more similar to a struct. An int[2], for
instance, is in many ways equivalent to struct { int a; int b; }.
Two ways this is visible is that static arrays are allocated on the stack,
and take up space in a struct or class the same way a struct would:
struct S1 {
int[] a;
}
static assert( S1.sizeof == int[].sizeof );
struct S2 {
int[17] a;
}
static assert( S2.sizeof == 17 * int.sizeof );
Also, like Jacob wrote, there is the difference of ref/value semantics
when embedded in a struct/class. If I have these two functions:
void foo1( S1 s ) {
s.a[0] = 7;
}
void foo2( S2 s ) {
s.a[0] = 7;
}
void test( ) {
S1 s1 = S1(new int[4]);
S2 s2 = S2();
foo1(s1);
foo2(s2);
}
The values in s1 will have changed, while those in s2 will not.
All in all, static arrays are treated as value types everywhere else,
and so treating them as value types when passed to a function makes
more sense.
--
Simen
Re: Why are fixed length arrays passed by value while variable are passed by reference?
On Thursday, 18 April 2013 at 13:37:45 UTC, ixid wrote: I know this will not be changed, I just want to understand why it is as it is. My naive thought is that consistency is the best scheme and that everything should have been passed by value or everything by reference unless the user specifies otherwise. Classifying types as passed by value and passed by reference types is a little bit confusing sometimes) In D, like in C, everything is passed by value (unless parameter is specified as ref, also note that in C passing by reference is a simulation done by pointers). Confusion comes when there is data which points to another data. Learning how data types are constructed is better approach than classifying their categories. The former sometimes can explain what the latter cannot: http://dpaste.dzfl.pl/7744d11e AA array behaves like a reference type, but when it is reset to null, it acts like a value type. Contradiction is caused by complex data structes with mixed structs and pointers in AA implementation. I have read a comment by Andrei that they tried making fixed length arrays into reference types but it did not work well. Did the current situation arise through the reality of language development or is there a reason for the inconsistency? I don't consider curent situation with static arrays as incosistent.
Re: Why are fixed length arrays passed by value while variable are passed by reference?
On 04/18/2013 07:20 AM, ixid wrote:
Jacob Carlborg said:
An array is represent using a struct with a pointer to the array data
and the length, like this:
struct Array
{
void* ptr;
size_t length;
}
The terms array and slice are commonly interchanged but I think it
adds to the confusion. The above is the definition of a slice. An array
is simply a collection of objects placed next to each other.
The struct is passed by value, but since it contains a pointer to the
data it will be passed by reference. Note that if you do:
void foo (int[] a)
{
a ~= 3;
}
auto b = [3, 4];
foo(b);
The caller will not see the change made by foo.
Don't know if this explanation helped you to understand.
What does a fixed length array look like when passed, doesn't it have a
similar payload of data and length?
No. It is all of the elements side by side. That is the definition of an
array.
int[3] a;
assert(a.sizeof == ((a[0]).sizeof * a.length));
assert(cast(void*)a == cast(void*)(a[0]));
A fixed-length array does not have a ptr or length member. The former is
simly the address of the fixed-length array itself and the latter is a
compile-time constant.
I take it you mean the struct method
is the variable length array.
Yes. The struct above is a slice. (Although, in reality length is
defined before ptr.)
Ali
Re: Why are fixed length arrays passed by value while variable are passed by reference?
On Thu, 18 Apr 2013 11:26:22 -0400, Maxim Fomin ma...@maxim-fomin.ru wrote: On Thursday, 18 April 2013 at 13:37:45 UTC, ixid wrote: I know this will not be changed, I just want to understand why it is as it is. My naive thought is that consistency is the best scheme and that everything should have been passed by value or everything by reference unless the user specifies otherwise. Classifying types as passed by value and passed by reference types is a little bit confusing sometimes) In D, like in C, everything is passed by value (unless parameter is specified as ref, also note that in C passing by reference is a simulation done by pointers). Confusion comes when there is data which points to another data. Learning how data types are constructed is better approach than classifying their categories. The former sometimes can explain what the latter cannot: http://dpaste.dzfl.pl/7744d11e AA array behaves like a reference type, but when it is reset to null, it acts like a value type. Contradiction is caused by complex data structes with mixed structs and pointers in AA implementation. AA's are not passed by reference, they ARE a reference. That reference is ALWAYS passed by value, unless ref is used. The problem with AA's is that the special reference null mutates upon first addition to the AA, and never changes afterwards, unless reassigned. It is always passed by value. In fact, if default construction allowed allocating the initial reference (or null wasn't treated specially), we wouldn't have that problem. -Steve
Re: Why are fixed length arrays passed by value while variable are passed by reference?
I don't consider curent situation with static arrays as incosistent. When correctly understood is isn't as inconsistent, thank you for explaining, this was the knowledge I was after.
writeln an object
Hi, how i can control what writeln outputs when I pass an object parameter? Thanks, Bogdan
Re: writeln an object
On Thursday, 18 April 2013 at 17:36:10 UTC, gedaiu wrote: Hi, how i can control what writeln outputs when I pass an object parameter? Thanks, Bogdan You can override the toString() method, like this http://dpaste.dzfl.pl/db7dbe28
Re: writeln an object
On Thursday, 18 April 2013 at 17:42:53 UTC, JN wrote: On Thursday, 18 April 2013 at 17:36:10 UTC, gedaiu wrote: Hi, how i can control what writeln outputs when I pass an object parameter? Thanks, Bogdan You can override the toString() method, like this http://dpaste.dzfl.pl/db7dbe28 i've done that but i get this error: Error: function base.Value.Value.toString cannot override a non-virtual function Error: function base.Value.Value.toString override only applies to class member functions
Re: writeln an object
On 4/18/13, gedaiu szabobog...@yahoo.com wrote: i've done that but i get this error: Error: function base.Value.Value.toString cannot override a non-virtual function Error: function base.Value.Value.toString override only applies to class member functions If it's a struct then don't put override.
Re: writeln an object
On Thursday, 18 April 2013 at 18:04:03 UTC, Andrej Mitrovic wrote: On 4/18/13, gedaiu szabobog...@yahoo.com wrote: i've done that but i get this error: Error: function base.Value.Value.toString cannot override a non-virtual function Error: function base.Value.Value.toString override only applies to class member functions If it's a struct then don't put override. Just to provide a bit more info: Classes all derive from Object, which defines toString. Hence, you need to override it to define your own. Structs don't have a parent (or any inheritance at all) and hence you don't override anything, you just define the method.
Re: writeln an object
On Thursday, 18 April 2013 at 18:25:21 UTC, John Colvin wrote:
On Thursday, 18 April 2013 at 18:04:03 UTC, Andrej Mitrovic
wrote:
On 4/18/13, gedaiu szabobog...@yahoo.com wrote:
i've done that but i get this error:
Error: function base.Value.Value.toString cannot override a
non-virtual function
Error: function base.Value.Value.toString override only
applies
to class member functions
If it's a struct then don't put override.
Just to provide a bit more info:
Classes all derive from Object, which defines toString. Hence,
you need to override it to define your own.
Structs don't have a parent (or any inheritance at all) and
hence you don't override anything, you just define the method.
i'm realy sorry... it's my mistake...
i have a struct not an object. I have someting like this when i
get the error:
struct Value {
string strVal;
this(string val) {
strVal = val;
}
override string toString() {
return strVal;
}
}
Re: writeln an object
Just drop the override:
struct Value {
string strVal;
this(string val) {
strVal = val;
}
override string toString() {
return strVal;
}
}
struct Value {
string strVal;
this(string val) {
strVal = val;
}
string toString() {
return strVal;
}
}
Re: writeln an object
On Thursday, 18 April 2013 at 18:46:09 UTC, gedaiu wrote: i have a struct not an object. There's a slight nomenclature clash here: Object is the base class in D. Therefore one could say that an object is an instatiation of Object and therefore a class. However, by a wider definition of the word, a struct could also be said to be an object.
Re: writeln an object
On 04/18/2013 12:37 PM, John Colvin wrote: However, by a wider definition of the word, a struct could also be said to be an object. You are missing some words there. :) Not a struct itself, but instances of it are said to be objects. Ali
Assigning a static array
Is this supposed to be allowed:
ubyte[] a;
ubyte[16] b;
a = b;
assert(a.ptr == b.ptr);
Because if so that makes it terribly easy to do a bug like this
(as I just saw in IRC):
struct A
{
ubyte[] a;
this(ubyte c)
{
ubyte[16] b;
b[] = c;
this.a = b; // a now points at an immediately invalid
static array
}
}
Re: Assigning a static array
For reference, here was what user soos on IRC was doing that
caused him to hit this http://dpaste.dzfl.pl/08ee7b76#:
import std.digest.md;
import std.stdio;
struct Hash {
ubyte[] hash1;
ubyte[] hash2;
this (string str) {
auto md5 = new MD5Digest();
this.hash1 = md5.digest(str);
this.hash2 = digest!MD5(str);
}
};
void main() {
auto h = Hash(hello world!);
writeln(toHexString(h.hash1));
writeln(toHexString(h.hash2));
}
It's not obvious at all what the problem is.
Re: Assigning a static array
On Thursday, April 18, 2013 23:06:32 Brad Anderson wrote:
Is this supposed to be allowed:
ubyte[] a;
ubyte[16] b;
a = b;
assert(a.ptr == b.ptr);
Because if so that makes it terribly easy to do a bug like this
(as I just saw in IRC):
struct A
{
ubyte[] a;
this(ubyte c)
{
ubyte[16] b;
b[] = c;
this.a = b; // a now points at an immediately invalid
static array
}
}
Yes, that's legal, though it should arguably be @system, since it's doing
essentially the same thing as
int i;
int* p = i;
which _is_ @system. The compiler doesn't currently consider slicing a static
array in general to be @system though, much as it should (
http://d.puremagic.com/issues/show_bug.cgi?id=8838 ). I could see an argument
that it should have to be
a = b[];
so that the slicing is explicit instead of just
a = b;
where it's implicit, but AFAIK, that's not currently required. You have to be
very careful when slicing static arrays. If it were up to me, exlicit slicing
would _always_ be required when slicing a static array, even when calling
functions which take a dynamic array, but that's not how it works
unfortunately.
- Jonathan M Davis
Re: Assigning a static array
On 04/18/2013 02:06 PM, Brad Anderson wrote:
Is this supposed to be allowed:
ubyte[] a;
ubyte[16] b;
a = b;
assert(a.ptr == b.ptr);
Because if so that makes it terribly easy to do a bug like this (as I
just saw in IRC):
struct A
{
ubyte[] a;
this(ubyte c)
{
ubyte[16] b;
b[] = c;
this.a = b; // a now points at an immediately invalid static
array
}
}
There is a similar problem with the automatically generated array arguments.
The following constructor takes any number of ints that come in array form:
import std.stdio;
struct S
{
int[] a;
this(int[] args...)
{
a = args;
}
void foo()
{
writeln(a);
}
}
void main()
{
S[] a;
foreach (i; 0 .. 2) {
a ~= S(i, i, i); // -- WARNING temporary array
}
foreach (e; a) {
e.foo();
}
}
The program prints the following because the temporary arrays that are
generated when calling the constructors are long gone:
[1, 1, 1]
[1, 1, 1]
The programmer *may have* ;) expected the following output:
[1, 1, 1]
[2, 2, 2]
Ali
Re: Assigning a static array
Brad Anderson:
Is this supposed to be allowed:
ubyte[] a;
ubyte[16] b;
a = b;
assert(a.ptr == b.ptr);
Yes, this is supposed to be allowed with the current design of D.
But with the latest dmd 2.063alpha that code doesn't work, see
below.
The Rust language removes this source of bugs because it manages
accurately the memory zones. D will probably improve its error
detection capabilities for such simple cases, but I think it will
not solve this problem in general, unless it improves its type
system, similarly to Rust.
import std.digest.md;
import std.stdio;
struct Hash {
ubyte[] hash1;
ubyte[] hash2;
this (string str) {
auto md5 = new MD5Digest();
this.hash1 = md5.digest(str);
this.hash2 = digest!MD5(str);
}
};
void main() {
auto h = Hash(hello world!);
writeln(toHexString(h.hash1));
writeln(toHexString(h.hash2));
}
It's not obvious at all what the problem is.
Now that code gives a warning:
temp.d(11): Warning: explicit slice assignment this.hash2 =
(digest(str))[] is better than this.hash2 = digest(str)
(This is the result of a small battle I have started years ago
that is now half work, thanks to the work of Hara implementing my
enhancement request. I am glad to see our time was not wasted.)
To remove that warning you have to write:
this.hash1 = md5.digest(str);
this.hash2 = digest!MD5(str)[];
Now it's visible that for hash2 you are slicing something that's
probably a fixed-sized array. This gives you a significant help
in understanding what's going on.
Bye,
bearophile
Re: Assigning a static array
Jonathan M Davis:
I could see an argument that it should have to be
a = b[];
so that the slicing is explicit instead of just
a = b;
where it's implicit, but AFAIK, that's not currently required.
It's currently a warning, and it will be required.
--
Ali Çehreli:
There is a similar problem with the automatically generated
array arguments.
The following constructor takes any number of ints that come in
array form:
import std.stdio;
struct S
{
int[] a;
this(int[] args...)
{
a = args;
}
void foo()
{
writeln(a);
}
}
void main()
{
S[] a;
foreach (i; 0 .. 2) {
a ~= S(i, i, i); // -- WARNING temporary array
This is a known problem, I have put it in Bugzilla since lot of
time and it seems there are various persons that agree with me
and you on it. So hopefully this source of bugs will be removed,
allocating that data on the heap.
Bye,
bearophile
Re: Assigning a static array
On Thursday, 18 April 2013 at 21:45:56 UTC, bearophile wrote: Yes, this is supposed to be allowed with the current design of D. But with the latest dmd 2.063alpha that code doesn't work, see below. [snip] Now that code gives a warning: temp.d(11): Warning: explicit slice assignment this.hash2 = (digest(str))[] is better than this.hash2 = digest(str) (This is the result of a small battle I have started years ago that is now half work, thanks to the work of Hara implementing my enhancement request. I am glad to see our time was not wasted.) To remove that warning you have to write: this.hash1 = md5.digest(str); this.hash2 = digest!MD5(str)[]; Now it's visible that for hash2 you are slicing something that's probably a fixed-sized array. This gives you a significant help in understanding what's going on. That's good to hear, Bearophile. Thanks Kenji.
Re: Assigning a static array
There is a similar problem with the automatically generated array
arguments.
The following constructor takes any number of ints that come in array
form:
import std.stdio;
struct S
{
int[] a;
this(int[] args...)
{
a = args;
}
void foo()
{
writeln(a);
}
}
void main()
{
S[] a;
foreach (i; 0 .. 2) {
a ~= S(i, i, i); // -- WARNING temporary array
}
foreach (e; a) {
e.foo();
}
}
The program prints the following because the temporary arrays that are
generated when calling the constructors are long gone:
[1, 1, 1]
[1, 1, 1]
The programmer *may have* ;) expected the following output:
[1, 1, 1]
[2, 2, 2]
There is no guarantee that the incoming array from a variadic function is
heap-based.
But an interesting way to deal with it is that you can overload with an
explicit slice parameter, and the variadic version will ONLY bind to a
variadic call.
For example, in dcollections' ArrayList I have two constructors:
/**
* Create an array list based on a number of elements.
*/
this(V[] elems...)
{
_array = elems.dup;
}
/**
* Use an array as the backing storage. This does not duplicate the
* array. Use new ArrayList(storage.dup) to make a distinct copy.
Beware
* of using a stack-based array when using this constructor!
*/
this(V[] storage)
{
_array = storage;
}
The first version binds only to cases where the parameter is not
*explicitly* a slice, so I am guaranteed that the array is allocated on
the stack! The second binds to slices, and I assume from my comment,
fixed-sized arrays (been a while since I looked at that code).
And the correct expectation for your code should be:
[0, 0, 0]
[1, 1, 1]
:)
-Steve
Re: Assigning a static array
Steven Schveighoffer:
There is no guarantee that the incoming array from a variadic
function is heap-based.
But an interesting way to deal with it is that you can overload
with an explicit slice parameter, and the variadic version will
ONLY bind to a variadic call.
For example, in dcollections' ArrayList I have two constructors:
/**
* Create an array list based on a number of elements.
*/
this(V[] elems...)
{
_array = elems.dup;
}
/**
* Use an array as the backing storage. This does not
duplicate the
* array. Use new ArrayList(storage.dup) to make a
distinct copy. Beware
* of using a stack-based array when using this constructor!
*/
this(V[] storage)
{
_array = storage;
}
To avoid those bugs I have suggested the simpler possible thing:
(V[] elems...) to dup the data on the heap every time. In theory
if you write (scope V[] elems...) it will be free to not dup
the data, avoiding the heap allocation and the associated little
performance loss. In practice as you know scope is not yet
implemented. D2 language is not close to being fully implemented.
Bye,
bearophile
Re: Assigning a static array
On 04/18/2013 02:54 PM, Steven Schveighoffer wrote:
The program prints the following because the temporary arrays that are
generated when calling the constructors are long gone:
[1, 1, 1]
[1, 1, 1]
The programmer *may have* ;) expected the following output:
[1, 1, 1]
[2, 2, 2]
There is no guarantee that the incoming array from a variadic function
is heap-based.
But an interesting way to deal with it is that you can overload with an
explicit slice parameter, and the variadic version will ONLY bind to a
variadic call.
Interesting.
Personally, I would not even bother with the second one and expect the
caller to simply put square brackets around the arguments:
import std.stdio;
struct S
{
int[] a;
this(int[] args) // -- now requires a slice
{
a = args;
}
void foo()
{
writeln(a);
}
}
void main()
{
S[] a;
foreach (i; 0 .. 2) {
a ~= S([i, i, i]); // -- minor inconvenience
}
foreach (e; a) {
e.foo();
}
}
It is now safe, right?
And the correct expectation for your code should be:
[0, 0, 0]
[1, 1, 1]
:)
-Steve
Wow! I made an off-by-6 error there. :)
Ali
Re: Assigning a static array
On Thu, Apr 18, 2013 at 02:43:54PM -0700, Ali Çehreli wrote:
On 04/18/2013 02:06 PM, Brad Anderson wrote:
Is this supposed to be allowed:
ubyte[] a;
ubyte[16] b;
a = b;
assert(a.ptr == b.ptr);
Because if so that makes it terribly easy to do a bug like this (as I
just saw in IRC):
struct A
{
ubyte[] a;
this(ubyte c)
{
ubyte[16] b;
b[] = c;
this.a = b; // a now points at an immediately invalid static
array
}
}
There is a similar problem with the automatically generated array arguments.
The following constructor takes any number of ints that come in array form:
import std.stdio;
struct S
{
int[] a;
this(int[] args...)
{
a = args;
}
void foo()
{
writeln(a);
}
}
[...]
Yeah I got bitten by this before. Took me several days to find the
problem, 'cos it was nested deep inside a complex data structure, and at
a glance it doesn't *look* wrong.
I'm all for making this @system at the very least, if not outright
compile error. Storing a persistent reference to a stack-allocated
object is outright wrong... in the case of variadic array args, if the
compiler can't prove that args will *always* be a dynamic array, then
any attempt to save a reference to it should be rejected outright IMO.
T
--
It is impossible to make anything foolproof because fools are so ingenious. --
Sammy
Re: refuses to open file
Let's start over it has nothing to due with the file. It's the file name
thats the problem. I wote a short test program to demenstrate the problem.
It shows that if the file name has a path it causes the exception. i.e:
(prompt)dir
Volume in drive C is OS
Volume Serial Number is E221-AB60
Directory of c:\d\projects\equipment
04/18/2013 03:57 PM 1,070 test.d
1 File(s) 1,070 bytes
0 Dir(s) 899,752,787,968 bytes free
(prompt)test 2000 c:\d\projects\equipment\test.d
args.length = 3
out of switch
Type is 2000 case 2
std.exception.ErrnoException@std\stdio.d(289): Cannot open file
`c:\d\projects\eqipment\test.d' in mode `rb' (No such file or directory)
0x0041A83C
0x0041A6C7
0x0040F577
0x0040B240
0x0040B27A
0x0040AE9C
0x00421F3D
0x752E33AA in BaseThreadInitThunk
0x770C9EF2 in RtlInitializeExceptionChain
0x770C9EC5 in RtlInitializeExceptionChain
(prompt)test 2000 test.d
out of switch
args.length = 3
out of switch
Type is 2000 case 2
out of switch
args[2] = [test.d]
efile name is File(1F81FE0) case 3
out of switch
out of for
Command line was: [test, 2000, test.d]
File is open
test.d follows:
/* Test program
To test file opening problem
*/
import std.stdio, std.string, std.conv;
void main (string[] args)
{
auto fname = l:\\filepro\\mvammach\\key;
File efile;
int type;
writeln(args.length = , args.length);
if (args.length = 3){
for (int n=1; n = args.length; n++){
switch (n){
case 1:
break;
case 2:
type = to!int( args[1] );
writefln(Type is %s case 2, type);
break;
case 3:
efile = File(args[2]);
writefln(args[2] = [%s], args[2]);
writefln(efile name is %s case 3, efile);
break;
default:
break;
} // end switch
writeln(out of switch);
} // end for
writeln(out of for);
} // end if
else {
efile = File(fname,r);
writefln(fname = [%s] in else, fname);
writefln(efile = [%s], efile);
} // end else
writeln(Command line was: , args[]);
if(efile.isOpen()) writeln (File is open);
} // end main
Re: A little of coordination for Rosettacode
Maybe there is a way to translate this Haskell version to D with bigints: http://rosettacode.org/wiki/Find_largest_left_truncatable_prime_in_a_given_base#Haskell Unrelated: now I have a kind of efficient longest common subsequence algorithm with O(n) memory usage. Maybe there is some interest for it in Phobos. Bye, bearophile
Re: refuses to open file
On 04/18/2013 04:25 PM, rbt...@digitalpath.net wrote: Let's start over it has nothing to due with the file. It's the file name thats the problem. Let's start with the obvious. :) Directory of c:\d\projects\equipment std.exception.ErrnoException@std\stdio.d(289): Cannot open file `c:\d\projects\eqipment\test.d' in mode `rb' (No such file or directory) There is a typo in that path. Ali
Re: Copying reference types by value
On 04/18/2013 06:22 AM, Joseph Rushton Wakeling wrote: On 04/17/2013
10:29 PM, Ali Çehreli wrote:
Yes but as I said I am not sure how useful or needed this whole
thing is.
The language handles copy, move, and assignment for structs.
takeOver() seems to
be a primitive operation for classes.
Could you expand a bit on that? Just that I'm not sure I understand your
meaning completely, and I'm curious. :-)
Being value types, structs enjoy automatic handling of copy, assignment,
and in the case of rvalues, move.
struct S
{
int i;
}
S makeS()
{
return S();
}
void main()
{
auto a = S();
auto b = a;// a is copied to b
b = a; // a is assigned to b
b = makeS(); // the returned rvalue is 'moved' to b
}
Of course that works only for structs with simple value members. When
the automatic handling is not sufficient or does the wrong thing, then
the programmer must provide this(this), opAssign(), or ~this(). Things
get more interesting when the members are mutable or immutable references.
With the above definition of S, all of the following compile:
immutable(S) imm0;
S mut = imm0;// immutable to mutable
immutable(S) imm1 = mut; // mutable to immutable
immutable(S) imm2 = imm0; // immutable to immutable
Now naively add another member to S:
struct S
{
int i;
int[] arr; // -- added
}
Only the latter of the three assignments compile:
immutable(S) imm0;
S mut = imm0; // compilation ERROR
immutable(S) imm1 = mut; // compilation ERROR
immutable(S) imm2 = imm0; // compiles
Anyway... I am trying to wrap up what I have learned so far before going
any further. :)
For classes, none of these operations make sense: There is no automatic
copying, no automatic assignment, nor there are rvalues to move.
I'd assumed this problem would be some fairly straightforward aspect
of the
language that I just wasn't familiar with, so I'm quite struck by the
fact that
it actually seems a non-trivial problem.
My experience has been with C++ so I don't know how this is solved in
Java or C#. Maybe this is not a problem with the common idioms in those
languages, which would also mean that this is not a problem with D
classes. Rather, if one has decided to go with a class, then value
semantics were not a consideration to begin with.
Ali
[Issue 5212] no escape analysis for typesafe variadic function arguments
http://d.puremagic.com/issues/show_bug.cgi?id=5212 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||c...@dawg.eu Summary|Safer typesafe variadics|no escape analysis for ||typesafe variadic function ||arguments --- Comment #11 from Martin Nowak c...@dawg.eu 2013-04-17 22:59:40 PDT --- Without escape analysis these functions are not memory @safe. Maybe we should think about this in conjunction with scope ref, http://wiki.dlang.org/DIP36#.40safe_concerns. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9907] Struct literal with destructor should match to non-ref overload
http://d.puremagic.com/issues/show_bug.cgi?id=9907 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9953] New: manifest constants of reference types should be illegal
http://d.puremagic.com/issues/show_bug.cgi?id=9953
Summary: manifest constants of reference types should be
illegal
Product: D
Version: D1 D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don clugd...@yahoo.com.au 2013-04-18 01:43:43 PDT ---
---
enum X = [1,2,3];
void main()
{
assert( X.ptr is X.ptr);
assert( X is X );
}
---
Both asserts fail at runtime, because they are equivalent to
assert( [1,2,3].ptr is [1,2,3].ptr);
assert( [1,2,3] is [1,2,3] );
It would be OK for X to be an int[3] array, but not a slice.
Fundamentally, a reference enum type doesn't make sense. They can't have an
address.
This is the root cause of bug 4397.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4397] const/CTFE does not work
http://d.puremagic.com/issues/show_bug.cgi?id=4397 Don clugd...@yahoo.com.au changed: What|Removed |Added Depends on||9953 --- Comment #16 from Don clugd...@yahoo.com.au 2013-04-18 01:54:50 PDT --- There is no compiler bug here, it is working as designed, at least for D2. However, the design doesn't make sense. I have opened bug 9953 for the design change. It would be possible to give the desired behaviour in D1, though it's hardly worthwhile. In D2 I think it is a logical impossibility. IMHO this should just fail to compile. You should write static const instead of enum when you want to declare a constant of a reference type. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9953] manifest constants of reference types should be illegal
http://d.puremagic.com/issues/show_bug.cgi?id=9953 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc 2013-04-18 02:43:05 PDT --- This bug report seems for associative arrays too, then. This bug report is about an old and significant problem of D. Disallowing all enum reference types seems a little harsh, but I don't know if there are better solutions. One problem with this proposal is that there is probably some D code around that uses enum dynamic arrays and associative arrays (I have stopped using them in my code since some time), and this proposal will break that code. One advantage of disallowing enum dynamic arrays is that this avoids a performance trap, because they get rebuild at every usage point, and this in the middle of a loop is a waste of time. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9937] CTFE floats don't overflow correctly
http://d.puremagic.com/issues/show_bug.cgi?id=9937 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #2 from Don clugd...@yahoo.com.au 2013-04-18 03:32:03 PDT --- In D, any floating point algorithm that relies on a maximum precision is broken. The compiler and runtime is allowed to do all such calculations at as high a precision as they want to - the types only specify a minimum precision, not a maximum. That's not exactly true. It's true that the intermediate results may be at extended precision, for example, it would not be true that float x = float.max; assert( (x * 2) / 2 == float.infinity); // may fail But float and double must be IEEE types. Without this, it's impossible to write correct floating-point code. The big problem here is that the CTFE behaviour is different to the runtime behaviour. I hit this with HalfFloat, I can't implement it correctly because of this issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9954] New: Runtime wrong code with global interface var created in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=9954
Summary: Runtime wrong code with global interface var created
in CTFE
Product: D
Version: D1 D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don clugd...@yahoo.com.au 2013-04-18 04:06:16 PDT ---
interface ITest105a {
string test105a() const;
}
class Test105a: ITest105a {
string test105a() const {return test105a;}
}
interface ITest105b {
string test105b() const;
}
class Test105b: Test105a, ITest105b {
string test105b() const {return test105b;}
}
ITest105a makeit() {
return new Test105b;
}
const ITest105a t105ia = makeit();
void main() {
assert(t105ia.test105a() == test105a);
}
---
The bug is that t105ia is being created pointing to the Test105a part, instead
of pointing to Test105b.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9954] Runtime wrong code with global interface var created in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=9954 Don clugd...@yahoo.com.au changed: What|Removed |Added Keywords||CTFE, wrong-code Severity|normal |critical -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9955] New: std.math.feqrel for numbers close to zero
http://d.puremagic.com/issues/show_bug.cgi?id=9955
Summary: std.math.feqrel for numbers close to zero
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2013-04-18 04:46:11 PDT ---
I think feqrel is not working well when numbers are close to 0.0:
import std.stdio: writeln;
import std.math: feqrel;
void main() {
feqrel(1.001, 1.0).writeln;
feqrel(1.001, 1.0).writeln;
feqrel(1.1, 1.0).writeln;
feqrel(0.001, 0.0).writeln;
feqrel(0.001, 0.0).writeln;
feqrel(0.1, 0.0).writeln;
}
Prints, dmd 2.063alpha:
50
37
4
0
0
0
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9949] template initialization when alias cannot be read at compile time
http://d.puremagic.com/issues/show_bug.cgi?id=9949
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-04-18
05:23:37 PDT ---
(In reply to comment #0)
The following code compiles aldo s is not readable at compile time:
struct S (alias T) {
typeof(T) value;
}
void main () {
auto s = some;
s ~= string;
S!s value;
}
That code isn't reading 's', it is only using it to get its type. And all types
are known at compile-time. The code is ok.
The side effect of this is the following error:
// Error: function literal __lambda3 (S!(s) a) is not
// callable using argument types (S!(s))
module program;
import std.stdio;
struct S (alias T) {
typeof(T) value;
}
void f (alias l = x = 1) (string s) {
l(S!(s).init);
}
void main () {
auto s = some;
s ~= string;
f!((S!s a) { return 1; })(s);
}
It doesn't compile because 's' within 'main' and 's' within 'f' are two
different variables. You'd have to pass 's' from within main as an alias
parameter to 'f'. E.g.:
import std.stdio;
struct S(alias T)
{
typeof(T) value;
}
void f(alias lambda = x = 1, alias str)()
{
lambda(S!str.init);
}
void main()
{
string str = some;
f!((S!str a) { return 1; }, str)();
}
But I'd recommend changing the struct S definition to take a type and use
typeof() at the call site to avoid having to use aliases everywhere.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9956] New: hasElaborateAssign trait does not work with static arrays
http://d.puremagic.com/issues/show_bug.cgi?id=9956
Summary: hasElaborateAssign trait does not work with static
arrays
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: pull
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-04-18
05:30:59 PDT ---
hasElaborateDestructor works with static arrays, but not hasElaborateAssign:
import std.traits;
void main()
{
static struct S { void opAssign(S) {} }
static struct S3 { S s; }
static assert(hasElaborateAssign!(S[1])); // fails
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9956] hasElaborateAssign trait does not work with static arrays
http://d.puremagic.com/issues/show_bug.cgi?id=9956 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-04-18 05:31:06 PDT --- https://github.com/D-Programming-Language/phobos/pull/954 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9955] std.math.feqrel for numbers close to zero
http://d.puremagic.com/issues/show_bug.cgi?id=9955 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Don clugd...@yahoo.com.au 2013-04-18 06:11:07 PDT --- No, it's correct. They have no equal bits. What you have is something like this: 0.001 0.0 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9949] template initialization when alias cannot be read at compile time
http://d.puremagic.com/issues/show_bug.cgi?id=9949
--- Comment #2 from luka8088 luka8...@owave.net 2013-04-18 07:03:26 PDT ---
(In reply to comment #1)
(In reply to comment #0)
The following code compiles aldo s is not readable at compile time:
struct S (alias T) {
typeof(T) value;
}
void main () {
auto s = some;
s ~= string;
S!s value;
}
That code isn't reading 's', it is only using it to get its type. And all
types
are known at compile-time. The code is ok.
Oh, I see, value can be used in runtime but compile time is only using it's
type:
import std.stdio;
struct S (alias T) {
typeof(T) value;
void print () { writeln(T); }
}
void main () {
auto s = some;
s ~= string;
S!s value;
value.print();
}
The side effect of this is the following error:
// Error: function literal __lambda3 (S!(s) a) is not
// callable using argument types (S!(s))
module program;
import std.stdio;
struct S (alias T) {
typeof(T) value;
}
void f (alias l = x = 1) (string s) {
l(S!(s).init);
}
void main () {
auto s = some;
s ~= string;
f!((S!s a) { return 1; })(s);
}
It doesn't compile because 's' within 'main' and 's' within 'f' are two
different variables. You'd have to pass 's' from within main as an alias
parameter to 'f'. E.g.:
I agree, but shouldn't in that case 's' in error message be fully qualified? Or
distinguishable in some way?
import std.stdio;
struct S(alias T)
{
typeof(T) value;
}
void f(alias lambda = x = 1, alias str)()
{
lambda(S!str.init);
}
void main()
{
string str = some;
f!((S!str a) { return 1; }, str)();
}
But I'd recommend changing the struct S definition to take a type and use
typeof() at the call site to avoid having to use aliases everywhere.
I wanted to only take a type without using typeof() so I wrote:
template S(alias T) if (!is(T)) {
alias S = S!(typeof(T));
}
struct S (T) {
// ...
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9953] manifest constants of reference types should be illegal
http://d.puremagic.com/issues/show_bug.cgi?id=9953 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-04-18 07:15:52 PDT --- If we're going to do this we might as well introduce it in 2.063, since this release will have breaking changes related to this. For example const/immutable fields with initializers will no longer be implicitly static, and people might end up changing them to manifest constants. If they were l-value initializers it's going to cause further problems when this issue is implemented (hence why it should be done sooner rather than later to avoid fixing code two times). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9957] New: [2.061 - 2.062] Taking pointer of enum float array gives some garbage
http://d.puremagic.com/issues/show_bug.cgi?id=9957
Summary: [2.061 - 2.062] Taking pointer of enum float array
gives some garbage
Product: D
Version: D2
Platform: All
OS/Version: Mac OS X
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: st...@kraybit.com
--- Comment #0 from st...@kraybit.com 2013-04-18 08:09:28 PDT ---
import std.stdio;
void main()
{
enum float[3][1] A = [[1.0, 2.0, 3.0]];
auto a = A[0].ptr;
writeln(a[0], should be , A[0][0]);
writeln(a[1], should be , A[0][1]);
writeln(a[2], should be , A[0][2]);
}
rdmd -m32 test.d
1 should be 1
1.76941e-40 should be 2
-1.98565 should be 3
rdmd -m64 test.d
1 should be 1
1.4013e-45 should be 2
4.33594e+15 should be 3
_
Example output above. Changes every run.
Worked in 2.061. Don't know if it's supposed to work, but if not, should at
least throw an error?
MacOS 10.8.3
DMD 2.062
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9958] New: Integer FloatSuffix is not a valid FloatLiteral
http://d.puremagic.com/issues/show_bug.cgi?id=9958 Summary: Integer FloatSuffix is not a valid FloatLiteral Product: D Version: D2 Platform: All URL: http://dlang.org/lex.html#floatliteral OS/Version: All Status: NEW Keywords: spec Severity: trivial Priority: P2 Component: websites AssignedTo: nob...@puremagic.com ReportedBy: thecybersha...@gmail.com --- Comment #0 from Vladimir Panteleev thecybersha...@gmail.com 2013-04-18 19:00:07 EEST --- The spec for floating point literals seems to indicate that the syntax 5f is not a valid floating point literal, however it is accepted by the compiler. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9959] New: Add functional pattern matching for object references
http://d.puremagic.com/issues/show_bug.cgi?id=9959
Summary: Add functional pattern matching for object references
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: pull
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: generic...@gmail.com
--- Comment #0 from IdanArye generic...@gmail.com 2013-04-18 09:56:20 PDT ---
Polymorphism is usually the way to write code that handles objects of different
types, bit it is not always possible or desirable. When the code that uses the
objects is required to treat objects differently based on class, the D way is
using castassign inside `if`:
if (auto a = cast(A) obj)
{
...
}
else if (auto b = cast(B) obj)
{
...
}
This is not always convenient for two reasons:
* You need to write `obj` in every `if` statement. If `obj` is a more complex
expression(like the return value of a function) you'll need to store it in an
variable beforehand. This is not that cumbersome but still worth mentioning.
* An `if` statement is a statement - which means it does not return a value -
and creates it's own scope - which means you variables declared in it are not
accessible outside. Those two constraints mean that if you need to compute a
value differently based on the object's class and use that value after the
`if`s, you need to declare the variable before the `if` - and that means you
can't make it `const`.
My solution is the function `std.algorithm.castSwitch`, which is based on
Scala's
approach(http://ofps.oreilly.com/titles/9780596155957/RoundingOutTheEssentials.html#MatchingOnType).
It is used like this:
obj.castSwitch!(
(A a) = ...,
(B b) = ...,
)()
It answers both mentioned problems, plus it is more compact readable.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9959] Add functional pattern matching for object references
http://d.puremagic.com/issues/show_bug.cgi?id=9959 IdanArye generic...@gmail.com changed: What|Removed |Added URL||https://github.com/D-Progra ||mming-Language/phobos/pull/ ||1266 --- Comment #1 from IdanArye generic...@gmail.com 2013-04-18 10:00:51 PDT --- See https://github.com/D-Programming-Language/phobos/pull/1266 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9949] template initialization when alias cannot be read at compile time
http://d.puremagic.com/issues/show_bug.cgi?id=9949 --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-04-18 10:35:19 PDT --- (In reply to comment #2) I agree, but shouldn't in that case 's' in error message be fully qualified? Or distinguishable in some way? Yep. This is covered by Issue 9631, but you can add your test-case there so it isn't missed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7790] [CTFE] assignment to AA apply ref argument
http://d.puremagic.com/issues/show_bug.cgi?id=7790 --- Comment #3 from github-bugzi...@puremagic.com 2013-04-18 11:22:58 PDT --- Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/c42dcec4f053ffa65feb278d09efb701fabc6fa0 Fix issue 7790 [CTFE] assignment to AA apply ref argument 1. IndexExp: Stop copying the AA whenever it is indexed (This was horrific for performance, as well as being wrong). 2. aaApply: If the value is 'ref', create a reference to the value. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9338] Compiler segfaults if try to CTFE member function without valid 'this'
http://d.puremagic.com/issues/show_bug.cgi?id=9338 --- Comment #6 from github-bugzi...@puremagic.com 2013-04-18 11:23:09 PDT --- Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/c3a9411507a9971c9471e29ca1898bab73f71352 fix Issue 9338 - Compiler segfaults if try to CTFE member function without valid 'this' -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
