Re: extern(C) with function returning user type
On Friday, 31 July 2015 at 21:35:30 UTC, Kyoji Klyden wrote: On Friday, 31 July 2015 at 19:13:18 UTC, Laeeth Isharc wrote: On Friday, 31 July 2015 at 17:14:29 UTC, Kyoji Klyden wrote: On Friday, 31 July 2015 at 16:09:23 UTC, bachmeier wrote: On Friday, 31 July 2015 at 03:30:20 UTC, Kyoji Klyden wrote: So idk, it feels silly and counterproductive to have D not able to natively use C libraries. Are we just gonna have to write D bindings to every notable library out there? Also I don't see how it'd be problematic, if you don't want a C preprocessor kicking in, then just don't import any C source, and then the compiler will just skip that step. :P That's how you end up with C++. The solution there is to use only a subset of the language, but since everyone has her own subset, you can either learn the whole language or not interact with anyone else's code. A tool-based solution is much better. It's a fair argument. Regardless though, I feel like D has lost it practicality for me for the time being. I might come back to it in half a year and see if anything changes, but unfortunately I don't see myself using D for any of my projects I got lined up. You have to make the right decision for you. But from what you say, I am not sure if you are making it on the basis of proper information about the tradeoffs involved. It shouldn't be a difficult thing to port the headers for most C libraries. Use dstep to do the work, and a bit of tidying up after (which gets easier each time). Less time involved than that involved in trying to fix just one nasty memory leak or pointer problem in C code. Sometimes though, cashflow dominates return on investment. If one cannot spare the time then, ROI on learning something new is irrelevant. One can't do much about that in the short term. I definitely agree with you there. I'm sure dstep could work quite well, but at the same time, for what I'm doing, there's nothing in D I couldn't do in C, and C's the one with the libraries + the endless supply of documentation. There really isn't any reward for that extra percent of time/effort spent when using D right now. I still think D is rad, and will probably use it again sometime :) Walter observes that if you are a Java programmer and start writing D, you will write D like you write Java. And so I suppose one will see what one doesn't have in Java, but not so much the benefits of D. That's true of other languages too. When one learns something new, one is often initially worse off as a result, because it destabilises ones habits before one sees how to apply ones new knowledge. So those benefits only come with persistence and the passage of time. Language familiarity can also be deceptive - D adds nothing really new say the Reddit guys. But as a C guy who never got into C++, it makes a huge difference. Just not obviously so in the beginning. One thing that's great is to be able to come back to my own code after a break when it was written in a hurry and without too many comments and tie be able to understand it immediately. That wasn't my experience with C, but I suppose it depends how much discipline you have. (Also, once it compiles, the bugs are usually obvious enough and simple to fix - stronger typing has benefits). The main advantage I have found is that one can deploy limited energy to achieve more, because one doesn't get as bogged down, and because the work is more pleasant and satisfying. Which libraries do you miss, out of interest?
Re: Weird error after moving code from Linux to Windows
On 7/31/15 11:34 AM, Hamburger-san wrote:
I was expecting something to break, but I thought it'd be more along the
lines of file paths...
For whatever reason, my compiler really doesn't like it when I try to
access my Array!SomeStruct opIndex function. It gives me the following
Error
Error: inout method std.container.array.Array!(SomeStruct).Array.opIndex
is not callable using a mutable object
struct SomeStruct {
AppState!U state;
int id;
}
Array!(SomeStruct) states_; //can allocate to this fine
Array!(AppState!U) stack_;
void somefunction(){
stack_.reserve(4);
stack_ = make!(Array!(AppState!U));
stack_.insertBack( (states_[0].state) ); //errors
}
void someotherfunction(){
...
auto state = states_[aa]; //also errors
...
}
It compiles fine on my Linux machine and I can't figure out what I'm
doing wrong here...
Same version of compiler? Same compiler?
-Steve
Weird error after moving code from Linux to Windows
I was expecting something to break, but I thought it'd be more
along the lines of file paths...
For whatever reason, my compiler really doesn't like it when I
try to access my Array!SomeStruct opIndex function. It gives me
the following Error
Error: inout method
std.container.array.Array!(SomeStruct).Array.opIndex is not
callable using a mutable object
struct SomeStruct {
AppState!U state;
int id;
}
Array!(SomeStruct) states_; //can allocate to this fine
Array!(AppState!U) stack_;
void somefunction(){
stack_.reserve(4);
stack_ = make!(Array!(AppState!U));
stack_.insertBack( (states_[0].state) ); //errors
}
void someotherfunction(){
...
auto state = states_[aa]; //also errors
...
}
It compiles fine on my Linux machine and I can't figure out what
I'm doing wrong here...
Re: extern(C) with function returning user type
On Friday, 31 July 2015 at 03:30:20 UTC, Kyoji Klyden wrote: So idk, it feels silly and counterproductive to have D not able to natively use C libraries. Are we just gonna have to write D bindings to every notable library out there? Also I don't see how it'd be problematic, if you don't want a C preprocessor kicking in, then just don't import any C source, and then the compiler will just skip that step. :P That's how you end up with C++. The solution there is to use only a subset of the language, but since everyone has her own subset, you can either learn the whole language or not interact with anyone else's code. A tool-based solution is much better.
Re: Struct that destroys its original handle on copy-by-value
On 07/26/2015 04:29 AM, Joseph Rushton Wakeling via Digitalmars-d-learn wrote: is this design idea even feasible in principle, or just a bad idea from the get-go? As I understand it, it is against one of fundamental D principles: structs are value types where any copy can be used in place of any other. I expect there are examples where even Phobos violates it but the struct documentation still says so: A struct is defined to not have an identity; that is, the implementation is free to make bit copies of the struct as convenient. http://dlang.org/struct.html And if feasible -- how would I go about it? Disallowing automatic copying and providing a function comes to mind. Ali
Re: extern(C) with function returning user type
On Friday, 31 July 2015 at 16:09:23 UTC, bachmeier wrote: On Friday, 31 July 2015 at 03:30:20 UTC, Kyoji Klyden wrote: So idk, it feels silly and counterproductive to have D not able to natively use C libraries. Are we just gonna have to write D bindings to every notable library out there? Also I don't see how it'd be problematic, if you don't want a C preprocessor kicking in, then just don't import any C source, and then the compiler will just skip that step. :P That's how you end up with C++. The solution there is to use only a subset of the language, but since everyone has her own subset, you can either learn the whole language or not interact with anyone else's code. A tool-based solution is much better. It's a fair argument. Regardless though, I feel like D has lost it practicality for me for the time being. I might come back to it in half a year and see if anything changes, but unfortunately I don't see myself using D for any of my projects I got lined up.
Re: Weird error after moving code from Linux to Windows
On Friday, 31 July 2015 at 15:59:02 UTC, Steven Schveighoffer wrote: Same version of compiler? Same compiler? -Steve Same version of compiler? Same compiler? -Steve (just checking now on my linux) Yeah, same compiler: DMD2 They're both up to date and version: 2.067.1 Both machines are x64.
Re: Struct that destroys its original handle on copy-by-value
On 07/31/2015 11:01 AM, Dicebot wrote: On Friday, 31 July 2015 at 17:21:40 UTC, Ali Çehreli wrote: On 07/26/2015 04:29 AM, Joseph Rushton Wakeling via Digitalmars-d-learn wrote: is this design idea even feasible in principle, or just a bad idea from the get-go? As I understand it, it is against one of fundamental D principles: structs are value types where any copy can be used in place of any other. I expect there are examples where even Phobos violates it but the struct documentation still says so: A struct is defined to not have an identity; that is, the implementation is free to make bit copies of the struct as convenient. I believe this restriction should be banned. Considering classes have inherent reference + heap semantics (and you can only bail out of that with hacks) saying struct can't be anything but data bags makes impossible to implement whole class of useful designs. The fact that Phobos has to violate it itself to get stuff done is quite telling. To make sure, I didn't mean that I know of structs in Phobos that behave that way. Although, it would be interesting to identify them. :) Ali
Re: Struct that destroys its original handle on copy-by-value
On Fri, Jul 31, 2015 at 06:01:44PM +, Dicebot via Digitalmars-d-learn wrote: On Friday, 31 July 2015 at 17:21:40 UTC, Ali Çehreli wrote: On 07/26/2015 04:29 AM, Joseph Rushton Wakeling via Digitalmars-d-learn wrote: is this design idea even feasible in principle, or just a bad idea from the get-go? As I understand it, it is against one of fundamental D principles: structs are value types where any copy can be used in place of any other. I expect there are examples where even Phobos violates it but the struct documentation still says so: A struct is defined to not have an identity; that is, the implementation is free to make bit copies of the struct as convenient. I believe this restriction should be banned. Considering classes have inherent reference + heap semantics (and you can only bail out of that with hacks) saying struct can't be anything but data bags makes impossible to implement whole class of useful designs. The fact that Phobos has to violate it itself to get stuff done is quite telling. On the other hand, though, structs that are *not* mere data bags usually get into the dark area of compiler bugs and other unexpected side-effects or unclear areas of the language, often with questionable or inconsistent behaviour. My suspicion that these problems aren't just because of compiler quality or the language spec being incomplete, but it's because they are caused by this underlying dichotomy between structs being defined to be purely data, and structs being used for things that are more than just pure data. One example of this is how long it took for std.stdio.File to get to its present form. It started out as a simple wrapper around the C library FILE*, passed through stages of being pure data yet showing buggy corner cases, then stepping into dtor territory with its associated unexpected behaviours, then now into a wrapper around a ref-counted type (and IIRC, it may still show buggy / odd behaviour when you stick it inside a container like an array). Along the way, we had issues with dtors, postblit, and a whole slew of issues, almost all of which can be traced back to the dichotomy between a struct wanting to be just a value yet at the same time wanting / needing to be more than that. It seems that what the language (originally) defines structs to be, is not entirely consistent with how it has come to be used (which also entailed later extensions to the struct definition), and this has been a source of problems. T -- Bare foot: (n.) A device for locating thumb tacks on the floor.
Re: Struct that destroys its original handle on copy-by-value
On Friday, 31 July 2015 at 18:13:04 UTC, Ali Çehreli wrote: To make sure, I didn't mean that I know of structs in Phobos that behave that way. Although, it would be interesting to identify them. :) Ali Things like Unique, Scoped, RefCounted - pretty much everything which wraps reference type with additional semantics.
Re: Struct that destroys its original handle on copy-by-value
On Friday, 31 July 2015 at 18:23:39 UTC, H. S. Teoh wrote: It seems that what the language (originally) defines structs to be, is not entirely consistent with how it has come to be used (which also entailed later extensions to the struct definition), and this has been a source of problems. Yes, and it wasn't because people started to misuse structs - it was because certain designs would be simply impossible otherwise. The very language design assumption that structs should always be dumb copyable values was not practical. It may come from times when GC, heaps and classes were considered good enough for everyone and RAII intended to be completely replaces by scope(exit). Which didn't work.
Re: Struct that destroys its original handle on copy-by-value
On 7/31/15 1:21 PM, Ali Çehreli wrote: Disallowing automatic copying and providing a function comes to mind. Isn't that what std.algorithm.move is for? -Steve
Re: extern(C) with function returning user type
On Friday, 31 July 2015 at 17:14:29 UTC, Kyoji Klyden wrote: On Friday, 31 July 2015 at 16:09:23 UTC, bachmeier wrote: On Friday, 31 July 2015 at 03:30:20 UTC, Kyoji Klyden wrote: So idk, it feels silly and counterproductive to have D not able to natively use C libraries. Are we just gonna have to write D bindings to every notable library out there? Also I don't see how it'd be problematic, if you don't want a C preprocessor kicking in, then just don't import any C source, and then the compiler will just skip that step. :P That's how you end up with C++. The solution there is to use only a subset of the language, but since everyone has her own subset, you can either learn the whole language or not interact with anyone else's code. A tool-based solution is much better. It's a fair argument. Regardless though, I feel like D has lost it practicality for me for the time being. I might come back to it in half a year and see if anything changes, but unfortunately I don't see myself using D for any of my projects I got lined up. You have to make the right decision for you. But from what you say, I am not sure if you are making it on the basis of proper information about the tradeoffs involved. It shouldn't be a difficult thing to port the headers for most C libraries. Use dstep to do the work, and a bit of tidying up after (which gets easier each time). Less time involved than that involved in trying to fix just one nasty memory leak or pointer problem in C code. Sometimes though, cashflow dominates return on investment. If one cannot spare the time then, ROI on learning something new is irrelevant. One can't do much about that in the short term.
Re: Yes or No Options
On Thursday, 30 July 2015 at 15:14:28 UTC, Chris wrote: On Thursday, 30 July 2015 at 14:20:41 UTC, Alex wrote: My father owns a small software company, specialized in market data products. www.bccgi.com (in case anyone is interested) So programming was basically around all my life. I do a small job in his company and my next task was to learn D. There are two trainees and the three of us have to learn D. Ofc the two trainees have to learn other languages as well. My dad said the reason why we learn this language is that he personally finds it to be a very intuitive language that produces machine code. If he just wanted us to teach programming he said he'd just told us to learn C#. In addition to that he wants to keep up and always have new languages and features in the company (only 8 people). And since we have experts for almost any language here but not a single one for D, it was time for someone to start! Once I started I found it to be really interesting and challenging plus I like solving problems. Thank you for being so nice! I have seen very few communities where beginners are welcomed so well! Very interesting indeed! Care to write an article about it one day? Learning D as an absolute beginner or something like that. I wonder, is your father's company listed among those using D? I think there's a list somewhere on Wiki, if not we should have one :-) Sure I'd do something like that! Maybe refering to the Ali Çehreli's book! Question is if my English skills are sufficient.. They aren't in the list because right now nothing is written in D in our company. But the future will look different I according to what my dad told me. Is there a reddit community? How is D generally seen in the internet?
Re: Struct that destroys its original handle on copy-by-value
On Friday, 31 July 2015 at 17:21:40 UTC, Ali Çehreli wrote: On 07/26/2015 04:29 AM, Joseph Rushton Wakeling via Digitalmars-d-learn wrote: is this design idea even feasible in principle, or just a bad idea from the get-go? As I understand it, it is against one of fundamental D principles: structs are value types where any copy can be used in place of any other. I expect there are examples where even Phobos violates it but the struct documentation still says so: A struct is defined to not have an identity; that is, the implementation is free to make bit copies of the struct as convenient. I believe this restriction should be banned. Considering classes have inherent reference + heap semantics (and you can only bail out of that with hacks) saying struct can't be anything but data bags makes impossible to implement whole class of useful designs. The fact that Phobos has to violate it itself to get stuff done is quite telling.
Re: Struct that destroys its original handle on copy-by-value
On 07/31/2015 12:18 PM, Steven Schveighoffer wrote: On 7/31/15 1:21 PM, Ali Çehreli wrote: Disallowing automatic copying and providing a function comes to mind. Isn't that what std.algorithm.move is for? -Steve Sounds great and I like it! :) Ali
Subclasses in std.concurrency.receive pattern match
Hi
Coming back after a (too long) break from D programming.
Using DMD 2.067.1:
# cat receive_subclass.d
import std.stdio;
import std.concurrency;
class A {}
class B : A {}
void worker () {
while (true) {
receive(
(shared B b) { writefln( Got B: %s, cast(B)b ); },
(shared A a) { writefln( Got A: %s, cast(A)a ); }
);
}
}
void main () {
shared A arg = new B;
Tid tid = spawn(worker);
send( tid, arg);
send( tid, cast(shared B)arg);
receive( (bool) {} ); // wait
}
# dmd -run receive_subclass.d
Got A: receive_subclass.B // XXX: we got B, but it was matched as A
Got B: receive_subclass.B
So patten matching only works on type of containing variable, not the type
of the object itself. Is it possible to work around this? I need to receive
objects from rather large subclass hierarchy and it would be much more
convenient for me to recognize particular subclass using receive than some
type of multiple cast check clauses.
On a related matter - how does GC behave on such class objects (created in
one thread, casted to shared and handled by another thread)? Won't the
object get possibly GC'ed when it runs out of scope in origin thread while
handler thread still uses it?
--
Marek Janukowicz
Re: Subclasses in std.concurrency.receive pattern match
On Friday, 31 July 2015 at 07:35:47 UTC, Marek Janukowicz wrote: So patten matching only works on type of containing variable, not the type of the object itself. Is it possible to work around this? No, it would be very surprising if receive performed a dynamic downcast, and it's also somewhat expensive. If you want that, do the downcast in your handler yourself. Won't the object get possibly GC'ed when it runs out of scope in origin thread while handler thread still uses it? No, the GC pauses and scans all threads for roots.
Re: Struct that destroys its original handle on copy-by-value
On Sunday, 26 July 2015 at 12:16:30 UTC, Joseph Rushton Wakeling wrote: Example: Unique!Random rng = new Random(unpredictableSeed); rng.take(10).writeln; My aim by contrast is to _allow_ that kind of use, but render the original handle empty when it's done. `take` stores the range, you can try to use some sort of a weak reference.
Re: extern(C) with function returning user type
On Friday, 31 July 2015 at 19:13:18 UTC, Laeeth Isharc wrote: On Friday, 31 July 2015 at 17:14:29 UTC, Kyoji Klyden wrote: On Friday, 31 July 2015 at 16:09:23 UTC, bachmeier wrote: On Friday, 31 July 2015 at 03:30:20 UTC, Kyoji Klyden wrote: So idk, it feels silly and counterproductive to have D not able to natively use C libraries. Are we just gonna have to write D bindings to every notable library out there? Also I don't see how it'd be problematic, if you don't want a C preprocessor kicking in, then just don't import any C source, and then the compiler will just skip that step. :P That's how you end up with C++. The solution there is to use only a subset of the language, but since everyone has her own subset, you can either learn the whole language or not interact with anyone else's code. A tool-based solution is much better. It's a fair argument. Regardless though, I feel like D has lost it practicality for me for the time being. I might come back to it in half a year and see if anything changes, but unfortunately I don't see myself using D for any of my projects I got lined up. You have to make the right decision for you. But from what you say, I am not sure if you are making it on the basis of proper information about the tradeoffs involved. It shouldn't be a difficult thing to port the headers for most C libraries. Use dstep to do the work, and a bit of tidying up after (which gets easier each time). Less time involved than that involved in trying to fix just one nasty memory leak or pointer problem in C code. Sometimes though, cashflow dominates return on investment. If one cannot spare the time then, ROI on learning something new is irrelevant. One can't do much about that in the short term. I definitely agree with you there. I'm sure dstep could work quite well, but at the same time, for what I'm doing, there's nothing in D I couldn't do in C, and C's the one with the libraries + the endless supply of documentation. There really isn't any reward for that extra percent of time/effort spent when using D right now. I still think D is rad, and will probably use it again sometime :)
Re: Yes or No Options
On Thursday, 30 July 2015 at 17:48:51 UTC, Ali Çehreli wrote: On 07/30/2015 08:14 AM, Chris wrote: I wonder, is your father's company listed among those using D? I think there's a list somewhere on Wiki, if not we should have one :-) I don't think they use D yet but the page is here: http://wiki.dlang.org/Current_D_Use Ali That's the link. Thanks! I find the reasons Alex gave for using D very interesting. It's beyond all hype and reddit and stuff like that. It shows that D attracts users for what it is, without any hype or sh*t like that.
alias overloading strange error
//Why expression 'foobar(1);' doesn't work?
void foo()(){}
void bar(int){}
alias foobar = foo;
alias foobar = bar;
void main(){
.foobar(1); //OK
foobar(1); //Error: overload alias 'foo' is not a variable
}
Re: alias overloading strange error
On Friday, 31 July 2015 at 10:56:33 UTC, vitus wrote:
//Why expression 'foobar(1);' doesn't work?
void foo()(){}
void bar(int){}
alias foobar = foo;
alias foobar = bar;
void main(){
.foobar(1); //OK
foobar(1); //Error: overload alias 'foo' is not a variable
}
foo is a template, while bar is a function. I would have thought
the `.foobar(1)` should have failed too... Must be some strange
lookup rules I don't know about (or a dmd bug).
`alias foobar = foo!();` should make it work in both cases though.
Re: alias overloading strange error
On Friday, 31 July 2015 at 10:56:33 UTC, vitus wrote:
//Why expression 'foobar(1);' doesn't work?
void foo()(){}
void bar(int){}
alias foobar = foo;
alias foobar = bar;
void main(){
.foobar(1); //OK
foobar(1); //Error: overload alias 'foo' is not a variable
}
It works when you switch the aliases around:
void foo()(){}
void bar(int){}
alias foobar = bar;
alias foobar = foo;
void main(){
foobar(1);
}
Definitely a bug. Please file an issue at
https://issues.dlang.org/.
