Re: copying a struct containing a struct

On Friday, 16 November 2012 at 23:35:47 UTC, eskimo wrote: The default generated should simply call the user specified ones of any sub struct. I agree that is a more ideal solution. Conceptually, there's supposed to be a default opAssign anyway, so it should work as you would expect when a n

Re: I'm back

On Fri, Nov 16, 2012 at 08:52:39PM -0500, Jonathan M Davis wrote: > On Friday, November 16, 2012 13:55:31 H. S. Teoh wrote: > > I don't like the prospect of having to duplicate parts of > > std.algorithm just because I have some code that produces transient > > ranges -- I *know* I'm never going to

Re: I'm back

On Friday, November 16, 2012 13:55:31 H. S. Teoh wrote: > I don't like the prospect of > having to duplicate parts of std.algorithm just because I have some code > that produces transient ranges -- I *know* I'm never going to need to > use algorithms on them that can't handle transience anyway. It'

Re: DConf 2013 on kickstarter.com: we're live!

On 22/10/2012 19:25, Andrei Alexandrescu wrote: We're on! For one month starting today, we're raising funding for DConf 2013. http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0 Please pledge your support and encourage your friends to do the same. Hope t

Re: copying a struct containing a struct

On Fri, 2012-11-16 at 23:45 +0100, Rob T wrote: > This should be a compiler error or at the very least issue a > warning. > > It seems to me that overridden sub-struct opAssign needs to be > chained together, and it's a compiler error if there's a break in > the chain, i.e., if a sub-level stru

Custom checkers for Clang Static Analyzer [partially OT]

The LLVM 2012 Developers' Meeting has released some more slides. LLVM "back-end" tools are directly used and usable by the LDC compiler, and even some of the Clang front-end-like parts designed for C/C++11 are probably adaptable for the LDC front-end/glue layers. The Clang Static Analyzer is

Re: copying a struct containing a struct

> "opAssign(TTest other)" Thanks for highlighting this, now it is at least clear what happens. > > The fact that "opAssign called for: " is not printed is, AFAIK, a > HUGE and old standing bug: The fields of the struct are bit > copied (!) I now re-read the section in TDPL about move

Re: copying a struct containing a struct

On Friday, 16 November 2012 at 22:24:09 UTC, monarch_dodra wrote: The fact that "opAssign called for: " is not printed is, AFAIK, a HUGE and old standing bug: The fields of the struct are bit copied (!) Frankly, I have no idea why it isn't fixed yet... To "bypass" this "bug", simply

Re: copying a struct containing a struct

On Friday, 16 November 2012 at 21:02:36 UTC, eskimo wrote: Btw. if you replace t1=t2; with t1.inner=t2.inner; everything works as expected. What you are seeing is move semantics in action: When you call t1 = t2, it calls the compiler generated: "opAssign(TTest other)" As you can see, pass

Re: Request for "indexOf" undeprecation.

On Friday, 16 November 2012 at 21:17:00 UTC, Jonathan M Davis wrote: On Friday, November 16, 2012 14:18:02 monarch_dodra wrote: Can I get some Yays or Nays? Absolutely not. std.algorithm.indexOf was _always_ supposed to return code points for strings. It's an outright bug if it ever did othe

Re: I'm back

On Fri, Nov 16, 2012 at 10:32:22PM +0100, Jonathan M Davis wrote: [...] > Regardless, std.array.array _cannot_ work on ranges with transient > fronts. So, we have a few options: > > 1. Make transient fronts illegal, then std.array.array and its ilk > never have to worry about it. > > 2. Make it s

Re: I'm back

On Friday, November 16, 2012 19:06:05 Timon Gehr wrote: > The suggestion is to ban all potentially mutable indirections from > 'non-transient' ranges. (this redefines what 'transient' means.) It > cannot be derived that popFront will invalidate stuff just from the fact > that the type system does n

Re: A simple question

On 2012-11-16 11:16, Andrej Mitrovic wrote: Have you seen this comment: On 11/16/12, jerro wrote: doing that certainly would introduce some ambiguities. For example, consider this line: alias Foo Bar; Should Bar be a template or an instance of a template here? And my reply to that comment

