Re: align(n) not working as expected

On Tue, 28 Dec 2010 00:32:37 -0700, %u wrote: Hi, I'm not sure if I'm doing something wrong, but it seems like struct alignment isn't really working. (I just found out that I'm not supposed to post this on the digitalmars.D.bugs newsgroup, so I'm posting it here.) When I execute this cod

align(n) not working as expected

Hi, I'm not sure if I'm doing something wrong, but it seems like struct alignment isn't really working. (I just found out that I'm not supposed to post this on the digitalmars.D.bugs newsgroup, so I'm posting it here.) When I execute this code: struct Temp { ubyte x; align(16) ubyte y; }

Re: Clay language

bearophile wrote: The docs offer very little on Clay's module system (which is rock solid in D2). D2 module system may be fixed, but currently it's not even bread-solid. It does all of your wish list, and more. I've pointed this out to you before even in the last month. Please read the docume

streaming redux

I've put together over the past days an embryonic streaming interface. It separates transport from formatting, input from output, and buffered from unbuffered operation. http://erdani.com/d/phobos/std_stream2.html There are a number of questions interspersed. It would be great to start a disc

Re: Clay language

bearophile wrote: > The Clay syntax for imports is more similar to what I have desired for D: That looks virtually identical to D, with the sole exception of "import module" there means "static import module" in D and "import module.*" is "import module". But the functionality is identical. I've

Re: Clay language

On 12/28/10 12:09 AM, bearophile wrote: Andrei: FWIW I just posted a response to a question asking for a comparison between Clay and D2. http://www.reddit.com/r/programming/comments/es2jx/clay_programming_language_wiki/ Just few comments: The docs offer very little on Clay's module system

Re: GC conservatism -- again

On Mon, 27 Dec 2010 09:12:53 -0700, Steven Schveighoffer wrote: While fixing a design issue in druntime, I re-discovered how crappy the conservative GC can be in certain situations. The issue involves the array appending cache, which is used to significantly speed up array appends. Essent

Re: Clay language

Andrei: > FWIW I just posted a response to a question asking for a comparison > between Clay and D2. > > http://www.reddit.com/r/programming/comments/es2jx/clay_programming_language_wiki/ Just few comments: > The docs offer very little on Clay's module system (which is rock solid in > D2). D

Re: GC conservatism -- again

On Tue, 28 Dec 2010 05:25:59 +0200, Vladimir Panteleev wrote: the entire program - including the standard library, libc, etc. - are written in Safe-D Sorry, that made no sense. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net

Re: GC conservatism -- again

On Mon, 27 Dec 2010 18:12:53 +0200, Steven Schveighoffer wrote: While fixing a design issue in druntime, I re-discovered how crappy the conservative GC can be in certain situations. I have posted about this problem several times. Never got any replies. I think memory management is D's "e

Re: Subtyping with "alias this" doesn't mix with regular inheritance (issues 5380)

Oh hell! It took this posting to realize the problem in full. Sorry for disturbance.

Subtyping with "alias this" doesn't mix with regular inheritance (issues 5380)

Copied from bugzilla: --- Comment #0 from Max Samukha 2010-12-27 03:59:11 PST --- class A { } class B { A a; alias a this; } class C : B { } void main() { A a = new C; // error } Error: cannot implicitly convert expression (new C) of type test.C to test.A Since C is a subtype

Re: Clay language

On 12/28/2010 03:49 AM, Walter Bright wrote: Stanislav Blinov wrote: Frankly, I'd warmly back Walter on this one. "Requiring" optimizations is similar to asking a compiler to do something it's not supposed to... Another problem with specified optimizations is that computer architectures change

Re: Clay language

On 12/27/10 12:35 PM, bearophile wrote: Through Reddit I have found a link to some information about the Clay language, it wants to be (or it will be) a C++-class language, but it's not tied to C syntax. It shares several semantic similarities with D too. It looks like a cute language: https:/

Re: Clay language

On 12/27/10 12:35 PM, bearophile wrote: Through Reddit I have found a link to some information about the Clay language, it wants to be (or it will be) a C++-class language, but it's not tied to C syntax. It shares several semantic similarities with D too. It looks like a cute language: https:/

Re: Clay language

Stanislav Blinov wrote: Frankly, I'd warmly back Walter on this one. "Requiring" optimizations is similar to asking a compiler to do something it's not supposed to. In the end, optimization is a means compiler uses to make generated code more "efficient", which is a subjective term and can only

