The autotester has been showing a broken dmd testsuite for a while:
http://d.puremagic.com/test-results/
Any bugzilla entry/pull request I may have missed?
I somehow hit a bug where dmd deadlocks within Mem::Free if I use
-inline. With previous bugs I was able to reduce my code using DustMite
but with this one it is hard because dmd gives no output and just
freezes. Any ideas how I could reduce my code?
You could play with DustMite + timeout.
I can't believe I'm saying this, but I can't wait for my next ICE to
try it out. :p
Me too :D
Here's one for DMD 2.057. Knock yourself out ;)
(As I mentioned in my other post, I can't build DustMite right now, or
I'd do it myself. But if you want one...)
--
chad@Hugin ~/dprojects/database $ dmd ice.d
entity.(fld)
Internal error: e2ir.c 683
If it's because my compiler is a version behind, then don't worry about
it too much.
Yep it uses the new => syntax.
Kudos!
Yep there also is a kernel in D: http://wiki.xomb.org
http://twitter.com/#!/ID_AA_Carmack/status/173111220092682240
Unfortunately plenty of 64Bit errors again :/
I played with some algorithms today and got about a 7x improvement in
reduction time for my test case. The data is now arranged into a binary
tree, and the progress indicator was changed to reflect that. Let me
know if I broke anything in the process.
Hooray, DustMite ftw!
1) Is there a chance that dmd will support 64 bit on windows any time
soon?
No. gdc will remain the only option for quite a while. But that's better
than dealing with optlink anyway.
3) Am I mistaken or are most of the people here using dmd under linux?
Yeah, definitely more of a pleasur
Because then you _have_ to have a variable to call the function - except
for the bizarre situation that struct literals have where they're
considered
lvalues (very bad idea IMHO). I think that from the perspective of most
programmers, the fact that const ref doesn't take rvalues is a major
n
I _think_ that the issue was that Walter had
implemented it as a template thing, and it was supposed to work in
general, but I'm not sure.
How could it ever work without being a template?
It's supported in C++, isn't it supported by D?
Andrei once said it was already a bad idea in C++.
why is allowing temporaries bind to ref const params bad again?
bernardh commented that they might not have an address, e.g. cause of
being in a register.
I posted this question several times already and no answer yet,
why is allowing temporaries bind to ref const params bad again?
report @ the bitbucket project site.
|-bin (64-bit version of dmd, impcnvgen, idgen, optabgen, plus
dmd.conf)
^^ You don't need impcnvgen, idgen and optabgen.
Unfortunately the conclusion was that it would be to difficult an
undertaking to be realistic, since DMD is designed to be run-and-done
(also something about "Walter code" :-)). But maybe a rewrite/port of
DMD, especially one written in D, might be able to be reworked with this
goal in mind
it would be nice to have something like current github builds
was there an attempt to implement such a service?
Well there's the autotester: http://d.puremagic.com/test-results/
So they are indeed built but not packaged/downloadable.
Maybe there's some IDE that can make use of this.
"Unfortunately" VisualD already has its own ;)
But things like shared libraries that will become necessary once it
becomes mainstream. Lack of shared library support is one of the
barriers to it becoming mainstream (among many other things).
Support for that is almost ready even in dmd.
You were talking about making phobos shared and that's
The same has to happen with druntime and Phobos2 or otherwise our
programs will break with every new release that deprecates or changes
non-template functions. That would probably be *every* release at the
moment, so it could look like this:
/usr/lib64/libphobos2.so (link to /usr/lib64/l
The autotester hasn't revealed this cause it still uses the old g++4.2
on OSX.
Apple switched to Clang just recently.
"gcc" on OS X 10.7, which I am using, defaults to using clang. So I am
using clang on a regular basis, and have not seen issues.
It's a really small corner case.
Here's a f
Found out I forgot something in the makefile (such hardcoding really
sucks!):
strtold.o: $C/strtold.c
- gcc -m$(MODEL) -c $<
+ clang -m$(MODEL) -c $<
But it still fails.
btw, another improvement would be precise time information, i.e. incl. the
time zone.
Also they should be consistent. It seems to me like
http://d.puremagic.com/test-results/pulls.ghtml uses a different time than
a single result like
http://d.puremagic.com/test-results/pull.ghtml?runid=4722
Can anyone confirm this?
If yes, bug in clang, dmd or phobos?
Note that the dmd testsuite passes for me.
I changed posix.mak as follows to compile with svn clang:
-HOST_CC=g++
+HOST_CC=clang++
-WARNINGS=-Wno-deprecated -Wstrict-aliasing
+WARNINGS=-Wno-deprecated -Wstrict-aliasing -Wno-logical-op-parentheses
-GFLAGS = $(WARNINGS) -D__near= -D__pascal= -fno-exceptions -O2
+GFLAGS = -x c++ $(WARNINGS
My current thinking is that I'll first write a
greasemonkey script that integrates the tester results into github so
that there's visibility of the current state
along-side the pull itself.
Sounds promising.
It's a security measure to avoid building just any random bit of code
that happens
http://d.puremagic.com/test-results/pulls.ghtml
I've seen several suggestions in an older thread to improve the tester
like posting notifications about failing tests to the corresponding pull
request.
Any plans for that?
Also why aren't all pull requests tested there?
On Saturday, 28 January 2012 at 00:59:17 UTC, Trass3r wrote:
I guess weak linking could be easily achieved with gdc's pragma
setattribute weak.
But what about dmd? (Or ldc?)
And is it also possible on Windows?
anyone?
Am I mistaken? If no, am I missing some major spaces
advantages? If no, lets use tabs. Perhaps, there is no tool
that will convert (convert right, not somehow, see article)
tabs<->spaces in D code.
There wouldn't be any problem if people were able to use tabs for
indentation and spaces for al
Personally, I've never understood how anyone can stand anything
other than Allman.
Totally agree.
export on a function declaration means dllimport for exactly that purpose
(.di files).
It's not mentioned at the attributes doc site but I'm sure I read it
somewhere else.
http://www.d-programming-language.org/dstyle.html in regard to
indent-style, can someone shed some light what is recommended practice
for it within D community?
Everyone thinks his way is the best.
Am 29.01.2012, 12:34 Uhr, schrieb Gour :
On Sun, 29 Jan 2012 12:21:35 +0100
Alex Rønne Petersen wrote:
Phobos generally uses 4-space indentation.
That is mentioned in the style-guide, but I'm curious about bracing,
iow, GNUstyle, K&R, ANSI...?
Some people seem to use that godawful BSD KNF
No it's not. Your sample won't compile with -property. That's why I've
wrapped it into a template, to avoid having to use parens.
Never used -property.
I don't mind adding parentheses either.
Fair enough. But if we're going to be anal about it you should add a
constraint `if (is(EnumType == e
The following is a better solution, and should probably be in the
standard library.
..
(could be mixin(exposeEnumMembers!UITableViewRowAnimation); )
That's what I already do.
The whole point of the thread is to get rid of that crap after each enum.
import std.conv;
import std.traits;
string exposeEnumMembersImpl(T)()
{
string result;
foreach (member; EnumMembers!UITableViewRowAnimation)
result ~= "alias " ~ to!string(T.stringof) ~ "." ~
to!string(member) ~ " " ~ to!string(member) ~ ";\n";
return result;
}
template expos
When I build my code, I notice that the CTFE functions, which are never
referenced in any runtime code, are still present in the object file.
For now you can get rid of it with -L--gc-sections (or LTO).
gdc also needs -ffunction-sections -fdata-sections.
I guess weak linking could be easily achieved with gdc's pragma
setattribute weak.
But what about dmd? (Or ldc?)
And is it also possible on Windows?
"What's the alternative to Qt in D?" should not be "Qt bindings" but
maybe a library which imitates the implementation and/or interface of
Qt UI widgets in native D.
http://www.ohloh.net/p/qt/estimated_cost
some scary numbers
http://www.ohloh.net/p/qt5
dmd could really learn a thing or two
extern(C):
enum Bla : int {...}
void foo(Bla b);
How does this require implicit conversion?
The codegen treats Bla like basetype anyway.
Some of the Windows functions are made of multiple enums of different
types, ORed together.
-.- Microsuckx.
Then I think it should either become a combine
Is there any merit in having implicit conversion to the basetype?
Allowing it to be used as an argument when calling C functions?
extern(C):
enum Bla : int {...}
void foo(Bla b);
How does this require implicit conversion?
The codegen treats Bla like basetype anyway.
What about be able to do something like this:
enum Foo
{
public:
bar,
fooBar,
}
Foo f = bar;
public is the wrong keyword. Furthermore, the solution is not better
than mixin Import!Foo; I think the extern(C) enum proposal is pragmatic
and makes more sense.
+1
If your binding is for yourself, that's not a big deal. But if you're
putting it out there for public consumption, then I think compatibility
with the C version would be more important. If someone is looking at
sample C code, you should make it they don't need to adjust it much
Yep, one big
`typedef' is or will be disallowed in D because of reasons I do not
understand.
It's ill-defined. There are 4 possible types of typedef:
http://d.puremagic.com/issues/show_bug.cgi?id=5467
In C and C++ their existence introduce problems because
they increase the amount of parsing passes.
C
I have argued for banning those operations on strong enums before, but
some objected to it because they wanted to use strong enums as bit flags.
Yep, that's what the other thread 'using enums for flags' is about.
But implicit conversions seem wrong in any case.
Ok,Thanks for clarification! Seems that DStep is a missing link
in the D tool-chain and should be part of the DMD package
I'll try DStep ASAP on libxml2 and libxslt. Will let you know
how it works for me.
I don't think it's in a usable state yet.
I guess SWIG could be useful currently.
Is there any merit in having implicit conversion to the
basetype?
Yes. Otherwise it would be at least close to equivalence to a
`typedef'.
Even typedef implicitly converts in one of the directions.
A named enum is a separate type with a finite set of allowed
values defined by the user.
Sorry for my ignorance but why should one use DStep instead of
htod in order to port plain vanilla C headers ? I have to
admit that I haven't tried DStep yet.
htod is Windows-only.
And it sucks.
For example it drops const, runs the preprocessor instead of
turning preprocessor directives into
On Thursday, 26 January 2012 at 14:45:02 UTC, Manfred Nowak wrote:
Trass3r wrote:
but by using named enums I made clear that Bla and Blub are
totally different
No. Obviously you decjlared both to be implicitely convertable
to a common super type: int. To change this, both supertypes
have
I thought it'd be good to outsource this question from the other
thread about enums as flags.
Is there any merit in having implicit conversion to the basetype?
Imo it only introduces a severe bug source and brings no
advantages.
For example it allows implicit conversion to bool.
enum Bla
{
It's not type safe in C. But you can wrap it in a struct with
alias this instead.
Yep, but in D we have strong enums, so why not use them.
I agree, enum variable should only contain one of the
enumerated values. Here's an example how current way may lead
to unexpected result:
enum Foo { A = 1, B }
void bar( Foo foo ) {
final switch( foo ) {
case Foo.A:
writeln( "A" );
return;
case Foo.B:
Or if you absolutely need both type safety and the values to
live in the outer scope, you can do this:
enum Something
{
SomethingPointy,
SomethingSmooth,
}
alias Something.SomethingPointy SomethingPointy;
alias Something.Som
Are the Clang C bindings complete? I imagine they don't get
that much attention.
It depends on what complete means. If you mean that you can do
all the things you can do with the C++ API, then no. If you
mean it's complete enough to implement this project, then I
don't know. I think at least
Often C enum value naming takes into account that they'll live
in the outer scope. For instance:
enum UITableViewRowAnimation {
UITableViewRowAnimationFade,
UITableViewRowAnimationRight,
UITableViewRowAnimationLeft,
UITableViewRowAnimationTop,
You can use anonymous enums. The members will then live in the
global scope. You can then use just one alias to an int, uint
or what's appropriate.
Yeah but you loose type safety.
When writing C bindings I usually create lots of aliases via a
string mixin to pull enum members into the enclosing scope so
it's compatible to C.
Would it be wise to let the compiler do this automatically for
extern(C) enums?
I think that it makes sense to use enums as flags, but I do _not_ think
that it makes sense to use an enum as the type of the variable _holding_
the flags.
STC var = STC.A & STC.B;
We could easily introduce @flags enum or whatever to make it more clear
like in C#.
just makes it worse.
In the codebase I have to work with, having the same enum specified in
different places is rather common. Yeah, I hate it. This means I might
have a filter defined using one enum, and the value to filter being a
different type with the same values.
Why don't you fix it then?
Yeah, while refusing to implement most of C++11.
To be fair, they did implement a big part of the library.
I care more about long overdue language changes like non-static member
initializers.
But I do share your opinion here. I hate the way that Microsoft
cherry picks the C and C++ standa
Good! The C++11 committee should be shot. They've got it completely
wrong, and MS have it right for my money! :)
I don't want MORE STL, I want less :)
C++11 contains important stuff like "for each", auto and #1: non-static
member initializers.
Does it really make sense to allow bitwise operations on different
enums?
Maybe. Certainly sometimes
Examples please.
but those could just as easily use casts.
Seconded.
I generally don't see any merit in letting enums *implicitly* convert to
their base type.
There is no obvious finer-grained separation of modules, so including
only a part of them would need to be done on mostly subjective decisions.
Yep, Walter just added what he used.
Whats.necessary to use D in order to create C++ bindings ?
I forgot SWIG.
I'm trying to reimplement the code as a separate tool in D using the
Clang C bindings. So far it's not working out that well, there's not
much documentation available.
Are the C bindings complete? I imagine they don't get that much attention.
For some reason your messages never have the proper position (i.e. they
aren't connected with the post the respond to) in the message tree.
This is fairly interesting. MS have extended their C++ compiler
significantly for Windows8 with a bunch of non-standard stuff.
Yeah, while refusing to implement most of C++11.
Even if you paint shit yellow it's not necessarily gold.
:D
Sorry, but it's needed for some ancient platform D has never and
will never exist/ed on in.
What platform is that?
I assume you mean the windows one? dmc is fast enough that recompiling
takes very little time, especially compared to running the test suites.
Nope, Linux.
iirc Walter's complaint is that the makefiles quickly get out of sync
anyway, so it's a better habit to use make clean constantly regardl
So I was just reading
http://stackoverflow.com/questions/1448396/how-to-use-enums-as-flags-in-c
And did a quick test:
enum STC
{
A = 0x1,
B = 0x2,
C = 0x4
}
enum FOO
{
F = 0x8,
G = 0x10
}
void main()
{
STC s = STC.A | STC.C;
STC s2 = s &
Whats.necessary to use D in order to create C++ bindings ?
github.com/jacob-carlborg/dstep
Run a clean build and test every so often (several times per hour) but
MOST builds should be incremental so as to be as fast as can be managed.
Yep, even Clang needs half a minute to do a full build for me.
Am 25.01.2012, 08:36 Uhr, schrieb Rainer Schuetze :
A simple and effective way to do it with gcc is to generate dependency
files (*.dep) during compilation with -MD/-MF and include these into the
makefile with
-include *.dep
That sounds sound :)
Exactly. Even a capital .C is recognized as C++ source code if .cpp isn't
desired.
Is there any makefile guru who could (maybe use some fancy tool to) fix
the dependencies?
Having to recompile everything for each small change is annoying.
Should aliases be allowed to raise the accessibility of a symbol?
Yeah I do use that by having a private template function and public
aliases to certain instances.
It's really annoying. clang++ gives a lot of warnings and IDEs are
confused as well.
Queue Walter saying that it's needed for some ancient platform D has
never and will never exist/ed on in three... two...
:D
It's really annoying. clang++ gives a lot of warnings and IDEs are
confused as well.
Adapt the bot or configure your client to ignore the bot. Plain simple.
Alternatively, you could just program CGI in D.
This is about client-side.
Just discovered this LLVM-to-Javascript translator: http://emscripten.org/
Looks really interesting, they even converted CPython.
Might be interesting for D as well.
Question is how the low-level stuff in druntime would work out.
D2 only.
No point in supporting D1.
sizediff_t or ptrdiff_t I think
Or they're on windows.
No excuse. Now there are prebuilt gdc packages :)
Couldn't it be handled by a special switch on 64 bit compilers, and
disabled normally?
Theoretically yes, but it would destroy the original intention.
Ensuring 64 bit compatibility is as easy as compiling with -m64 from time
to time, but some people can't be bothered.
They won't use a new sw
Generating C functional wrappers is already pretty cool, but the
fantastic news is SWIG output! As you may have noticed, SWIG has D
support. Means : No need to manually re-create C++ classes in D.
Does SWIG D support static linking by now?
Could we please have at least a warning if code isn't compatible with
64Bit?
It's really annoying to test out some code and having to fix a bunch of
stupid uint->size_t bugs just because the author is still on a 32 bit
machine.
Is that feasible?
I'm unfamiliar with the reason for C++ having a standard library as well
(which I bring up when people bitch about poor design or something
similar which I usually get no viable or any answer at all). More of an
ignorant question probably but oh well...
:D
Do you know what a chaos there was
dmd -c test.d && gcc test.o -lphobos2 -lrt -lpthread -o testgcc
vs
dmd -c test.d && dmd test.o -oftestd
Well dmd test.d calls
gcc test.o -o test -m64 -Xlinker -L/dmd/linux/lib64 -Xlinker
-L/dmd/linux/lib32 -Xlinker --no-warn-search-mismatch -Xlinker
--export-dynamic -lphobos2 -lpthread -lm -
Configuration:
Ubuntu 11.10 64bit
DMD64 D Compiler v2.056
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)
? dmd also uses ld to link.
Am 17.01.2012, 01:49 Uhr, schrieb Daniel Green :
I'm running across version( Win32 ) in phobos. Often the code is
perfectly valid for Win64 as well.
Is it acceptable to replace version( Win32 ) with version( Windows )?
Yep.
DMD patch against commit c50eb5f (from December 31): http://j.mp/xdI0hb
Druntime Github fork: https://github.com/IgorStepanov/druntime
Why the heck isn't the dmd patch a fork as well?
On Tuesday, 10 January 2012 at 09:27:03 UTC, deadalnix wrote:
Le 09/01/2012 19:19, Trass3r a écrit :
On Monday, 9 January 2012 at 18:04:58 UTC, Michel Fortin wrote:
Or maybe it should be a pragma instead.
Interesting idea. But how to do it properly?
A namespace or a class may have lots of
On Tuesday, 10 January 2012 at 12:09:14 UTC, Michel Fortin wrote:
Another idea which would be much less verbose:
extern(C++, gccmangle)
void foo();
Here, gccmangle is a CTFE-capable function that'd be called
like this:
gccmangle("foo");
So if you need a namespace arg
On Monday, 9 January 2012 at 18:04:58 UTC, Michel Fortin wrote:
Hmm another difficulty is how to switch between mangling
schemes.
One thing that could be done is instead of the namespace
argument, have a mangled name argument. Then use CTFE to build
the mangled name (if you want to).
This w
I'm sure it's possible, but it would need some pretty powerful
global expression analysis.
Ie, if data initialised in static this() is only touched in one
function
lets say, and that function is never referenced, then it should
surely be
able to safely eliminate that function and associated dat
101 - 200 of 842 matches
Mail list logo