Re: Request for "indexOf" undeprecation.

On Friday, November 16, 2012 14:18:02 monarch_dodra wrote: > Can I get some Yays or Nays? Absolutely not. std.algorithm.indexOf was _always_ supposed to return code points for strings. It's an outright bug if it ever did otherwise. It was renamed to countUntil so that people would not mistaking

copying a struct containing a struct

I hit a strange problem, which seems to be a compiler bug, but I kind of doubt it, because it is really serious and I did not find anything in bugzilla. So here is the example code, that behaves really not as expected and in my understanding just plain and seriously wrong: --- #!/usr/bin/rdmd impo

Re: Something needs to happen with shared, and soon.

11/16/2012 5:17 PM, Michel Fortin пишет: On 2012-11-15 16:08:35 +, Dmitry Olshansky said: While the rest of proposal was more or less fine. I don't get why we need escape control of mutex at all - in any case it just opens a possibility to shout yourself in the foot. In case you want to p

Re: Deprecation in core.sys.posix.termios

On Fri, Nov 16, 2012 at 07:15:01PM +0100, Alex Rønne Petersen wrote: > On 16-11-2012 19:14, H. S. Teoh wrote: > >Due to the deprecation of octal literals, core.sys.posix.termios doesn't > >compile anymore. But because this is in druntime, we can't use > >std.conv.octal. What should be done about th

Re: Deprecation in core.sys.posix.termios

On 16-11-2012 19:14, H. S. Teoh wrote: Due to the deprecation of octal literals, core.sys.posix.termios doesn't compile anymore. But because this is in druntime, we can't use std.conv.octal. What should be done about this? T I fixed this in a pull request of mine because it happened to get i

Deprecation in core.sys.posix.termios

Due to the deprecation of octal literals, core.sys.posix.termios doesn't compile anymore. But because this is in druntime, we can't use std.conv.octal. What should be done about this? T -- Designer clothes: how to cover less by paying more.

Re: I'm back

On 11/16/2012 01:58 AM, Jonathan M Davis wrote: On Thursday, November 15, 2012 22:11:33 Timon Gehr wrote: On 11/14/2012 08:32 PM, Jonathan M Davis wrote: On Wednesday, November 14, 2012 20:18:26 Timon Gehr wrote: That is a very imprecise approximation. I think it does not cover any ground: The

Re: Request for "indexOf" undeprecation.

On Friday, 16 November 2012 at 17:30:57 UTC, Denis Shelomovskij wrote: 16.11.2012 17:18, monarch_dodra пишет: As you can see, when operating on UTF strings, the (expected) result of countUntil is not the same as that of indexOf. countUntil is currently bugged, in the sense that it will return

Re: What about std.lockfree ?

