Re: The difference between the dates in years
On 2/10/2024 6:01 PM, matheus via Digitalmars-d-learn wrote: On Saturday, 10 February 2024 at 22:11:48 UTC, Brad Roberts wrote: Back when I was doing lots of software developer interviews, one of my frequent questions involved date math. This wasn't because it's difficult from a coding standpoint, but that it's NOT a coding problem. The key part of the question is realization that it's a requirements question. The thing that makes dates complicated is defining what the question actually is. The topic _seems_ like it should be simple, but the deeper you dig the more you realize it's anything but simple. Interesting but I have a doubt, they (Interviewees) should do the test with already existing Date Functions of given language or write new ones? Matheus. My interviews were never tests, they were discussions that might also involve coding tasks. In this case, the discussion was about requirements gathering disguised initially as a coding task. By and large, I never put a lot of weight on the coding parts themselves and mostly focused on problem solving and thinking skills. If the candidate couldn't get past writing code and wouldn't ask questions, that was a very bad sign.
Re: The difference between the dates in years
Back when I was doing lots of software developer interviews, one of my frequent questions involved date math. This wasn't because it's difficult from a coding standpoint, but that it's NOT a coding problem. The key part of the question is realization that it's a requirements question. The thing that makes dates complicated is defining what the question actually is. The topic _seems_ like it should be simple, but the deeper you dig the more you realize it's anything but simple. On 2/10/2024 7:53 AM, Alexander Zhirov via Digitalmars-d-learn wrote: Is it possible to calculate the difference between dates in years using regular means? Something like that ``` writeln(Date(1999, 3, 1).diffMonths(Date(1999, 1, 1))); ``` At the same time, keep in mind that the month and day matter, because the difference between the year, taking into account the month that has not come, will be less. My abilities are not yet enough to figure it out more elegantly.
Re: malloc error when trying to assign the returned pointer to a struct field
On 9/8/2023 12:59 AM, rempas via Digitalmars-d-learn wrote: u64 _cap = 0; // Total amount of elements (not bytes) we can this._ptr = cast(T*)malloc(size); I'm pretty sure this is your problem. You're allocating size bytes which is only going to work where sizeof(T) == 1. Changing to malloc(size * sizeof(T)) is likely going to work better.
Re: purity question
On 5/28/2017 6:46 PM, Brad Roberts via Digitalmars-d-learn wrote: Here's the bug that I'm digging into today, a clear example of an api that _should_ be pure, but based on the implementation is rather difficult for the compiler to infer. https://issues.dlang.org/show_bug.cgi?id=17442
Re: purity question
On 5/28/2017 6:36 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
On Sunday, May 28, 2017 17:53:25 Brad Roberts via Digitalmars-d-learn wrote:
On 5/28/2017 5:34 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
On Sunday, May 28, 2017 16:49:16 Brad Roberts via Digitalmars-d-learn
wrote:
Is there a mechanism for declaring something pure when it's built from
parts which individually aren't?
string foo(string s)
{
// do something arbitrarily complex with s that doesn't touch
globals or change global state except possibly state of the heap or gc
return s;
}
you can cast
Ok, so there essentially isn't. I'm well aware of the risks of lying to
the compiler, but it's also not sufficiently smart to unravel complex
code. Combined with there being interesting parts of the standard
libraries that themselves aren't marked pure, there's a real need for
escape hatches.
Well, the big thing is that there are a number of functions in Phobos that
need to have someone go over them and fix them so that they are inferred to
be pure when they should be. Some work has been done in that area, and the
situation is certainly better than it once was, but not enough work has been
done to make it so that we can at all reasonably that everything in Phobos
that should be pure is and what isn't shouldn't be.
A simple example: anything that has a malloc/free pair.
Yeah, if you do it right, you should be fine, but you have to do it right,
and it's very easy to miss some detail that makes it wrong to insist to the
compiler that what you're doing is pure. So, arguably, having anything more
user-friendly than a cast is pretty dangerous. Having folks slap something
like @assume_pure on things (if there were such an attribute) could be
pretty risky. We already have enough trouble with @trusted on that front.
Ultimately, we want to be in a position where needing to get around pure is
very rare, and in most cases, I'd just tell folks to give up on pure on that
piece of code rather than trying to hack it into working.
- Jonathan M Davis
Again, of course it's possible to do it wrong. Escape hatches are like
that. And of course things are being worked on and improved, I'm one of
the ones that's done a good bit of that at various points in time. I'm
really not seeking a lesson or lecture in why it's dangerous.
Here's the bug that I'm digging into today, a clear example of an api
that _should_ be pure, but based on the implementation is rather
difficult for the compiler to infer.
Re: purity question
On 5/28/2017 6:27 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
On Monday, May 29, 2017 01:01:46 Stefan Koch via Digitalmars-d-learn wrote:
On Monday, 29 May 2017 at 00:53:25 UTC, Brad Roberts wrote:
On 5/28/2017 5:34 PM, Jonathan M Davis via Digitalmars-d-learn
wrote:
On Sunday, May 28, 2017 16:49:16 Brad Roberts via
Digitalmars-d-learn wrote:
Is there a mechanism for declaring something pure when it's
built from
parts which individually aren't?
string foo(string s)
{
// do something arbitrarily complex with s that doesn't
touch
globals or change global state except possibly state of the
heap or gc
return s;
}
you can cast
Ok, so there essentially isn't. I'm well aware of the risks of
lying to the compiler, but it's also not sufficiently smart to
unravel complex code. Combined with there being interesting
parts of the standard libraries that themselves aren't marked
pure, there's a real need for escape hatches. A simple
example: anything that has a malloc/free pair.
There is
void[] myPureMalloc(uint size) pure @trusted nothrow @nogc
{
alias pure_malloc_t = pure nothrow void* function(size_t size);
return (cast(pure_malloc_t)malloc)(size)[0 .. size];
}
There was a whole discussion or 3 is PRs about making malloc pure, and IIRC,
it was done and then decided that it wasn't safe to do some for one reason
or another (IIRC, it had to do with what would happen when calls were
elided, because the caller was strongly pure, but I'm not sure). So, I'd be
_very_ careful about deciding that it was safe to call malloc in pure code.
I expect that it's just fine in some contexts, but it's easy enough to screw
up and mark something as pure when it really shouldn't be because of some
detail you missed that you should be _really_ careful about decided to cast
to pure.
- Jonathan M Davis
That's one reason I explicitly referenced malloc/free pairs. It's a lot
easier to be sure that those together aren't violating purity.
Re: purity question
On 5/28/2017 6:01 PM, Stefan Koch via Digitalmars-d-learn wrote:
On Monday, 29 May 2017 at 00:53:25 UTC, Brad Roberts wrote:
On 5/28/2017 5:34 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
On Sunday, May 28, 2017 16:49:16 Brad Roberts via
Digitalmars-d-learn wrote:
Is there a mechanism for declaring something pure when it's built from
parts which individually aren't?
string foo(string s)
{
// do something arbitrarily complex with s that doesn't touch
globals or change global state except possibly state of the heap or gc
return s;
}
you can cast
Ok, so there essentially isn't. I'm well aware of the risks of lying
to the compiler, but it's also not sufficiently smart to unravel
complex code. Combined with there being interesting parts of the
standard libraries that themselves aren't marked pure, there's a real
need for escape hatches. A simple example: anything that has a
malloc/free pair.
There is
void[] myPureMalloc(uint size) pure @trusted nothrow @nogc
{
alias pure_malloc_t = pure nothrow void* function(size_t size);
return (cast(pure_malloc_t)malloc)(size)[0 .. size];
}
That's still a cast. It's a nice way to isolate the cast, but it's
clearly still there. And as I said, that's just one simple example.
Re: purity question
On 5/28/2017 5:34 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
On Sunday, May 28, 2017 16:49:16 Brad Roberts via Digitalmars-d-learn wrote:
Is there a mechanism for declaring something pure when it's built from
parts which individually aren't?
string foo(string s)
{
// do something arbitrarily complex with s that doesn't touch
globals or change global state except possibly state of the heap or gc
return s;
}
you can cast
Ok, so there essentially isn't. I'm well aware of the risks of lying to
the compiler, but it's also not sufficiently smart to unravel complex
code. Combined with there being interesting parts of the standard
libraries that themselves aren't marked pure, there's a real need for
escape hatches. A simple example: anything that has a malloc/free pair.
purity question
Is there a mechanism for declaring something pure when it's built from
parts which individually aren't?
string foo(string s)
{
// do something arbitrarily complex with s that doesn't touch
globals or change global state except possibly state of the heap or gc
return s;
}
Re: spam in bugzilla
I've been marking the accounts as spam and moving the bugs to a specific spam product/category. The last few days have been unusual. If it keeps up, I'll investigate ways of potentially dealing with it better, but I really don't want to add friction to the signup process. It's hard enough to get people to report bugs in general, I don't want to make it harder. On 11/23/2016 11:09 AM, Jonathan M Davis via Digitalmars-d-learn wrote: On Wednesday, November 23, 2016 13:31:45 Steven Schveighoffer via Digitalmars-d-learn wrote: See here: https://issues.dlang.org/show_bug.cgi?id=16737 I don't want to close/change anything, because the guy's email is the reporter, and he'll get any updates. Is there a way to mark something as spam so it gets deleted, and so there are no emails sent to the reporter? If there is, it probably requires Brad to do it. - Jonathan M Davis
Re: Is memory-safe IO possible?
On 1/22/2016 9:10 AM, Chris Wright via Digitalmars-d-learn wrote: On Fri, 22 Jan 2016 08:36:14 +, Kagamin wrote: Should be possible. Why not? Because almost no IO routines in Phobos are marked @safe, which implies that it's difficult in practice or that people simply haven't done it. I checked std.file, std.net.curl, and std.stdio; a handful of things are @safe while the vast majority aren't. I want everything I do to be @safe. Unfortunately, "everything I do" includes IO (and std.json), and while it's not sprinkled throughout my code, the call stack has enough variety that I can't mark very much @safe at the end of the day. At the very least, it would be nice to say: I can't entirely trust some of the code I'm calling, but at least for the code I'm writing here, stop me from doing anything stupid. A @tryToBeSafeIsh, if you will. Correct, the bug isn't that the documentation is missing about why it's not @safe. The bug is that a whole lot of phobos (and druntime) should be @safe but the work hasn't been done to mark it as such. At this point in time, there's not many interesting apps that could mark their main with @safe, which is a real shame.
Re: Calling D from C, C++, Python…
On 9/12/15 9:20 AM, Adam D. Ruppe via Digitalmars-d-learn wrote: On Saturday, 12 September 2015 at 09:47:55 UTC, Jacob Carlborg wrote: Well, if your D function doesn't use anything of the runtime I guess it's not necessary. Right. If you don't call into the threading system in the druntime, you should be ok. Keep in mind though that the GC uses the threads and the new expression, array literals, array append, and others use the GC. Runtime.initialize is also what calls static and module constructors... and might have responsibility for fixing up dynamic casting of class objects in a shared lib too, I'm not sure about that. But if you avoid the bulk of the runtime functions, indeed you can get away without initializing it. Just that null thread handle is likely to cause segfaults in places where you might not expect if you don't. It is best to initialize it. Lots of C libraries need an init an teardown call, so surely the Python interop provides some solution for it. idk what it would be though. I think it's safest to say (and it belongs in the spec somewhere) that executing D code before initializing the runtime results in undefined behavior, or something along those lines. You can get away with it in some circumstances, but it's at your own risk.
Re: Startup files for STM32F4xx
On 4/25/2015 10:02 PM, Timo Sintonen via Digitalmars-d-learn wrote: -Import mess. Phobos files import several other files. Some of them cannot be used. Work is going on to remove unnecessary imports and use scoped imports. It is important that imports for unittests are only in unittest blocks. -All functions have to be nogc. Active work is going on also in this area. The files should just be tried one by one to see if they can be compiled. It's important to note that most of the work occurring on these fronts is use-case driven. Not much is happening for the sake of completeness (except to some degree by Walter). So, your needs where they don't overlap with someone else's needs, might well take a long time to get done unless you do some of the driving. Even tackling the improvement of one or two api's helps drive towards completion.
Re: Valgrind
Valgrind has a mechanism for teaching it how to ignore certain patterns. A long time ago I setup suppressions for the gc, but the code has changed out from under that version so the work would need to be redone. On 4/20/2015 7:23 PM, Martin Nowak via Digitalmars-d-learn wrote: On Monday, 20 April 2015 at 13:28:57 UTC, John Colvin wrote: The only special thing to take in to account is that valgrind will choke on DMD generated floating point code I actually fixed this problem a while ago. https://github.com/D-Programming-Language/dmd/pull/4368 An actual problem with valgrind is the GC, because most of it's operations appear to valgrind as memory corruptions. You can GC.disable() collections, use gcstub.d, or help Vladimir with his valgrind/GC support to make things work. http://dlang.org/phobos/core_memory.html#.GC.disable https://github.com/D-Programming-Language/druntime/blob/master/src/gcstub/gc.d https://github.com/CyberShadow/druntime/commits/valgrind
Re: std.conv.to purity
While snprintf might be one thing that provides to be an interesting
obstacle, the better answer to why std.conv.to isnt pure is that no one
has invested the time to work through issues like that to make it so.
It _should_ be pure.
On 2/14/2015 12:32 PM, ketmar via Digitalmars-d-learn wrote:
On Sat, 14 Feb 2015 19:59:58 +, Gary Willoughby wrote:
On Saturday, 14 February 2015 at 12:24:51 UTC, ketmar wrote:
On Sat, 14 Feb 2015 11:29:28 +, Jack Applegame wrote:
why std.conv.to is not pure?
string foo(real v) pure { return v.to!string; }
// Error: pure function 'foo' cannot call impure function
'std.conv.to!string.to!(real).to'
'cause float-string conversion is damned hard task. to perform this
conversion `to!` falls back to `formatValue` from std.format,
which in turn using `snprintf()` from libc.
Forgive me being a bit dense but that doesn't necessarily mean it's
impure though, right?
yes, you are right, it *may* be pure. yet `snprintf()` can't be marked as
`pure`, so it contaminates everything. and there are no guarantees that
`snprintf()` is pure even for known arguments (compiler can't prove that,
and libc is free to do any funny things in it), so it will be wrong to
just force-reimport it as `pure`.
tl;dr: we need native D float-string converter to allow purity in this
case. you are free to force-hack purity flag on function if you want, but
this can be wrong and may lead to various heisenbugs.
native pure D converter will also allow CTFE, btw, which is impossible
now.
Re: Getting libcurl for 64 bit Windows
The one that the win64 auto-tester uses is here:
http://downloads.dlang.org/other/
curl-7.28.1-devel-rainer.win64.zip
There's a newer one available there, but I can't vouch for it.
On 6/26/14, 11:49 AM, Andrei Alexandrescu via Digitalmars-d-learn wrote:
On 6/26/14, 11:11 AM, Mark Isaacson wrote:
Managed to build it successfully I think, but have actually
returned to the problem that initially caused me to want to try
and build the library in the first place:
If I try to build a simple program:
import std.stdio;
import std.net.curl;
void main() {
writeln(Hello world);
}
The program compiles, but does not print Hello World at
runtime... it just stops, and seemingly does nothing.
Trying to determine the root cause of that now.
Mark is my intern, and we're currently blocked by this in creating an important
demo for tomorrow.
Does anyone have good instructions for building libcurl on Win64, or prebuild
.lib and .dll files?
Thanks very much,
Andrei
Re: list in spam blacklist? [OT]
Once every few years spamhaus 'cleans up' their white lists with no notifications. I've already initiated the re-removal. Sigh. I hate spamhaus, they're a pain in every mail sender's backside. On 4/4/14, 10:25 AM, Hugo Florentino wrote: Hi, IP 173.45.241.208 (slice-1.puremagic.com) seems to be blacklisted in zen.spamhaus.org Please check for a possible misuse of the server, or in case of a false positive report to spamhaus.org Regards, Hugo
Re: Why CTFE is context-sensitive?
On 1/27/14 10:40 AM, Pierre Talbot wrote: On Monday, 27 January 2014 at 01:39:47 UTC, Simen Kjærås wrote: On 2014-01-26 09:59, Pierre Talbot wrote: Hi, I was wondering why CTFE is context sensitive, why don't we check every expressions and run the CTFE if it applies? Mostly because it's not necessary, and takes more time than simply compiling it. For an optimization step, opportunistic CTFE would certainly be possible (it is, after all, simply constant folding on steroids). The situations in which CTFE is attempted today are when it's explicitly required - either because the value is used at compile time, or because it's assigned to a manifest constant or static variable (which are defined to be required to be known at compile time). This means the compiler does not need to spend inordinate amounts of time testing to see if the code compiles with CTFE, and that it can give sensible error messages when something cannot be CTFE'd. If instead opportunistic CTFE were the norm, you would need to disassemble your program to see if the compiler did in fact CTFE the code that you think it should. -- Simen We could do opportunistic CTFE by default, and if the user want to ensure it is done, instead of disassemble the program, he could just use the usual techniques (static, ...). But ok, what I wanted to hear is that it is theoretically possible but technically problematic. Thanks to all, Pierre One of the problems is on the opposite side, ensuring it's NOT done when you don't want it to be. Consider an example where you have a blob of obfuscated data and a de-obfuscation routine. It _could_ be executed at compile time, but that defeats the point. What we have right now puts the control in the hands of the developer.
Re: Profiling
Please file a bug on this. The docs should be on dlang.org. On 1/24/14 11:15 AM, Dmitry Olshansky wrote: 24-Jan-2014 20:31, Philippe Sigaud пишет: I'm trying to use the `-profile` flag for DMD and, without any documentation, I can't really understand the resulting log files: * They contain only mangled names. Is there a way to get demangled, human-readable symbols? pipe it though ddemangle tool. I though it was shipped with compiler. * Can someone tell me what the numbers means? Ticks spent in this function. One column specifies inclusive time (the whole call-tree of that function) another one exclusive - time spent exactly in this function not its children. Is there a page somewhere on dlang.org that explains how to use the profiler? http://digitalmars.com/ctg/trace.html see Dynamic Profiling With DMD Thanks, Philippe
Re: A little of coordination for Rosettacode
On 1/15/14 4:42 PM, bearophile wrote: Brad Roberts: I think this is a mistake. They should compile with a released compiler. Why? And why do you think that outweighs the several advantages of having entries compilable only with the latest beta compiler? (Currently there are 40-50 entries that don't compile with the released dmd 2.064.) Requiring that users of the code in resottacode be using bleeding edge, unreleased, compilers is a disservice to those users. Typical users will not and should not need to use anything other than a released compiler. They also likely form a potentially interesting set of regression tests that someone ought to volunteer to test beta's against. Rosettacode site has many different purposes; I also use those programs to test the dmd compiler for regressions. But to do this effectively you have to use the latest compiler changes. Also, how can you update manually on the site tens of entries all at once when a new compiler comes out? The point is you shouldn't have to, unless the code is taking advantage of broken behavior. Any changes that 'have' to be made due to a compiler release need to be carefully examined as probable regressions in the compiler.
Re: Starting D with a project in mind.
On 10/15/13 3:38 PM, Dicebot wrote: Unfortunately, this is an area where difference in developer count is really notable. It is a dead end - support for more exotic platforms like ARM is lacking because there too few people who need it and new bypassers are scared from further investigation because of lacking support. There is hardly anything we can do until some volunteer will appear who is willing to champion this. I think you mean catch-22 rather than dead-end. There's not more people helping support ARM due to ARM not yet working well, so there's no developers. ARM's not exotic, it's just not on as many people's desktops. Thats been changing rapidly over the last several years.
Re: Linker error: Symbol Undefined
It's due to having the destructor versioned out when building foo and visible when building bar.
When brought together, you've created an incompatible whole. There's no destructor actually
included in foo's .o file that you told it it could expect to find.
There's no bug in the compiler or linker, just your usage of mis-matched code.
On 10/11/13 11:39 AM, Namespace wrote:
Hey, I'm curious about this linker error:
OPTLINK (R) for Win32 Release 8.00.13
Copyright (C) Digital Mars 1989-2010 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
bar.obj(bar)
Error 42: Symbol Undefined _D3foo1A6__dtorMFZv
--- errorlevel 1
foo.d:
debug import std.stdio;
struct A {
public:
int id;
this(int id) {
debug writeln(CTor A with , id);
this.id = id;
}
debug ~this() {
writeln(DTor A with , id);
}
}
bar.d
import foo;
void test(A a) {
a.id++;
}
void main() {
test(A(42));
A a = A(23);
test(a);
}
Usage:
C:\Users\Besitzer\Desktopdmd -lib foo.d
C:\Users\Besitzer\Desktopdmd bar.d foo.lib -debug
OPTLINK (R) for Win32 Release 8.00.13
Copyright (C) Digital Mars 1989-2010 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
bar.obj(bar)
Error 42: Symbol Undefined _D3foo1A6__dtorMFZv
--- errorlevel 1
Without -debug or with 'debug' _in_ the DTor (before writeln) instead before
the DTor works fine.
Re: Unable to use tradional tools to find memory leaks
On 9/21/13 9:01 AM, Maxim Fomin wrote: On Saturday, 21 September 2013 at 14:30:19 UTC, Flamaros wrote: I tried to used Valgrind (Linux) and Dr Memory (Windows) without success to find a big leak I have in my application. But both tools can't launch my application without make it crash. Is application crashing without these tools? Probably you have some bug which is detected by valgrind. By the way, some pitfalls of using valgrind for testing D code: 1) Its implementation of float numbers at compile time is buggy (for example, there may be static asserts which are true when running under native envorionment and false under valgrind) 2) Dmd's codegen is sometimes not supported by valgrind (cannot execute some instructions which is rare case when something from D beats some tool outside) 3) It has some false positives regarding using uninitialized values especially during execution of GC code. Do I need do something particular, to have a chance to see one of those tool working fine with my application? If you run into #2 then you cannot fix it. That's wrong. Both DMD and Valgrind are software, both of which can be debugged and changed. Please file appropriate bug reports, hopefully with nicely minimized test cases.
Re: Why is the rex.w prefix not generated for certain instructions in inline assembler blocks?
On 9/11/13 9:59 AM, Joseph Cassman wrote:
On Monday, 9 September 2013 at 20:37:47 UTC, Joseph Cassman wrote:
So I'm out of ideas on where the error is coming from. Anyone got any ideas on
what's going on here?
Still not sure what is going on but I found a work-around that somebody else
might find useful.
The mov instruction is able to work with 64-bit values successfully so the
value that is larger than
32 bits can be placed in a register and the register used for the operation.
Here are few examples.
void main()
{
asm
{
mov RAX,0x1UL;
mov R8,0xUL;
and R8,RAX;
xor R8,RAX;
orR8,RAX;
add R8,RAX;
sub R8,RAX;
cmp R8,RAX;
}
}
And their disassembly (excluding the nonessentials).
mov RAX,01h
mov R8,0h
and R8,RAX
xor R8,RAX
or R8,RAX
add R8,RAX
sub R8,RAX
cmp R8,RAX
The only downside of the work-around is that there is already pressure on the
limited number of
registers in x64. Some shuffling might be required.
Joseph
Please file a bug for this. http://d.puremagic.com/issues/
Re: scoped imports
On 8/17/13 5:20 PM, H. S. Teoh wrote: On Sun, Aug 18, 2013 at 01:24:12AM +0200, bearophile wrote: H. S. Teoh: Most of your answer posts break threads. I suggest you to try to find ways to avoid that. [...] Unfortunately, it's not within my control. It's the mailing list to NNTP gateway that has a bug where message IDs are sometimes rewritten when they're not supposed to be. I suggest you should pester the listmaster instead, that way, we'll get a solution that works for everybody, not just for me. :) T Don't pester the list master either, which is me. Get the mailman software fixed.
Re: for loop parens
On 7/12/13 1:46 PM, ixid wrote: They are not issues in Go, but Walter is strongly against optional semicolons, as bearophile said. Me and others (like you) like optional semicolons, but since Walter doesn't and it's his language, that will not change. I personally understand much better the code without semicolons, like in Ruby and Python. And making a parser that way isn't that much difficult, and error recovery is as powerful. Yes, I don't expect anyone to change their opinion though frankly the anti-groups opinions feel more like attachment to the status quo than something that's evidently and demonstrably superior. It seems a pity that D is achieving such power and elegance in some areas while failing to take on some of the syntactic beauty that is within reach. The ultimate language would look something like D crossed with Go in my eyes. It would be interesting if someone were able to make a D subset that showed what it could look like. There is significant value to being easy to read and write, making the language naturally more appealing for users just as speed makes applications much more attractive to users. One person's beauty is another person's ugly. This is an area that reasonable people are going to disagree on. You're feeling on their reasons is rather dismissive.
Re: What xml libraries are people using?
On Sat, 2 Mar 2013, Jesse Phillips wrote: On Saturday, 2 March 2013 at 08:03:08 UTC, simendsjo wrote: Everyone says Don't use std.xml, and there are several other libraries. Which can you recommend? (I haven't looked closely at any of them, just some links found by googling) https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/dom.d http://svn.dsource.org/projects/xmlp/trunk/std/ https://github.com/theredhead/red.xml https://github.com/opticron/kxml https://github.com/opticron/libdxml2 https://launchpad.net/d2-xml I use xmlp, aka d2-xml, aka std.xml2 on Review Queue http://wiki.dlang.org/Review_Queue Source: https://launchpad.net/d2-xml XML is pretty complex so I hope more people try and use so that we can get a nice library into Phobos that will appeal to most people. I don't see Michael Rynn too much on the forms, but he's been pretty receptive when I email him. Has this implementation been bounced off the w3c xml test suite?
Re: Inlining a pure ASM function
On Thu, 28 Feb 2013, Simen Kj?r?s wrote: On Thu, 28 Feb 2013 16:22:49 +0100, D-ratiseur thisadressdoesntex...@nowhere.fr wrote: Hello, Is it possible for an ASM function to be inlined in D? Nope. To be a little more accurate: it's possible in the technical sense. No D compiler today does it automatically. There's no way with DMD to force it, but might be with GDC and/or LDC. The lack of inlining in a number of cases that seem like they should is a quality of implementation issue and not a language definition issue.
Re: Importing problems
On Wed, 13 Feb 2013, jerro wrote: I created self-contained sample.d, ran it with rdmd, then moved class A to sample_a.d and tried to run it with rdmd again. I could reproduce the issue that way. It seems that rdmd caches the dependency list. Using --chatty flag confirms that rdmd does not run dmd to get the dependency list the second time. This solves the issue: rdmd --force sample Please file a bug report on this.
Re: How to read fastly files ( I/O operation)
On Mon, 4 Feb 2013, monarch_dodra wrote: AFAIK, he is reading text data that needs to be parsed line by line, so byChunk may not be the best approach. Or at least, not the easiest approach. I'm just wondering if maybe the reason the D code is slow is not just because of: - unicode. - front + popFront. First rule of performance analysis.. don't guess, measure.
Re: Pull 1019
On Fri, 18 Jan 2013, monarch_dodra wrote: On Friday, 18 January 2013 at 18:35:47 UTC, Namespace wrote: Ok, thanks. But nobody can tell me when and if the pull is merged, right? I think many users here would be pleased if someone could say something to this pull. Not sure what you mean? Nobody will tell you when your pull fails the unittests. When your pull actually gets merged for real into the head, you aren't notified either (sadly), but the puller usually leaves a merged comment, and you get *that* notification. Actually, github _does_ send a notification when the pull is merged. They added that some time ago.
Re: Inner function overload bug?
On 1/10/2013 5:49 PM, Timon Gehr wrote: On 01/08/2013 10:12 PM, Philippe Sigaud wrote: It's conform to the spec http://dlang.org/function.html Last line of the 'nested functions' subsection: Nested functions cannot be overloaded. Nested functions cannot be overloaded. Note that this is a case of the spec being adapted to the implementation. It has been added after I complained about the DMD behaviour. Careful with that sort of logic. Just because the spec was updated such that it matches the implementation does NOT mean that it was because that just happens to be the implementation. It's also likely that it was _intentional_ and had the spec been written first it would have been done the same way. If you want to propose changing the behavior, do that, but don't attempt to blame the implementation as the reason for the spec.
Re: Marking bug entires as fixed/closed on bugzilla
On 12/14/2012 3:47 AM, monarch_dodra wrote: I have a whole list of bugs/issues that have since been corrected in 2.060alpha. I was wondering when and how these were to be closed? Am I supposed to wait for an official 2.061 first? Do I have to prove it was fixed, or just a simple verified fixed comment enough? The pattern we've been following for years is to mark them as resolved/fixed at the point of checkin of the fix. Any bug that's no longer reproducible becomes a judgement call.. either resolved/worksforme or resolved/fixed. If there's reason to believe a specific change caused it to move from broken to fixed, then fixed is more accurate. If it was never confirmed broken then worksforme is more accurate. The more data you have the better, but it's not necessary to make a major time investment. The original reporter can always reopen it and push back. My 2 cents, Brad
Re: static init cycle detection problem
On Thu, 20 Sep 2012, Jonathan M Davis wrote: On Thursday, September 20, 2012 20:49:32 ?ivind wrote: Thanks for the explination. The trick you talk about has worked for me before, but now I really need static init of modules that depend on eachother. Only solution I can think of is to list all modules in a script and generate d code from this to call init functions.. Then pass it to dmd along with the other code. Sad that we can't get this to work like it really should. D is a very flexible language in many ways, and it seems strange that it should not allow the stuff I want to do here.. If you have a true circular dependency, then you're just plain screwed and need to redesign your code. That's fundamental and _can't_ be fixed. Off the top of my head, the only reason that you wouldn't be able to use the trick that std.stdio uses but not have a true circular dependency is if your initializing const or immutable variables in a static constructor. But then the solution is to refactor your code so that you don't have the circular dependency, even if it's just moving those variables into a separate module, which is generally quite feasible, even if it's not necessarily quite what you wanted. - Jonathan M Davis I'm not picking on Jonathan's response, just needed an entry point to the thread... Static initializers are overused in D, particularly phobos and druntime, imho. They're a particular problem when it comes to use in library code. Mixing static and dynamic linkage along with initialization == things break in wierd ways. I'd _much_ rather see them moved into explicit api calls or removed entirely where possible. Every static initializtion is unavoidable (by users of the library) overhead. My 2 cents, Brad
Re: D and SCons [ was Re: bigint - python long ]
On 9/9/2012 1:15 AM, Johannes Pfau wrote: Am Sat, 08 Sep 2012 16:25:49 +0100 schrieb Russel Winder rus...@winder.org.uk: On Sat, 2012-09-08 at 07:20 -0700, Ellery Newcomer wrote: […] Okay, here: https://bitbucket.org/ariovistus/deimos-elfutils/overview I have some code with a working makefile and a nonworking SConstruct file. I believe the issue is the header files have pragma(lib, X) in them, and a single call to dmd links the appropriate lib in, but scons' link step loses that information. Do you have any intention of supporting pragma(lib) in scons? If that is valid Dv2 and SCons doesn't deal with it then the SCons D tools are broken and need fixing. Is there a tiny project replicating this that I can turn into a unit/system test. The red so caused will necessitate action :-) Please note that pragma(lib) is an evil feature. For example it will never work in gdc. It's not impossible and never is rather defeatist. Using the frontend as is and grabing the json output, part of which includes the pragmas, would be easy. Then invoking gdc with the appropriate options to get the library linked in. rdmd is a good example of this sort of process.
Re: float[] → Vertex[] – decreases performance by 1000%
On Wed, 29 Aug 2012, Timon Gehr wrote: On 08/29/2012 01:26 AM, David wrote: Use this to create a minimal test case with minimal user interaction: https://github.com/CyberShadow/DustMite Doesn't help if dmd doesn't crash, or? It doesn't help a lot if compilation succeeds, but you stated that you generally tend to ignore dmd bugs. Most dmd bugs make compilation fail. It's more generally useful than that. It can reduce for any set of commands that together produce a binary decision: pass or fail. The key problem is that it does need to be deterministic. It doesn't matter if it's dmd that fails, or an execution of the output code, or really anything that determines pass or fail. The basic pattern is: while (progress can be made) try a reduction if reduction still reproduces the error continue else revert done (it's obviously more complex and there's tons of magic inside try a reduction)
Re: Tiny/Small C++ libraries
On 8/5/2012 5:19 PM, Jonathan M Davis wrote: Last I heard, it never releases _any_ memory, and the one attempt to fix that via a garbage collector tanked performance. It _is_ something that needs to be sorted out one of these days though. It's often said, and never true. It's patently obvious that it releases memory by simply grepping the source for 'free'.
Re: Tiny/Small C++ libraries
On 8/5/2012 7:09 PM, Jonathan M Davis wrote: On Sunday, August 05, 2012 18:57:07 Brad Roberts wrote: On 8/5/2012 5:19 PM, Jonathan M Davis wrote: Last I heard, it never releases _any_ memory, and the one attempt to fix that via a garbage collector tanked performance. It _is_ something that needs to be sorted out one of these days though. It's often said, and never true. It's patently obvious that it releases memory by simply grepping the source for 'free'. Then why on earth does the memory consumption keep going up and up the more CTFE-related stuff a module is doing. It certainly _looks_ like it doesn't free any of _that_ memory at least, and I've definitely heard that it didn't, but I obviously could have heard wrong. I've never studied the code to figure out what it's doing. - Jonathan M Davis Um, because there's a large amount of room between never releasing any and always releasing everything?
Re: ufcs and integer params
On 7/18/2012 5:30 AM, Adam D. Ruppe wrote: On Wednesday, 18 July 2012 at 11:37:43 UTC, David Nadlinger wrote: Arguments! Yay! I've gone over this a dozen times on the group and on bugzilla, and I'm kinda sick of repeating it. -property breaks craploads of code. That's a huge negative, and nobody has even come close to countering that. -property will be the standard is utterly worthless, yet that's really the only thing I see brought up again. The clear argument for me is that it must be trivial to take an existing member variable and change it to a property function pair _and vice versa_. If someone has @property int foo() and @property void foo(int) as members of a class and call sites add (), then yanking those back to just int foo; will fail, badly. So that must be explicitly disallowed. THAT is the argument for enforcing the lack of parens after properties, imho. The other bits about non-@property functions is significantly less important as far as I'm concerned. My 2 cents, Brad
Re: Is this actually supposed to be legal?
http://en.wikipedia.org/wiki/Curiously_recurring_template_pattern
On 7/16/2012 10:24 PM, Jonathan M Davis wrote:
This code strikes me as being a bug:
class MyBase(T)
{}
class MySubA : MyBase!MySubA
{}
class MySubB : MyBase!MySubB
{}
void main()
{}
but it compiles just fine. However, given the fact that MySubA isn't even
properly defined until its base class has been defined, I don't see how it
could
possibly _not_ be a bug for the base class to be templatized on it. You could
get some really weird behavior if you use compile time reflection on the
derived class in the base class definition.
Does anyone know if this is actually supposed to work? Or is it in fact a bug
like I think it is?
- Jonathan M Davis
Re: D and Programming Theory (Suggestions?)
One really good book I read ages ago that takes the magic away from c++ and talks about how it's translated into an underlying implementation is Inside the C++ Object Model by Stanley Lippman. While it's written with c++ in mind, it's details can be abstracted to just about any object oriented language. Unfortunatly it doesn't get into some of the interesting (to me) lower level details like function prolog/epilogs, argument passing, etc. Those details vary quite a bit between platforms (both os and cpus) since they're among the lowest level details. Another good book that talks about how applications go from bits on disk to running in memory is Linkers and Loaders by John Levine. Neither of those really get into the guts of how computers work. I'll leave that one for Walter to point you to.. I'm sure he's got a favorite 'how x86 works from the inside out' kind of book. If you're particularly interested in the HOW part of how they work, some digital logic classes plus a cpu architecture class would fit the bill nicely. The latter was one of my favorite college courses... designing on paper a simple cpu (address decoders, alu, registers, etc). None of these topics are really 'for dummies' though. I highly suggest gaining some level of comfort working at the high level of writing code before diving deep into the how it works parts. Starting at the bottom could well mean you never get to the point of writing code out of sheer enormity of the details. Later, Brad On Wed, 12 Oct 2011, Louis wrote: Dear Friends, Here is the QUESTION: Does anyone know of any good books that talk about how computers work abstractly enough to be a solid cross language foundation? To put this question another way, I REALLY want to actually understand The D Programming Language by Andrei Alexandrescu. I understand enough of it to be really excited about D, but not enough to start really programming with it. EXPLANATION: I'm new to systems language programming, although I have attempted to self-learn C++ a few times. I had been looking over C, C++ and C#, and there is a tremendous amount of information about those languages available, but on a whim I decided to search and see if there was actually a D programming language. Not only did I find D, but I also found out that it's a relatively new language, and it appears to be cutting edge. From what little knowledge I have about C++ programming, I can already see some serious advantages of putting time and effort into learning D because I think in the long run, it will be worth the effort. Not to mention that D appears to have fixed some really complex, and potentially dangerous issues with C++ - issues that are over my head at the moment - but clearly stated enough that even a noob like me can see some ugly problems coming at me with C++ over the long haul. (Yes, I have crashed windows with bad C++ before). I bought The D Programming Language and have been fascinated by it even though a lot of it is way over my head. As I am pouring over my C++ books and my D book it has become painfully obvious to me that while the syntax of language(s) are unique and important, what is far more important is understanding the computer theories underlying the code. Things like understanding linear programming, OOP, functional programming etc. Also, things like understanding how a computer works internally and how that relates to language (and compilation...). I have made the mistake of trying to understand how a language works through learning its syntax as defining function rather than understanding how function dictates syntax. With a new language like D with few books written on it (actually 2 as far as I can see) it's difficult for a newcomer like me just to jump in. There is no Beginning D or D For Dummies yet. I'm a quick study if I can find a few good books, and that's what I am looking for. Thanks!
Re: const main args?
On Mon, 15 Aug 2011, Timon Gehr wrote:
On 08/15/2011 03:47 PM, Steven Schveighoffer wrote:
On Fri, 12 Aug 2011 17:51:50 -0400, bearophile
bearophileh...@lycos.com wrote:
Steven Schveighoffer:
int main(in string[] args);
What would be the purpose of this?
Why do you use in in function arguments? To make sure you will not
modify the given array. I think it's not good practice to change the
length of the input strings of the main or replace it with another
dynamic array at runtime.
int main(string[] _args)
{
const args = _args; // not modifiable copy
}
It's a very easy problem to solve, and it's not really worth changing
the compiler for IMO.
In other words, it's one of those features that's so trivial that it's
not worth implementing. D cannot always be perfect, and I'd rather we
spend more time on the meaty parts of the language.
-Steve
This is a place where D trivially could be perfect ;). I agree that this issue
has a very low priority. But it should be fixed eventually.
Only if there was actual uniformity in agreement on what perfect is.
There isn't in this case.
Re: Writing .di files duplicate storage
On Monday, August 08, 2011 12:54:00 AM, simendsjo wrote: On 08.08.2011 09:47, Jonathan M Davis wrote: http://d.puremagic.com/issues/show_bug.cgi?id=6360 Thanks. The annoying thing is that I have to manually modify the import library :| Could spend the time fixing dmd instead of working around the bug. I can't guarantee it'll be actually easier to fix it at the source rather than massaging the output, but I do know that the long term result would be more useful. :)
Re: Versioned extern?
On Saturday, July 23, 2011 8:35:39 PM, Nick Sabalausky wrote:
Is there a way to have a section of code be extern(C) on one OS and
extern(Windows) on another OS, without resorting making the code in question
a mixin?
These doesn't appear to work:
--
version(Windows)
{
enum callingConvention = Windows;
}
else
{
enum callingConvention = C;
}
extern(mixin(callingConvention ))
{
/+ ...code here... +/
}
--
version(Windows)
{
extern(Windows):
}
else
{
extern(C):
}
/+ ...code here... +/
extern(D):
--
That specific pair of extern types with that specific set of versions
-- extern(System)
Re: Infinite loop not working DMD2
On 6/2/2011 8:43 AM, Guillermo Estrada wrote:
Hi, been developing in D a lot but first time in news groups, I
thought this might be the place.
I'm trying to make a fork bomb in D (of course no fork cause target
its windows platform) but anyway. I did one a while ago using D1 and
Tango and all ran perfectly, I'm trying to migrate my whole dev to
D2 and Phobos (reading Andrei's book) but this one does not work.
import std.process;
void main(string[] args) {
while( true ) {
execv(args[0], null);
}
}
It spawns one after the other but just once, it always exits the
father process, if u comment the execv line, program stays in the
infinite loop as expected. any insight?
The exec* family of functions cause the new app to replace the current process.
So after the execv, the loop doesn't exist.
Re: Helping the compiler with assumptions while using exceptions
On 5/30/2011 2:55 PM, Jonathan M Davis wrote: I'd be very surprised to see the compiler ever optimize code based on assert or enforce statement. It's unlikely to do so based on assert simply because the assertion is going to be compiled out. I think that there's a high chance that optimizing based on an assertion that is removed in release mode would actually be violating the guarantees of assert, since then the code without it wouldn't act the same. But you'd have to ask Walter on that one. As for enforce, it'll never happen because enforce is a library function, and the compiler doesn't know anything about it. So, I wouldn't expect to ever seen any compiler optimzations based on assert or enforce. - Jonathan M Davis I think you're underselling the possibilities. The only thing preventing enforce from helping optimize in DMD is the lack of inlining of it. That will be improved at some point. Once it's inlined, the rest of the optimizations can easily take advantage of it. There's nothing particularly magic about either assert or enforce. They're just if's and flow control which are an optimizer's bread and butter. Later, Brad
Re: version(all) block in src/phobos/unittest.d unnecessary?
On 5/28/2011 9:03 AM, Dmitry Olshansky wrote: On 28.05.2011 19:54, Andrej Mitrovic wrote: What the heck, I've just opened the linux makefile and it's beautiful compared to the windows one. The windows one is 3x the size. Is this because Linux uses GNU's make perhaps? Don't think so, though admittedly I haven't looked very deep. One reason is that win32 had a collection of workarounds for optlink. And that not counting the sheer verbosity of it. Me thinks that if anyone has the skill to bring to shape win32 makefile that would make an awesome pull request. It is due to the relative primitiveness of the make.exe that walter ships with the windows version of things. It's.. weak.
Re: How to run DMD's tests?
On 4/7/2011 10:17 PM, Nick Sabalausky wrote: Like the subject says. I try to use the makefile, but I keep getting this: Error on line 76: expecting target : dependencies It requires gnu make to run. You can look at the scripts used by the auto-tester here: https://github.com/braddr/d-tester/tree/master/client/src
Re: How do I limit the number of active threads (queuing spawn calls)
On 3/26/2011 7:00 PM, Andrej Mitrovic wrote:
Edit: It looks like I did almost the same as Jonathan advised.
I'm looking forward to std.parallelism though. I'm thinking I'd
probably use some kind of parallel foreach loop that iterates over 4
files at once, and letting it do its work by spawning 4 threads. Or
something like that. We'll see.
The way I've typically done this sort of pattern is with a thread pool that
gets its work from a queue. The main thread
shoves work into the queue and then calls a .join or .waitForEmpty sort of api
on the pool. So it'd look something like:
void workerFunc(string str) { ... }
auto tp = new ThreadPool(getNumCpus(), workerFunc);
foreach(...)
tp.push(str);
tp.join();
This can suffer from queue size problems if the amount of work is awful, but
that's not a problem for the vast majority
of the cases I've had, so never worried about having the push capable of
blocking or otherwise throttling the producer side.
Re: github syntax hilighting
On 1/26/2011 7:13 AM, Steven Schveighoffer wrote: Anyone have any clue why this file is properly syntax-aware: https://github.com/D-Programming-Language/druntime/blob/master/src/rt/lifetime.d but this file isn't https://github.com/D-Programming-Language/druntime/blob/master/src/core/thread.d I'm still not familiar at all with git or github... -Steve I'm going to guess it's filesize. Totally a guess, but consider that adding highlighting costs additional markup. The file that's not highlighted is over 100k, the file that is is only(!) 62k.
Re: Trouble with OPTLINK
On 11/13/2010 1:14 PM, bearophile wrote: Aardvark Soup: I've already tried cleaning up all build files and adding the current directory to the system PATH, both to no avail. This does not happen while I compile single-file programs that import from the standard library. Does anyone have an idea how to fix this? This is a problem that Walter seems to think it doesn't exist. The solution is to add all the module names you use in the command line. Bye, bearophile Interesting way you phrased your response. The behavior of dmd here is explicit and specifically intended. It's exactly the same as every c and c++ compiler's behavior. It's different than java. And interpreted languages are a different enough execution model to not compare them directly. rdmd can be used to build and execute multi-file applications more like traditional scripting languages. Later, Brad
Re: Generic collection/element function signatures in D2 versus D1
On 9/11/2010 9:32 PM, Nick Sabalausky wrote:
Jacob Carlborg d...@me.com wrote in message
news:i5t61q$2j7...@digitalmars.com...
If you're not going to modify the content of the array I think this will
work:
void foo (T) (const(T)[] collection, T elem) {}
This will allow both mutable, immutable and const arrays. But it will not
let you modify the array like this:
collection[3] = 'a';
On DMD 2.048, This isn't working for me:
-
void foo(T)(const(T)[] coll, T elem)
{
}
void main()
{
string x = hello;
foo(x, x[1]);
}
-
Result:
-
testStringAndChar.d(8): Error: template testStringAndChar.foo(T) does not
match any function template declaration
testStringAndChar.d(8): Error: template testStringAndChar.foo(T) cannot
deduce template function from argument types !()(string,immutable(char))
-
I figured that was just because 'const(immutable(T))[]' doesn't make much
sence, so I tried this and got the exact same error messages:
-
import std.traits;
void foo(T)(const(Unqual!T)[] coll, T elem)
{
}
void main()
{
string x = hello;
foo(x, x[1]);
}
-
It seems to be a problem with IFTI, because this does work with both
versions:
foo!char(x, x[1]);
Kind of a pain.
http://d.puremagic.com/issues/show_bug.cgi?id=2594
Re: Exception stack traces on Phobos2? (Win or Lin)
On 9/4/2010 3:14 PM, Nick Sabalausky wrote: Nick Sabalausky a...@a.a wrote in message news:i5ufqs$1v2...@digitalmars.com... Is there a way to get stack traces for exceptions on Phobos2? For either Windows (preferably), or for Linux. Oops, sorry, I completely forgot I asked the exact same thing here little more than a month ago :) But, someone there reported they're getting them in Linux as long as they don't use -release, but on Linux, even with both -debug and -g, I'm just getting meaningless addresses, no names or anything. Progress has been made, but it's slow in coming. Sean just landed a rewrite of the buggy and inefficient std.demangle as core.demangle, an important stepping stone to adding that to the stack trace generator. I'm investigating a couple issues with it right now, in fact. See also: bug 1001 Later, Brad
Re: I don't understand a const
On 9/2/2010 5:59 AM, Simen kjaeraas wrote:
bearophile bearophileh...@lycos.com wrote:
This program doesn't compile, dmd prints the errors:
test.d(4): Error: template test.foo(T) does not match any function template
declaration
test.d(4): Error: template test.foo(T) cannot deduce template function from
argument types !()(const(int),int)
test.d(9): Error: template instance test.bar!(int) error instantiating
Are you able to tell me what is the error in this code?
void foo(T)(const T a, out T b) {}
void bar(T)(const T x, out T y) {
foo(x, y); // line 4
}
void main() {
int s1, s2;
bar(s1, s2); // line 9
}
Bye, and thank you,
bearophile
Simpler test case:
void bar(T)(const T x, out T y) {}
void main() {
const int s1;
int s2;
bar(s1, s2);
}
It seems DMD is confused by const(int) being such a nice fit for the
first parameter. This might have to do with s2 = s1 being ok.
It is probably worth noting that this works:
import std.traits;
void bar(T)(const T x, out T y) {}
void main() {
const int s1;
int s2;
bar!(CommonType!(s1,s2))(s1, s2);
}
http://d.puremagic.com/issues/show_bug.cgi?id=4594
itfi limitation or bug on my part?
module test;
void main()
{
int[] foos;
func1(foos);
}
void func1(T)(const T[] foos)
{
T afoo;
func2(foos, afoo);
}
void func2(T)(const T[] foos, out T afoo)
{
}
$ dmd -c test.d
test.d(12): Error: template test.func2(T) does not match any function template
declaration
test.d(12): Error: template test.func2(T) cannot deduce template function from
argument types !()(const(int[]),int)
test.d(6): Error: template instance test.func1!(int) error instantiating
Ignore style.. this is a massively reduced case from a much more complex block
of code.
Re: Loop optimization
On 5/16/2010 4:15 PM, Walter Bright wrote: bearophile wrote: DMD compiler doesn't perform many optimizations, This is simply false. DMD does an excellent job with integer and pointer operations. It does a so-so job with floating point. There are probably over a thousand optimizations at all levels that dmd does with integer and pointer code. Compare the generated code with and without -O. Even without -O, dmd does a long list of optimizations (such as common subexpression elimination). While it's false that DMD doesn't do many optimizations. It's true that it's behind more modern compiler optimizers. I've been working to fix some of the grossly bad holes in dmd's inliner which is one are that's just obviously lacking (see bug 2008). But gcc and ldc (and likely msvc though I lack any direct knowledge) are simply a decade or so ahead. It's not a criticism of dmd or a suggestion that the priorities are in the wrong place, just a point of fact. They've got larger teams of people and are spending significant time on just improving and adding optimizations. Later, Brad
Re: Latest GDB version problems
On Mon, 10 May 2010, Robert Clipsham wrote: On 10/05/10 19:48, Piotrek wrote: (gdb) info locals i = 1 s = 578159222890430469 f = 9.55146781e-38 (gdb) show language The current source language is auto; currently d. You are not using a version of gdb with D support if s is not displayed as a string. This said, I've only ever looked at variables using print or a backtrace, could you try 'p s' and see what result it gives? If it's the same you aren't using a D capable version of gdb. This said, it should be working in that version of gdb, I guess there's some other issues there if this is the case. Reading symbols from /home/pio/dev/d/projects/cb_test/hello...Segmentation fault This is a gdb issue, not a D issue, you should report this issue to the gdb developers so they can add a test case to their test suite and fix the bug :) Does anyone can work with gdb on linux? I do, and it works great for me :) This said, if you have issues with it it's good to voice them to either the D community or the gdb devs if appropriate so we can work out any issues and make debugging D on linux/freebsd/os x etc a pleasant experience. It isn't right now, but the situation's far better than it was a few weeks ago (it was impossible to do anything non-trivial then :P) Cheers Piotrek For what it's worth, I've still had lots of problems with gdb (from cvs) + dmd from svn. It's certainly LOTS better, but there's lots left to fix. Unfortunatly I haven't spent the time to try to reduce the problem down at all. I'll do that, but just haven't yet. Later, Brad
Re: Memory leak with dynamic array
On Mon, 12 Apr 2010, Joseph Wakeling wrote: Curious question: how come with a registered email address my messages have to be moderated, whereas via the http interface I can post straight away? :-P Best wishes, -- Joe All new subscribers to the lists start off moderated until a post flows through that isn't obvious spam. As soon as I see that, I remove the moderated flag. The list is a much bigger spam target than the news server is. I deflect dozens of spam messages a day, some of which are clever enough to register for the list first (not daily, but probably monthly). Later, Brad
Re: DMD on x86_64
On 2/16/2010 10:05 PM, Jesse Phillips wrote: Robert Clipsham wrote: On 16/02/10 15:20, Jesse Phillips wrote: Robert Clipsham wrote: I don't use ubuntu, so those instructions don't apply to me. I don't either, but the instructions still apply to me. What distro are you using? If you figure it out, write up some instructions for it. I'm using Arch Linux. I've found a gcc-multilib package in AUR ( http://aur.archlinux.org/packages.php?ID=28545 ), it's out of date and doesn't build for me though, it seems to require the de_DE locale too for some unknown reason. I'm hoping when this package is updated it'll do what I need, I'm not holding my breath though. Oh, yeah Arch dropped most efforts to support 32bit didn't they. This probably won't help but maybe trying dmd test.d -L-L/opt/lib32/lib -L-melf_i386 I'd hope that would at least stop it complaining about libpthread. (but so should have your gcc -m32 The other thing you could try is to take dmd out of the loop. Can you build a 32 bit c/c++ app with gcc/g++ directly? If you can't get that to work, it's unlikely that dmd will we successful either, given that it relies on gcc to invoke the linker, picking up all the right c library pieces.
Re: Traced static assert ?
Don wrote: Jacob Carlborg wrote: Is it possible to somehow trace a static assert, just like a backtrace for exceptions ? http://d.puremagic.com/issues/show_bug.cgi?id=2816 Unfortunately Walter rejected it, but gave no clue as to why. Walter, if Don was to update the patch to match the current dmd code and fold the various minor fixes listed in the bug report into it, would you be willing to incorporate the changes? I haven't seen a single person, other than you, question the value of template failure 'stack' traces. - Brad
Re: implicit ubyte casting
On Thu, 1 Oct 2009, Saaa wrote: I think is very bug-prone, isn't it obvious iub should be -5? ubyte ub = 5; int iub = -ub; // iub now is 251 What is the reasoning to do it this way? The inclusion of the 'int' part obscures what I think the real problem is.. Does it make sense to use uniary-minus on a unsigned type? My answer.. no. But the counter argument that will likely come up is generic behavior. So, to prempt that.. does unary minus have any useful meaning for MOST types? My answer is still no. :) Later, Brad
Re: XML D2.x parsing amp;
Jesse Phillips wrote: On Wed, 22 Jul 2009 01:37:38 +0100, Stewart Gordon wrote: Jesse Phillips wrote: According to the documentation having amp; in a tag will be turned to http://digitalmars.com/d/2.0/phobos/std_xml.html#text I observe that this is not the case. And if an attribute contains amp; it is turned into amp;amp; What is the best way to receive the same output for both. The code that follows outputs Attr: What amp;amp; Up Elem: What amp; Up *testfile.xml:* ?xml version=1.0 encoding=utf-8? Tests Test thing=What amp; UpWhat amp; Up/Test /Tests Clearly std.xml is buggy. Correct behaviour would be Attr: What Up Elem: What Up The best place for bug reports is http://d.puremagic.com/issues/ Stewart. http://d.puremagic.com/issues/show_bug.cgi?id=3200 http://d.puremagic.com/issues/show_bug.cgi?id=3201 The xml parsing code in D2 could use some love and care. It was originally written by Janice who seems to have dropped off the face of the planet. It's little more than a first draft with serious performance problems and several important bugs. Anyone want to volunteer to invest some time in improving it? Later, Brad
Re: XML D2.x parsing amp;
Jarrett Billingsley wrote: On Tue, Jul 21, 2009 at 11:53 PM, Brad Robertsbra...@puremagic.com wrote: Jesse Phillips wrote: On Wed, 22 Jul 2009 01:37:38 +0100, Stewart Gordon wrote: Jesse Phillips wrote: According to the documentation having amp; in a tag will be turned to http://digitalmars.com/d/2.0/phobos/std_xml.html#text I observe that this is not the case. And if an attribute contains amp; it is turned into amp;amp; What is the best way to receive the same output for both. The code that follows outputs Attr: What amp;amp; Up Elem: What amp; Up *testfile.xml:* ?xml version=1.0 encoding=utf-8? Tests Test thing=What amp; UpWhat amp; Up/Test /Tests Clearly std.xml is buggy. Correct behaviour would be Attr: What Up Elem: What Up The best place for bug reports is http://d.puremagic.com/issues/ Stewart. http://d.puremagic.com/issues/show_bug.cgi?id=3200 http://d.puremagic.com/issues/show_bug.cgi?id=3201 The xml parsing code in D2 could use some love and care. It was originally written by Janice who seems to have dropped off the face of the planet. It's little more than a first draft with serious performance problems and several important bugs. Anyone want to volunteer to invest some time in improving it? I don't mean to shoot down the idea? But Tango already has three XML parsers which are, like, the fastest. Ever. http://dotnot.org/blog/archives/2008/03/04/xml-benchmarks-updated-graphs/ I'm just saying, it'd seem like pointless duplication of effort with such parsers _already available_. If it could be relicensed, I'd say that's the best route. Relicensed and separable from the rest of Tango. It's been way too long since I looked at that code in Tango to recall any of its details. Basically I agree with you on this one. :)
Re: Valgrind D
Sean Kelly wrote: Stefan Rohe wrote: Hi, has anybody experience with the usage of valgrind and D? We are here using DMD (dmd 1.033/tango 0.997 but also some older versions) and got problems using valgrind on this. It seems that the _d_newarrayT routine or something under it jumps or moves on unitialized value(s). The last time I looked into this, Valgrind was wrong about these cases--initialization is actually logically guaranteed. You can check for yourself though. See lib/compiler/dmd/lifetime.d. I spent a good looking at similar reports a few years ago. The cause, at the time, was that the gc code walks the stack(s) during collections and has to examine every stack slot since it has no way of knowing anything about which slots are valid and which aren't. Valgrind, on the other hand, does know what stack slots have been assigned values and which haven't so can accurately report that the program has looked at memory that hasn't been initialized yet. One 'fix' might be to pre-initialize the stack with 0's upon function entry. I'm not even terribly convinced that'd work. Later, Brad
Re: enum to string
On Thu, 12 Mar 2009, BCS wrote: Reply to Lionello, cr*p, I've pasted too little. Try this one instead.. I'll use a proper diff tool next time.. you client is messing with you, paste-bin the sucker or add it to a bugzilla item Just to be sure the two don't get combined (I know you didn't say to do both, just making sure), please don't paste-bin stuff for bug reports. Either put it directly in a comment or attach it as a patch. While paste-bin's aren't super ephemeral, there's no good reason to have thing disconnected from the bug like that. That said, I don't think this really helps the desired usecase much. It's useful, don't get me wrong, but still requires code to build up the bi-directional translations. Or am I missing something? Seems to be happening to me a lot lately, so I'm very prepared to be wrong here too. :) Later, Brad
Re: casting int[] to bool[]
Bill Baxter wrote: On Thu, Jan 29, 2009 at 12:04 PM, Jarrett Billingsley jarrett.billings...@gmail.com wrote: On Wed, Jan 28, 2009 at 9:57 PM, Bill Baxter wbax...@gmail.com wrote: It's just that casting is a very blunt tool and should be avoided whenever possible, because the compiler won't tell you if you're doing something completely crazy. Here you could use somethign like: dataIn[i][index] = (t!=0); instead of casting. Blunt? Pfah! cast(bool)int is well-defined. ;) Just you're more likely to catch an error if t changes from being an int to something else later on. I wish D had a tame and well-behaved casts only please kind of cast. :-( --bb Oh, hey, that reminds me.. Walter! When are we going to get the equivalent to const_cast? And the related restriction that cast can't alter constness? I've already made the mistake at least once changing type and constness, without meaning to do the latter, at the same time. Thanks, Brad