Re: Clay language

On 12/28/2010 12:48 AM, bearophile wrote: Walter: Additional optimizations should not be prevented, however. I.e. the same situation as today. It's a different situation. See this part: It should be possible to specify that one or more of these optimizations is required, and have the com

Re: D vs C++

Andrei Alexandrescu Wrote: > On 12/27/10 2:34 PM, foobar wrote: > > Andrei Alexandrescu Wrote: > >> It's currently a growing niche as sequential speed doesn't scale anymore > >> by Moore's law. Depending on the interplay of discoveries in the coming > >> years, I believe it's not impossible that s

Re: Clay language

bearophile wrote: The idea is to allow the code (I presume with the help of some annotations) to require certain optimizations (some are listed here, and they are more complex than replacing a*4 with a<<2:https://github.com/jckarter/clay/wiki/Guaranteed-optimizations ), if the compiler doesn't pe

Re: D vs C++

On 12/27/10 3:33 PM, "Jérôme M. Berger" wrote: Jérôme M. Berger wrote: ... I should perhaps add a couple of points: - I like D (or I would not be here); - D has some advantages over Python (mostly to do with low level programming and performance); - D and Python have some feature

Re: D vs C++

On 12/27/10 3:19 PM, "Jérôme M. Berger" wrote: spir wrote: On Sun, 26 Dec 2010 22:44:04 +0100 "Jérôme M. Berger" wrote: 8. direct interface to C Cython gives it too: it is as easy to write a Cython interface module as to write a D interface file for a C library. Hum, I do not agree at all.

Re: Clay language

Walter: >>> Additional optimizations should not be prevented, however. > I.e. the same situation as today. It's a different situation. See this part: > It should be possible to specify > that one or more of these optimizations is required, and have the compiler > raise an error when they cannot

Re: D vs C++

Jérôme M. Berger wrote: > ... I should perhaps add a couple of points: - I like D (or I would not be here); - D has some advantages over Python (mostly to do with low level programming and performance); - D and Python have some features that are on a par with each other; - Python has s

Re: D vs C++

spir wrote: > On Sun, 26 Dec 2010 22:44:04 +0100 > "Jérôme M. Berger" wrote: > >>> 8. direct interface to C >> Cython gives it too: it is as easy to write a Cython interface >> module as to write a D interface file for a C library. > > Hum, I do not agree at all. As I see it, D binds to C dire

Re: Clay language

bearophile wrote: This is something that I want for D too, it's important: Jonathan Shapiro (of BitC) makes an excellent argument that, in a systems language, it is often undesirable to depend on the whims of an ill-specified optimizer to convert abstract code into efficient machine code. The B

Re: "The D Programming Language" : Still valid?

On 12/27/10 2:39 PM, Brad Roberts wrote: On Mon, 27 Dec 2010, Andrei Alexandrescu wrote: P.S. I suggest you use the NNTP (newsgroup) interface; I've heard the mailing list has delays. To wit, I'm only seeing your post now although it seems to have been sent a few hours ago. Only the very firs

Re: How is the D programming language financed?

On 12/27/10 2:48 PM, Jeff Nowakowski wrote: On 12/27/2010 02:16 PM, Andrei Alexandrescu wrote: There's a risk on this newsgroup to get stuck in a sort of limbo mode, in which the analysis of increasingly narrow corner cases loses focus on a few larger issues. Granted, we _must_ leave no nooks a

Re: "The D Programming Language" : Still valid?

On Mon, Dec 27, 2010 at 9:12 AM, Klaim wrote: > Hi! > > I'm a C++ and game developpement enthousiast and I'm insterested in D as a > potential language to use for my game developpements. > > I bought the book "The D Programming Language" on Amazon as pre-command and > got one of the early no-auth

Re: D vs C++

Andrej Mitrovic wrote: On 12/27/10, bearophile wrote: In practice I still create less bugs in Python than D. Google builds many systems using Python, and they work. If you used D for several years and then switched to Python, you would without a doubt create many bugs. From my own experien

Re: D vs C++

On 12/27/10, Andrei Alexandrescu wrote: > I hope I placed a winning bet with D's NDS (no-default-sharing) > concurrency model; only time will tell. > Excerpt from a recent article: "Initial multicore chip architectures depended on a set of protocols that assures that each core has the same view

Re: Clay language

On Mon, 27 Dec 2010 13:42:50 -0700, Guilherme Vieira wrote: On Mon, Dec 27, 2010 at 4:35 PM, bearophile wrote: Through Reddit I have found a link to some information about the Clay language, it wants to be (or it will be) a C++-class language, but it's not tied to C syntax. It shares s

Re: D vs C++

bearophile wrote: Templates are far more than just generics. But an army of people argue that using templates for more than generics is bad. Not surprising considering how awful templates are in C++. Don't make the mistake of transferring that to D, which does things significantly differentl

Re: How is the D programming language financed?

On 12/27/2010 02:16 PM, Andrei Alexandrescu wrote: There's a risk on this newsgroup to get stuck in a sort of limbo mode, in which the analysis of increasingly narrow corner cases loses focus on a few larger issues. Granted, we _must_ leave no nooks and crannies unexplored, but we also shouldn't

Re: D vs C++

On 12/27/10 2:34 PM, foobar wrote: Andrei Alexandrescu Wrote: It's currently a growing niche as sequential speed doesn't scale anymore by Moore's law. Depending on the interplay of discoveries in the coming years, I believe it's not impossible that serial languages that spend CPU cycles on dynam

Re: Clay language

On Mon, Dec 27, 2010 at 4:35 PM, bearophile wrote: > Through Reddit I have found a link to some information about the Clay > language, it wants to be (or it will be) a C++-class language, but it's not > tied to C syntax. It shares several semantic similarities with D too. It > looks like a cute la

Re: "The D Programming Language" : Still valid?

On Mon, 27 Dec 2010 16:12:53 +0100 >> "Klaim" == Klaim wrote: Klaim> So my question is simply : how much is the book outdated now? I had somewhat similar question some time ago...check this thread: http://www.digitalmars.com/d/archives/digitalmars/D/is_it_possible_to_learn_D_2_124696.html

Re: "The D Programming Language" : Still valid?

On Mon, 27 Dec 2010, Andrei Alexandrescu wrote: > P.S. I suggest you use the NNTP (newsgroup) interface; I've heard the mailing > list has delays. To wit, I'm only seeing your post now although it seems to > have been sent a few hours ago. Only the very first post from each person for each group

Re: D vs C++

Andrei Alexandrescu Wrote: > It's currently a growing niche as sequential speed doesn't scale anymore > by Moore's law. Depending on the interplay of discoveries in the coming > years, I believe it's not impossible that serial languages that spend > CPU cycles on dynamic interpretation might bec

Re: "The D Programming Language" : Still valid?

On 12/27/10 9:12 AM, Klaim wrote: Hi! I'm a C++ and game developpement enthousiast and I'm insterested in D as a potential language to use for my game developpements. I bought the book "The D Programming Language" on Amazon as pre-command and got one of the early no-author-name-on-front edition

Re: D vs C++

On 2010-12-27 18:58, bearophile wrote: Andrei: Conversely, I wonder how we can improve the dynamic typing capabilities of D. On the Lambda the Ultimate blog I have found few interesting comments about dynamic typing (all the text below are quotations): Dim objDoc objDoc = CreateObject("Word

Re: htod simple macro translation

On 2010-12-27 17:07, Andrej Mitrovic wrote: I have a C header with a whole bunch of simple macros like: #define PM_FILT_FD (1<< 0x0D) Unfortunately htod won't translate these (I've tried every flag documented). However, I vaguely remember Walter mentioning some kind of technique where one cou

Re: typeof(t) not working correctly?

On 2010-12-27 08:31, Robert Jacques wrote: On Sun, 26 Dec 2010 22:48:42 -0700, %u wrote: Hi, I'm running this code below, and it returns an array of length zero for both print statements. Is this a bug, or am I missing something? Thank you! private import std.stdio; private import std.tra

"The D Programming Language" : Still valid?

Hi! I'm a C++ and game developpement enthousiast and I'm insterested in D as a potential language to use for my game developpements. I bought the book "The D Programming Language" on Amazon as pre-command and got one of the early no-author-name-on-front edition. I started to read the chapter qui

Re: How is the D programming language financed?

On 12/23/10 4:49 PM, Adam D. Ruppe wrote: Andrei Alexandrescu wrote: I think the bread and butter support is as rock solid in both languages. I agree. For my day to day work, I'm pretty conservative in the use of the language; 90% of my code is probably best characterized as "a better C". Int

Re: D vs C++

Mariusz Gliwiński wrote: Monday 27 December 2010 @ 17:18:17 Daniel Gibson: Am 27.12.2010 17:01, schrieb Caligo: On Mon, Dec 27, 2010 at 7:20 AM, Jonathan M Davis mailto:newshou...@digitalmars.com>> wrote: > > 11. generative programming > > Does someone have a pointer to any kind

Re: Phobos usability with text files

On 12/26/10 11:53 AM, Michel Fortin wrote: On 2010-12-26 12:13:41 -0500, Andrei Alexandrescu Generally I think buffer reuse in byLine() is too valuable to let go. I also agree it's wasteful. But I think bearophile's experiment has illustrated two noteworthy problems. The first issue is that c

Clay language

Through Reddit I have found a link to some information about the Clay language, it wants to be (or it will be) a C++-class language, but it's not tied to C syntax. It shares several semantic similarities with D too. It looks like a cute language: https://github.com/jckarter/clay/wiki/ Some smal

Re: D vs C++

bearophile, let me reply to some of your quotations briefly. I think those comments are directed toward older generation static languages. D blows them out of the water. And surpasses older dynamic languages, like Javascript, at the same time. Observe: > So if we were writing [the Word open code]

Re: D vs C++

On 12/27/10, bearophile wrote: > Andrej Mitrovic: > >> If you used D for several years and then switched to Python, you would >> without a doubt create many bugs. > > I'm using D for enough years, so I don't believe this argument any more. > > Bye, > bearophile > Okay, but why do you often experi

Re: Phobos usability with text files

If the function is left as is I expect questions about "Why isn't this working?" for it to appear on D.learn about 1 time each month. Exactly like what happens with property += value and other things that lead to incorrect result or don't work, viewed from the most obvious point of view.

Re: D vs C++

Andrei: > Conversely, I wonder how we can improve the dynamic typing capabilities of D. On the Lambda the Ultimate blog I have found few interesting comments about dynamic typing (all the text below are quotations): Dim objDoc objDoc = CreateObject("Word.Application") objDoc.Open(strFilename)

Re: D vs C++

Andrej Mitrovic: > If you used D for several years and then switched to Python, you would > without a doubt create many bugs. I'm using D for enough years, so I don't believe this argument any more. Bye, bearophile

Re: D vs C++

On 12/27/10 10:01 AM, Caligo wrote: On Mon, Dec 27, 2010 at 7:20 AM, Jonathan M Davis mailto:jmdavisp...@gmx.com>> wrote: On Monday 27 December 2010 04:41:37 spir wrote: > On Sun, 26 Dec 2010 12:06:04 -0800 > > Walter Bright mailto:newshou...@digitalmars.com>> wrote: > >

Re: D vs C++

I don't know about Variant, but D's auto is a real time-saver for me, especially when I'm converting some C code to D (app code, not libraries). It almost feels like coding in a dynamic language. On 12/27/10, Andrei Alexandrescu wrote: > On 12/27/10 2:19 AM, Gour wrote: >> On Sun, 26 Dec 2010 14:

Re: D vs C++

On 12/27/10 2:57 AM, bearophile wrote: Je'rome M. Berger: I have almost never used inline assembler even in languages that support it. Of course, this is only a sub-point of your point 6: using inline assembly in a language as slow as Python would be completely pointless.< For scientific co

Re: D vs C++

On 12/27/10 2:19 AM, Gour wrote: On Sun, 26 Dec 2010 14:33:25 -0600 "Seth" == Seth Hoenig wrote: Seth> This is certainly a personal preference, but I would add static Seth> typing to that list. +1 Conversely, I wonder how we can improve the dynamic typing capabilities of D. For example,

Re: auto init & what the code means

On 12/26/10 6:04 PM, Tomek Sowiński wrote: spir wrote: On Sun, 26 Dec 2010 14:54:12 +0100 Andrej Mitrovic wrote: int i;// auto-initialized to int.init int i = void; // not initialized Thanks. Actually this solves my "semantic" issue, did not even think at 'void'. (I will use it often).

Re: D vs C++

Monday 27 December 2010 @ 17:18:17 Daniel Gibson: > Am 27.12.2010 17:01, schrieb Caligo: > > On Mon, Dec 27, 2010 at 7:20 AM, Jonathan M Davis > > wrote: > > > > 11. generative programming > > > > > > Does someone have a pointer to any kind of

Re: D vs C++

Am 27.12.2010 17:01, schrieb Caligo: On Mon, Dec 27, 2010 at 7:20 AM, Jonathan M Davis mailto:jmdavisp...@gmx.com>> wrote: On Monday 27 December 2010 04:41:37 spir wrote: > On Sun, 26 Dec 2010 12:06:04 -0800 > > Walter Bright mailto:newshou...@digitalmars.com>> wrote: > >

Re: D vs C++

On 12/27/10, Caligo wrote: > As for CTFE, does this mean I could call 'writeln()' at compile time and > have it print a message to stdout while compiling? > You need to use pragma(msg, "your message here") for that. Not everything in D is CTFE-able, there are some limitations.

GC conservatism -- again

While fixing a design issue in druntime, I re-discovered how crappy the conservative GC can be in certain situations. The issue involves the array appending cache, which is used to significantly speed up array appends. Essentially, since the array appending cache was scanned as containing

htod simple macro translation

I have a C header with a whole bunch of simple macros like: #define PM_FILT_FD (1 << 0x0D) Unfortunately htod won't translate these (I've tried every flag documented). However, I vaguely remember Walter mentioning some kind of technique where one could use DMC to translate these(?). Or maybe I'm

Re: D vs C++

On Mon, Dec 27, 2010 at 7:20 AM, Jonathan M Davis wrote: > On Monday 27 December 2010 04:41:37 spir wrote: > > On Sun, 26 Dec 2010 12:06:04 -0800 > > > > Walter Bright wrote: > > > 11. generative programming > > > > Does someone have a pointer to any kind of doc about this? (in D) > > Anything on

Re: assocArray.remove() gives strange error

On Fri, 24 Dec 2010 00:58:37 -0500, Mariusz Gliwiński wrote: When i compile: type[key2][key1] assocArray1; assocArray1[key1].remove(key2); everything is ok, but building type[key2][key1] assocArray1; return (assocArray1[key1].remove(key2)); gives dmd: expression.c:817: void expToCBuffer(Out

Re: D vs C++

On 12/27/10, bearophile wrote: In practice I still create less bugs in Python > than D. Google builds many systems using Python, and they work. If you used D for several years and then switched to Python, you would without a doubt create many bugs. In any case, let's not forget that Python is a

Re: D vs C++

On Monday 27 December 2010 04:41:37 spir wrote: > On Sun, 26 Dec 2010 12:06:04 -0800 > > Walter Bright wrote: > > 11. generative programming > > Does someone have a pointer to any kind of doc about this? (in D) Anything on templates, template mixins, and string mixins. All of them generate cod

Re: auto init & what the code means

On Monday 27 December 2010 04:28:29 spir wrote: > On Sun, 26 Dec 2010 14:04:28 -0800 > > Jonathan M Davis wrote: > > On Sunday 26 December 2010 07:08:22 Andrei Alexandrescu wrote: > > > On 12/26/10 8:54 AM, spir wrote: > > > > On Sun, 26 Dec 2010 14:54:12 +0100 > > > > > > > > Andrej Mitrovic w

Re: D vs C++

On Sun, 26 Dec 2010 22:44:04 +0100 "Jérôme M. Berger" wrote: > > 8. direct interface to C > Cython gives it too: it is as easy to write a Cython interface > module as to write a D interface file for a C library. Hum, I do not agree at all. As I see it, D binds to C directly, Lua binds to C ra

Re: D vs C++

On Sun, 26 Dec 2010 12:06:04 -0800 Walter Bright wrote: > 11. generative programming Does someone have a pointer to any kind of doc about this? (in D) Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com

Re: auto init & what the code means

On Sun, 26 Dec 2010 14:04:28 -0800 Jonathan M Davis wrote: > On Sunday 26 December 2010 07:08:22 Andrei Alexandrescu wrote: > > On 12/26/10 8:54 AM, spir wrote: > > > On Sun, 26 Dec 2010 14:54:12 +0100 > > > > > > Andrej Mitrovic wrote: > > >> int i;// auto-initialized to int.init > > >> in

Re: typeof(t) not working correctly?

Oh wow, I should've looked beforehand -- thank you very much for the great reply, and sorry for not searching first!! :)

Re: D vs C++

Je'rome M. Berger: >I have almost never used inline assembler even in languages that support it. >Of course, this is only a sub-point of your point 6: using inline assembly in >a language as slow as Python would be completely pointless.< For scientific computing this is better than D inline asm

Re: D vs C++

On Sun, 26 Dec 2010 14:33:25 -0600 >> "Seth" == Seth Hoenig wrote: Seth> This is certainly a personal preference, but I would add static Seth> typing to that list. +1 -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA sig