On Thursday, 18 October 2012 at 22:01:20 UTC, denizzzka wrote: Anyone interested in std.lockfree - lock-free lists, FIFOs, stacks etc? I spent a few days doing implementations of procs, but has not reached any success. My plan: For many of lock-free algorithms it is need a function MCAS (m

Re: Request for "indexOf" undeprecation.

16.11.2012 17:18, monarch_dodra пишет: As you can see, when operating on UTF strings, the (expected) result of countUntil is not the same as that of indexOf. countUntil is currently bugged, in the sense that it will return the index in the string (as opposed to the count of popFront's). Thanks

Re: Request for "indexOf" undeprecation.

Am 16.11.2012 17:50, schrieb monarch_dodra: > On Friday, 16 November 2012 at 16:33:47 UTC, Sönke Ludwig wrote: >> >> As far as I see allowing divergent behavior for index based access and >> popFront/front would >> basically mean that no sensible algorithm could be implemented. What should >> som

Re: Request for "indexOf" undeprecation.

On Friday, 16 November 2012 at 16:33:47 UTC, Sönke Ludwig wrote: As far as I see allowing divergent behavior for index based access and popFront/front would basically mean that no sensible algorithm could be implemented. What should some generic algorithm do with a RA range that returns double

Re: Something needs to happen with shared, and soon.

Le 15/11/2012 17:33, Sean Kelly a écrit : On Nov 15, 2012, at 4:54 AM, deadalnix wrote: Le 14/11/2012 21:01, Sean Kelly a écrit : On Nov 14, 2012, at 6:32 AM, Andrei Alexandrescu wrote: This is a simplification of what should be going on. The core.atomic.{atomicLoad, atomicStore} functi

Re: Request for "indexOf" undeprecation.

Am 16.11.2012 16:08, schrieb monarch_dodra: > On Friday, 16 November 2012 at 14:50:26 UTC, Sönke Ludwig wrote: >> Am 16.11.2012 15:02, schrieb monarch_dodra: wait, no, that one also screws up and returns based on the ASCII state of the search character! >>> >>> It doesn't screw up t

Re: Something needs to happen with shared, and soon.

On Nov 16, 2012, at 5:17 AM, Michel Fortin wrote: > On 2012-11-15 16:08:35 +, Dmitry Olshansky said: > >> 11/15/2012 8:33 AM, Michel Fortin пишет: >>> If you want to declare the mutex separately, you could do it by >>> specifying a variable instead of a type in the variable declaration: >>>

Re: Request for "indexOf" undeprecation.

On Friday, 16 November 2012 at 14:50:26 UTC, Sönke Ludwig wrote: Am 16.11.2012 15:02, schrieb monarch_dodra: wait, no, that one also screws up and returns based on the ASCII state of the search character! It doesn't screw up the result, it is meant for slicing your string. Just that it ret

Re: Request for "indexOf" undeprecation.

Am 16.11.2012 15:02, schrieb monarch_dodra: >> wait, no, that one >> also screws up and returns based on the ASCII state of the search character! > > It doesn't screw up the result, it is meant for slicing your string. Just that it returns the index of the _code point_ if you pass a non-ASCII ch

Re: Something needs to happen with shared, and soon.

On Friday, 16 November 2012 at 10:59:02 UTC, Manu wrote: On 16 November 2012 12:09, Pragma Tix wrote: On Friday, 16 November 2012 at 09:24:22 UTC, Manu wrote: On 15 November 2012 17:17, Andrei Alexandrescu < seewebsiteforem...@erdani.org> wrote: On 11/15/12 1:08 AM, Manu wrote: On 14 No

Re: Something needs to happen with shared, and soon.

Am 16.11.2012 14:17, schrieb Michel Fortin: > > Only if you can make a proxy object that cannot leak a reference. It's > already not obvious how to > not leak the top-level reference, but we must also consider the case where > you're protecting a data > structure with the mutex and get a pointer

Re: Request for "indexOf" undeprecation.

On Friday, 16 November 2012 at 13:49:57 UTC, Sönke Ludwig wrote: Fully agree about the fix of countUntil - I can imagine that there is a non-trivial amount of code that blindly uses countUntil instead of indexOf because of the deprecation (I know I also did this before). But there is still s

Re: Request for "indexOf" undeprecation.

Am 16.11.2012 14:18, schrieb monarch_dodra: > I'd like to get a green light to undeprecate "indexOf". > > The rationale for the original deprecation is that it was superseded by > "countUntil", which also > works on forward ranges (indexOf implies, by name, that it only operates on > RA). > > T

Re: Something needs to happen with shared, and soon.

On 2012-11-15 16:08:35 +, Dmitry Olshansky said: 11/15/2012 8:33 AM, Michel Fortin пишет: If you want to declare the mutex separately, you could do it by specifying a variable instead of a type in the variable declaration: Mutex m; synchronized(m) int i; synchronized(i)

Request for "indexOf" undeprecation.

I'd like to get a green light to undeprecate "indexOf". The rationale for the original deprecation is that it was superseded by "countUntil", which also works on forward ranges (indexOf implies, by name, that it only operates on RA). There is just one problem: "日本語".indexOf(本) => 3 "日本語".coun

Re: DMD on Haiku?

Well, I was going to tackle the porting stuff about a week ago, but for some reason my computer refuses to boot Haiku, I think it's an ACPI thing, but I can't find any settings for it in my BIOS. Oh well, I guess it will have to wait a while. Or alternatively I could port it from virtualbox or

Re: Something needs to happen with shared, and soon.

On 16 November 2012 12:09, Pragma Tix wrote: > On Friday, 16 November 2012 at 09:24:22 UTC, Manu wrote: > >> On 15 November 2012 17:17, Andrei Alexandrescu < >> seewebsiteforem...@erdani.org> wrote: >> >> On 11/15/12 1:08 AM, Manu wrote: >>> >>> On 14 November 2012 19:54, Andrei Alexandrescu >>

Re: Compiler bug? (alias sth this; and std.signals)

> Why would is(T == struct) be true but !isBuiltinType!T be false? Exactly because of alias this. Your type is a struct and an integer at the same time, so to speak. At least it behaves that way and that's what its all about. If if looks like a duck, quacks like a duck, ... it is a duck ;-) > This

Re: A simple question

On 11/16/12, kenji hara wrote: > Done. > https://github.com/D-Programming-Language/dmd/pull/1295 Have you seen this comment: On 11/16/12, jerro wrote: > doing that certainly would introduce some ambiguities. For > example, consider this line: > > alias Foo Bar; > > Should Bar be a template or a

Re: Something needs to happen with shared, and soon.

On Friday, 16 November 2012 at 09:24:22 UTC, Manu wrote: On 15 November 2012 17:17, Andrei Alexandrescu < seewebsiteforem...@erdani.org> wrote: On 11/15/12 1:08 AM, Manu wrote: On 14 November 2012 19:54, Andrei Alexandrescu > wrote: Yah, the whol

Re: Something needs to happen with shared, and soon.

On 15 November 2012 17:17, Andrei Alexandrescu < seewebsiteforem...@erdani.org> wrote: > On 11/15/12 1:08 AM, Manu wrote: > >> On 14 November 2012 19:54, Andrei Alexandrescu >> > > >> >> >> wrote: >> Yah, the whole point here is that we need something I

Re: A simple question

Done. https://github.com/D-Programming-Language/dmd/pull/1295 Kenji Hara 2012/11/16 kenji hara > Now I'm working that. > > Kenji Hara > > 2012/11/16 Don Clugston > >> One of the oldest open enhancement requests is on this topic: >> >> http://d.puremagic.com/issues/**show_bug.cgi?id=1012

Re: Something needs to happen with shared, and soon.

On 15 November 2012 17:17, Andrei Alexandrescu < seewebsiteforem...@erdani.org> wrote: > On 11/15/12 1:08 AM, Manu wrote: > >> On 14 November 2012 19:54, Andrei Alexandrescu >> > > >> >> >> wrote: >> Yah, the whole point here is that we need something I

Re: A simple question

Now I'm working that. Kenji Hara 2012/11/16 Don Clugston > On 16/11/12 05:15, Rob T wrote: > >> On Friday, 16 November 2012 at 03:41:45 UTC, Stugol wrote: >> >>> Event_t e2;// Will compile! >>> >>> Yeah but that kinda blows, doesn't it? >>> >>> >> I found it surprising or unintuiti

Re: Binary compatibility on Linux

Russel Winder wrote: > [[I suspect this is getting way off-topic for this list, so if > instructed to take it elsewhere will be happy to do so as long as > elsewhere is defined.]] I added your comments and a remark about the role of make in Debian: http://wiki.debian.org/UpstreamGuide?action=diff

Re: Compiler bug? (alias sth this; and std.signals)

Why would is(T == struct) be true but !isBuiltinType!T be false? This seems highly inconsistent. If T is a struct, it is not a builtin type, and if T is int (also making the condition false), then Property should never have been passed as a struct, but as the int gotten via the alias. On Thursday

Re: A simple question

On 16/11/12 05:15, Rob T wrote: On Friday, 16 November 2012 at 03:41:45 UTC, Stugol wrote: Event_t e2;// Will compile! Yeah but that kinda blows, doesn't it? I found it surprising or unintuitive that the !() is required, and I do want to know what is the reasoning behind it, One o

Re: What's the deal with __thread?

On Thursday, 15 November 2012 at 14:42:32 UTC, Don Clugston wrote: in D. It's a very rare case, I guess, but it's one of those situations where D code silently has different behaviour from identical C code. extern(C) int x; is not C code. :P