Re: GC vs. Manual Memory Management Real World Comparison
On 2012-09-07 01:53, Sean Kelly wrote: What version flags are set by GDC vs. DMD in your target apps? The way stop the world is done on Linux vs. Windows is different, for example. He's using only Windows as far as I understand, GDC MinGW. -- /Jacob Carlborg
Re: GC vs. Manual Memory Management Real World Comparison
On Thursday, 6 September 2012 at 20:44:29 UTC, Walter Bright
wrote:
On 9/6/2012 10:50 AM, Benjamin Thaut wrote:
I just tried profiling it with Very Sleepy but basically it
only tells me for
both versions that most of the time is spend in
gcx.fullcollect.
Just that the GDC version spends less time in gcx.fullcollect
then the DMD version.
Even so, that in itself is a good clue.
my bet is on, cross-module-inlining of bitop.btr failing...
https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gcbits.d
version (DigitalMars)
{
version = bitops;
}
else version (GNU)
{
// use the unoptimized version
}
else version (D_InlineAsm_X86)
{
version = Asm86;
}
wordtype testClear(size_t i)
{
version (bitops)
{
return core.bitop.btr(data + 1, i); // this is faster!
}
Re: GC vs. Manual Memory Management Real World Comparison
On 7 September 2012 07:28, Sven Torvinger s...@torvinger.se wrote:
On Thursday, 6 September 2012 at 20:44:29 UTC, Walter Bright wrote:
On 9/6/2012 10:50 AM, Benjamin Thaut wrote:
I just tried profiling it with Very Sleepy but basically it only tells me
for
both versions that most of the time is spend in gcx.fullcollect.
Just that the GDC version spends less time in gcx.fullcollect then the
DMD version.
Even so, that in itself is a good clue.
my bet is on, cross-module-inlining of bitop.btr failing...
https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gcbits.d
version (DigitalMars)
{
version = bitops;
}
else version (GNU)
{
// use the unoptimized version
}
else version (D_InlineAsm_X86)
{
version = Asm86;
}
wordtype testClear(size_t i)
{
version (bitops)
{
return core.bitop.btr(data + 1, i); // this is faster!
}
You would be wrong. btr is a compiler intrinsic, so it is *always* inlined!
Leaning towards Walter here that I would very much like to see hard
evidence of your claims. :-)
On a side note of that though, GDC has bt, btr, bts, etc, as
intrinsics to its compiler front-end. So it would be no problem
switching to version = bitops for version GNU.
--
Iain Buclaw
*(p e ? p++ : p) = (c 0x0f) + '0';
Re: GC vs. Manual Memory Management Real World Comparison
You can find the full article at: http://3d.benjamin-thaut.de/?p=20#more-20 You make some good points about what happen under the hood. Especially: - homogeneous variadic function call allocate - comparison of const object allocate - useless druntime invariant handlers calls I removed some homogeneous variadic function calls from my own code.
Re: GC vs. Manual Memory Management Real World Comparison
Benjamin Thaut wrote: I rewrote a 3d game I created during my studies with D 2.0 to manual memory mangement. If I'm not studying I'm working in the 3d Engine deparement of Havok. As I needed to pratice manual memory management and did want to get rid of the GC in D for quite some time, I did go through all this effort to create a GC free version of my game. The results are: DMD GC Version: 71 FPS, 14.0 ms frametime GDC GC Version: 128.6 FPS, 7.72 ms frametime DMD MMM Version: 142.8 FPS, 7.02 ms frametime Interesting. What about measuring a GDC MMM version? Because I wonder what is the GC overhead. With DMD it's two. Maybe that factor is lower with GDC. I would be interested in some numbers regarding memory overhead. To get a more complete picture of the impact on resources when using the GC. Jens
Re: GC vs. Manual Memory Management Real World Comparison
On 9/6/2012 11:47 PM, Iain Buclaw wrote: On a side note of that though, GDC has bt, btr, bts, etc, as intrinsics to its compiler front-end. So it would be no problem switching to version = bitops for version GNU. Would it be easy to give that a try, and see what happens?
Re: GC vs. Manual Memory Management Real World Comparison
On 7 September 2012 10:31, Walter Bright newshou...@digitalmars.com wrote: On 9/6/2012 11:47 PM, Iain Buclaw wrote: On a side note of that though, GDC has bt, btr, bts, etc, as intrinsics to its compiler front-end. So it would be no problem switching to version = bitops for version GNU. Would it be easy to give that a try, and see what happens? Sure, can do. Give me something to work against, and I will be able to produce the difference. -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: GC vs. Manual Memory Management Real World Comparison
On 9/7/2012 2:52 AM, Iain Buclaw wrote: On 7 September 2012 10:31, Walter Bright newshou...@digitalmars.com wrote: On 9/6/2012 11:47 PM, Iain Buclaw wrote: On a side note of that though, GDC has bt, btr, bts, etc, as intrinsics to its compiler front-end. So it would be no problem switching to version = bitops for version GNU. Would it be easy to give that a try, and see what happens? Sure, can do. Give me something to work against, and I will be able to produce the difference. Well, gdc with and without it!
Re: GC vs. Manual Memory Management Real World Comparison
On Sep 6, 2012, at 10:57 PM, Jacob Carlborg d...@me.com wrote: On 2012-09-07 01:53, Sean Kelly wrote: What version flags are set by GDC vs. DMD in your target apps? The way stop the world is done on Linux vs. Windows is different, for example. He's using only Windows as far as I understand, GDC MinGW. Well sure, but MinGW is weird. I'd expect the Windows flag to be set for MinGW and both the Windows and Posix flags set for Cygwin, but it seemed worth asking. If Windows and Posix are both set, the Windows method will be used for stop the world.
Re: GC vs. Manual Memory Management Real World Comparison
Am 07.09.2012 01:53, schrieb Sean Kelly: On Sep 6, 2012, at 10:50 AM, Benjamin Thaut c...@benjamin-thaut.de wrote: Am 06.09.2012 15:30, schrieb ponce: The problem with intstrumentation is, that I can not recompile druntime for the MinGW GDC, as this is not possible with the binary release of MinGW GDC and I did not go thorugh the effort to setup the whole build. I'm open to suggestions though how I could profile the GC without recompiling druntime. If someone else wants to profile this, I can also provide precompiled versions of both versions. You don't necessarily need to recompile anything with a sampling profiler like AMD Code Analyst or Very Sleepy I just tried profiling it with Very Sleepy but basically it only tells me for both versions that most of the time is spend in gcx.fullcollect. Just that the GDC version spends less time in gcx.fullcollect then the DMD version. As I can not rebuild druntime with GDC it will be quite hard to get detailed profiling results. I'm open for suggestions. What version flags are set by GDC vs. DMD in your target apps? The way stop the world is done on Linux vs. Windows is different, for example. I did build druntime and phobos with -release -noboundscheck -inline -O for DMD. For MinGW GDC I just used whatever version of druntime and phobos came precompiled with it, so I can't tell you which flags have been used to compile that. But I can tell you that cygwin is not required to run or compile, so I think its not using any posix stuff. I'm going to upload a zip-package with the source for the GC version soon, but I have to deal with some licence stuff first. Kind Regards Benjamin Thaut
Re: GC vs. Manual Memory Management Real World Comparison
On 9/7/12 6:31 PM, Benjamin Thaut wrote: I did build druntime and phobos with -release -noboundscheck -inline -O for DMD. For MinGW GDC I just used whatever version of druntime and phobos came precompiled with it, so I can't tell you which flags have been used to compile that. But I can tell you that cygwin is not required to run or compile, so I think its not using any posix stuff. I'm going to upload a zip-package with the source for the GC version soon, but I have to deal with some licence stuff first. Kind Regards Benjamin Thaut You mentioned some issues in Phobos with memory allocation, that you had to replace with your own code. It would be awesome if you could post more about that, and possibly post a few pull requests where directly applicable. Thanks, Andrei
Re: GC vs. Manual Memory Management Real World Comparison
Am 07.09.2012 18:36, schrieb Andrei Alexandrescu: You mentioned some issues in Phobos with memory allocation, that you had to replace with your own code. It would be awesome if you could post more about that, and possibly post a few pull requests where directly applicable. Thanks, Andrei Let me give a bit more details about what I did and why. Druntime: I added a reference counting mechanism. core.refcounted in my druntime branch. I created a reference counted array which is as close to the native D array as currently possible (compiler bugs, type system issues, etc). also in core.refcounted. It however does not replace the default string or array type in all cases because it would lead to reference counting in uneccessary places. The focus is to get only reference couting where absolutly neccessary. I'm still using the standard string type as a only valid for current scope kind of string. I created a allocator base interface which is used by everything that allocates, also I created replacement templates for new and delete. Located in core.allocator I created a new hashmap container wich is cache friendly and does not leak memory. Located in core.hashmap I created a memory tracking allocator in core.allocator which can be turned on and off with a version statement (as it has to run before and after module ctors dtors etc) I changed all parts of druntime that do string processing to use the reference counted array, so it no longer leaks. I made the Thread class reference counted so it no longer leaks. I fixed the type info comparsion and numerous other issues. Of all these changes only the type info fix will be easily convertible into the default druntime because it does not depend on any of my other stuff. I will do a merge request for this fix as soon as I find some time. Phobos: I threw away most of phobos because it didn't match my requirements. The only modules I kept are std.traits, std.random, std.math, std.typetuple, std.uni The parts of these modules that I use have been changed so they don't leak memory. Mostly this comes down to use reference counted strings for exception error message generation. I did require the option to specify a allocator for any function that allocates. Either by template argument, by function parameter or both, depending on the case. As custom allocators can not be pure this is a major issue with phobos, because adding allocators to the functions would make them unpure instantly. I know about the C-Linkage pure hack but its really a hack and it does not work for templates. So I think most of my changes are not directly applicable because: - You most likely won't like the way I implemented reference counting - You might won't like my allocator design - My standard library goes more into the C++ direction and is not as easly usable as phobos (as performance comes first for me, and usability is second) - All my changes heavily depend on some of the functionality I added to druntime. - The neccessary changes to phobos would break a lot of code because some of the function properties like pure couldn't be used any more, as a result of language limitations. Kind Regards Benjamin Thaut
Re: What are the differences between these forms of function-like declarations ?
On Thursday, 6 September 2012 at 06:41:37 UTC, Ali Çehreli wrote:
On 09/05/2012 11:31 PM, Anderel Cerol wrote:
On Thursday, 6 September 2012 at 05:18:24 UTC, Anderel Cerol
wrote:
a real example is :
import std.net.curl;
auto http=HTTP();
...
http.onReceiveStatusLine(...);
...
the function http.onReceiveStatusLine(...) is exactly what
the
function on(...) is above.
The environment is dmd 2.060 Windows.
plus, what passes to the http.onReceiveStatusLine is just
(a){a.writeln();} with different forms above.
by the way ,std.functional.toDelegate doesn't work as UFCS
style,why ?
Can you be more specific please: What doesn't work? The
following code is slightly modified from toDelegate's
documentation, demonstrating that it indeed does work with UFCS:
import std.stdio;
import std.functional;
void doStuff() {
writeln(Hello, world.);
}
void runDelegate(void delegate() myDelegate) {
myDelegate();
}
void main()
{
// auto delegateToPass = toDelegate(doStuff);
auto delegateToPass = (doStuff).toDelegate();
runDelegate(delegateToPass); // Calls doStuff, prints
Hello, world.
}
Ali
I coded like this :
auto func ={
..
};
import std.functional;
func.toDelegate(); //doesn't work ,shows undefined identifier
toDelegate
toDelegate(func); //works.
Re: Deserializing const fields
On 2012-09-06 21:54, Andrei Alexandrescu wrote: Except for pointers, which of course need to be handled carefully whether immutable or not, it's fine to deserialize into immutable fields as long as you clarify to the compiler you're dealing with ubyte[] and cast to the object type after. Thanks. -- /Jacob Carlborg
Re: core.simd 3 operand instructions?
On Thursday, 6 September 2012 at 19:21:22 UTC, Benjamin Thaut wrote: Looking at core.simd I noticed that all simd instructions that take 3 operands (usually two operands and some kind of constant third value), are commented out for the opcodes. Most likely because __simd() does not have a 4th parameter which could be used to pass in the additional value for some of the opcodes. Are there plans to fix this? Because for example the shuffle instructions are pretty important (try doing a cross product without simd shuffle instructions...) Kind Regards Benjamin Thaut I can't answer your question, but if you are using GDC, you could use gcc builtins . They have the same names as in GCC - take a look at *mmintrin.h files to find out SSE builtin names). For LDC, you could use pragma intrinsic(http://www.dsource.org/projects/ldc/wiki/Docs) and pragma shufflevector. You declare function that you want to compile to llvm shufflevector instruction like this: pragma(shufflevector) float4 shufflevector(float4, float4, int, int, int, int); Then shufflevector() is used in the same way as Clang's __builtin_shufflevector (http://clang.llvm.org/docs/LanguageExtensions.html#__builtin_shufflevector)
Re: core.simd 3 operand instructions?
On Friday, 7 September 2012 at 05:56:19 UTC, jerro wrote: On Thursday, 6 September 2012 at 19:21:22 UTC, Benjamin Thaut wrote: Looking at core.simd I noticed that all simd instructions that take 3 operands (usually two operands and some kind of constant third value), are commented out for the opcodes. Most likely because __simd() does not have a 4th parameter which could be used to pass in the additional value for some of the opcodes. Are there plans to fix this? Because for example the shuffle instructions are pretty important (try doing a cross product without simd shuffle instructions...) Kind Regards Benjamin Thaut I can't answer your question, but if you are using GDC, you could use gcc builtins . They have the same names as in GCC - take a look at *mmintrin.h files to find out SSE builtin names). For LDC, you could use pragma intrinsic(http://www.dsource.org/projects/ldc/wiki/Docs) and pragma shufflevector. You declare function that you want to compile to llvm shufflevector instruction like this: pragma(shufflevector) float4 shufflevector(float4, float4, int, int, int, int); Then shufflevector() is used in the same way as Clang's __builtin_shufflevector (http://clang.llvm.org/docs/LanguageExtensions.html#__builtin_shufflevector) I forgot to mention Manu's std.simd (https://github.com/TurkeyMan/phobos/blob/master/std/simd.d). It is supposed to be wrapper around compiler specific intrinsics. If your are using SIMD mostly for operation on geometric vectors, it should fit your use case well (for example, it already includes a cross3 function). It currently only really supports GDC, though.
Re: What are the differences between these forms of function-like declarations ?
On Friday, 7 September 2012 at 05:56:18 UTC, Anderel Cerol wrote:
I coded like this :
auto func ={
..
};
import std.functional;
func.toDelegate(); //doesn't work ,shows undefined identifier
toDelegate
toDelegate(func); //works.
Looks like scoped imports don't play nicely with UFCS. Put the
import in module scope and it works. Of course, that's just a
workaround, and you should report it as a bug.
Re: What are the differences between these forms of function-like declarations ?
On Friday, 7 September 2012 at 06:13:17 UTC, anonymous wrote: you should report it as a bug. Already in there: http://d.puremagic.com/issues/show_bug.cgi?id=6185
Re: pointers, functions, and uniform call syntax
On Friday, 7 September 2012 at 00:51:42 UTC, Era Scarecrow wrote: So it seems. The way I read it says it dereferences it first. Regardless that you are forcibly referencing a pointer which is low-level trickery; which I'm sure is undefined behavior. *Technically*, I think it is only undefined behavior once you *read* the dereferenced value... and passing by reference doesn't do that.
Re: pointers, functions, and uniform call syntax
On 09/07/12 02:52, Era Scarecrow wrote:
On Thursday, 6 September 2012 at 21:58:43 UTC, Artur Skawina wrote:
This program won't assert
and would segfault if 'i' was accessed by 'func'.
So it seems. The way I read it says it dereferences it first. Regardless
that you are forcibly referencing a pointer which is low-level trickery;
which I'm sure is undefined behavior.
There's nothing undefined about passing args by reference; i know the '*s' looks
misleading, but what happens when such an expression is used as a ref arg is
basically '*s' and then the compiler will let you access the result via the
function parameter; it's essentially syntax sugar (with a few extra usage
restrictions).
Course if you have to check/treat it as a pointer, adding @safe suddenly
refuses to compile (Won't let you get the address); But if you leave it out
(without @trusted either) and make main @safe, suddenly that doesn't compile
either. (Because I'm sure quite a few functions you'd want to share will end
up being @safe and pure).
'ref_arg' not being allowed in @safe mode is indeed a @safe-problem. But it's
not easily fixable right now, because scope enforcement isn't done - so it would
be too easy to leak a reference (pointer). Until it works with @safe, you can do
@safe:
auto func(ref int i) { @trusted check() { assert(!i); } check(); /*rest of
safe code*/ }
void main() { int* i; func(*i); }
which at least keeps the @trusted part to a minimum. Yeah, it should be possible
to do just '@trusted assert(!i);', ie have trusted scopes, not just functions;
see
http://www.digitalmars.com/d/archives/digitalmars/D/trusted_considered_harmful_173515.html
.
artur
Re: D and SCons
On Monday, 3 September 2012 at 07:19:06 UTC, Russel Winder wrote: Hi, Is there anyone out there using SCons to build D code? If so it would be good to get some alpha and beta testers for the evolution of D support in SCons. I appreciate that other build frameworks may be the preferred ones for D, let us not start a which build framework is the best debate, at least not in this thread, this email is only trying to contact people using SCons with D to see if some will volunteer to help with the evolution of this. Good D support in all build frameworks can only be good for D take up. Thanks. I try to use scons with D, and am currently using your site_scons (Thanks :).
std.hash, when?
I'm writing a webservice using d for my company. It needs sha signature. Have I to implement by myself? Is there a date for dmd 2.0xx release with new std.hash included?
Re: std.hash, when?
On Friday, 7 September 2012 at 10:47:12 UTC, Andrea Fontana wrote: I'm writing a webservice using d for my company. It needs sha signature. Have I to implement by myself? Is there a date for dmd 2.0xx release with new std.hash included? Couldn't you just use std.digest although it isn't in Phobos yet?
Would like to see ref and out required for function calls
I've been looking at migrating a reasonably large ship motion library (tens of thousands of lines) from C# to D. I've become quite enthusiastic about D, and most of my problems have been relatively minor (e.g., inconsistent bugs with std.container.Array, would like orange serialization to give me an error telling me I didn't register a class before calling serialize). I suggest that the language require ref and out when calling functions, as C# requires. This would make code easier to understand, and would also eliminate the problem I had when the wrong function from the following choices was mistakenly called: parseLineInts(string text, int positionStart, out int j0, out int j1) parseLineInts(string text, out int j0, out int j1, out int j2) I note that the second function calls another function as follows: int positionStart = 1; parseLineInts(text, positionStart, j0, j1, j2); I look forward to seeing feedback from D experts. This is the only significant change that I could think of recommending for the language.
Re: std.hash, when?
If std.hash doesn't work out for you - though I think it is going to be in the next release since the vote passed - I have a sha 1 function in my sha.d, and a binding to the mhash C library for more complex signatures in my oauth.d https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff Take a look at oauth.d, at the bottom of the file for a function called mhashSign.
Re: std.hash, when?
On Friday, 7 September 2012 at 11:33:59 UTC, jerro wrote: On Friday, 7 September 2012 at 10:47:12 UTC, Andrea Fontana wrote: I'm writing a webservice using d for my company. It needs sha signature. Have I to implement by myself? Is there a date for dmd 2.0xx release with new std.hash included? Couldn't you just use std.digest although it isn't in Phobos yet? Sure but if it's going to be released I wait for final release :)
Re: std.hash, when?
On Friday, 7 September 2012 at 12:07:47 UTC, Adam D. Ruppe wrote: If std.hash doesn't work out for you - though I think it is going to be in the next release since the vote passed - I have a sha 1 function in my sha.d, and a binding to the mhash C library for more complex signatures in my oauth.d https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff Take a look at oauth.d, at the bottom of the file for a function called mhashSign. Adam, you should build a standard library with your misc-stuff! :)
Re: Modulo Bug?
On Sat, 11 Aug 2012 09:48:15 -0400, David d...@dav1d.de wrote: -1 % 16 = -1 Shouldn't that be 15? It seems like the sign is ignored for the modulo. Is this a bug or intended behaviour? The Python implementation returns here, as expected, 15. In case you are still looking for an expression which mods always positive (even for non-powers of 2) (a % b + b) % b Obviously, b must be positive. The direct translation of this to assembly isn't the most efficient way. Technically, in assembly we could check for the sign bit, and only add b again (without doing the second mod) if the value was negative. But I'm not sure you can write an expression that causes that, maybe: a % b 0 ? a % b + b : a % b Certainly not as appealing. To get a direct translation from the above assembly, it would be something like: typeof(a) x; auto expr = (x = a % b) 0 ? x + b : x -Steve
Re: Formatted read consumes input
On Thu, 23 Aug 2012 07:33:13 -0400, monarch_dodra monarchdo...@gmail.com
wrote:
As title implies:
import std.stdio;
import std.format;
void main()
{
string s = 42;
int v;
formattedRead(s, %d, v);
writefln([%s] [%s], s, v);
}
[] [42]
Is this the expected behavior?
Furthermore, it is not possible to try to save s:
import std.stdio;
import std.format;
import std.range;
void main()
{
string s = 42;
int v;
formattedRead(s.save, %d, v);
writefln([%s] [%s], s, v);
}
main.d(9): Error: template std.format.formattedRead does not match any
function template declaration
C:\D\dmd.2.060\dmd2\windows\bin\..\..\src\phobos\std\format.d(526):
Error: template std.format.formattedRead(R,Char,S...) cannot deduce
template function from argument types !()(string,string,int*)
The workaround is to have a named backup:
auto ss = s.save;
formattedRead(ss, %d, v);
I've traced the root issue to formattedRead's signature, which is:
uint formattedRead(R, Char, S...)(ref R r, const(Char)[] fmt, S args);
Is there a particular reason for this pass by ref? It is inconsistent
with the rest of phobos, or even C's scanf?
Is this a file-able bug_report/enhancement_request?
I believe it behaves as designed, but could be designed in such a way that
does not need ref input range. In fact, I think actually R needing to be
ref is a bad thing. Consider that if D didn't consider string literals to
be lvalues (an invalid assumption IMO), then passing a string literal as
the input would not work!
The only issue is, what if you *do* want ref behavior for strings? You
would need to wrap the string into a ref'd range. That is not a good
proposition. Unfortunately, the way IFTI works, there isn't an
opportunity to affect the parameter type IFTI decides to use.
I think a reasonable enhancement would be to add a formattedReadNoref (or
better named alternative) that does not take a ref argument.
-Steve
Re: Formatted read consumes input
On Friday, 7 September 2012 at 13:58:43 UTC, Steven Schveighoffer
wrote:
On Thu, 23 Aug 2012 07:33:13 -0400, monarch_dodra
The only issue is, what if you *do* want ref behavior for
strings? You would need to wrap the string into a ref'd range.
That is not a good proposition. Unfortunately, the way IFTI
works, there isn't an opportunity to affect the parameter type
IFTI decides to use.
[SNIP]
-Steve
If you want *do* ref behavior, I still don't see why you we don't
just do it the algorithm way of return by value:
Tuple!(uint, R)
formattedRead2(R, Char, S...)(R r, const(Char)[] fmt, S args)
{
auto ret = formattedRead(r, fmt, args);
return Tuple!(uint, R)(ret, r);
}
void main()
{
string s = 42 worlds;
int v;
s = formattedRead(s.save, %d, v)[1];
writefln([%s][%s], v, s);
}
Re: std.hash, when?
On 9/7/12 2:12 PM, Andrea Fontana wrote: On Friday, 7 September 2012 at 11:33:59 UTC, jerro wrote: On Friday, 7 September 2012 at 10:47:12 UTC, Andrea Fontana wrote: I'm writing a webservice using d for my company. It needs sha signature. Have I to implement by myself? Is there a date for dmd 2.0xx release with new std.hash included? Couldn't you just use std.digest although it isn't in Phobos yet? Sure but if it's going to be released I wait for final release :) It will be part of 2.061. Andrei
Re: Formatted read consumes input
On Fri, 07 Sep 2012 10:35:37 -0400, monarch_dodra monarchdo...@gmail.com
wrote:
On Friday, 7 September 2012 at 13:58:43 UTC, Steven Schveighoffer wrote:
On Thu, 23 Aug 2012 07:33:13 -0400, monarch_dodra
The only issue is, what if you *do* want ref behavior for strings? You
would need to wrap the string into a ref'd range.
That is not a good proposition. Unfortunately, the way IFTI works,
there isn't an opportunity to affect the parameter type IFTI decides to
use.
[SNIP]
-Steve
If you want *do* ref behavior, I still don't see why you we don't just
do it the algorithm way of return by value:
Tuple!(uint, R)
formattedRead2(R, Char, S...)(R r, const(Char)[] fmt, S args)
{
auto ret = formattedRead(r, fmt, args);
return Tuple!(uint, R)(ret, r);
}
void main()
{
string s = 42 worlds;
int v;
s = formattedRead(s.save, %d, v)[1];
writefln([%s][%s], v, s);
}
This looks ugly. Returning a tuple and having to split the result is
horrible, I hated dealing with that in C++ (and I even wrote stuff that
returned pairs!)
Not only that, but there are possible ranges which may not be reassignable.
I'd rather have a way to wrap a string into a ref-based input range.
We have three situations:
1. input range is a ref type already (i.e. a class or a pImpl struct), no
need to pass this by ref, just wastes cycles doing double dereference.
2. input range is a value type, and you want to preserve the original.
3. input range is a value type, and you want to update the original.
I'd like to see the library automatically make the right decision for 1,
and give you some mechanism to choose between 2 and 3. To preserve
existing code, 3 should be the default.
-Steve
Re: Would like to see ref and out required for function calls
On 9/7/12, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Actually the darndest thing is that C# has retired the syntax in 5.0 (it used to be required up until 4.0). Apparently users complained it was too unsightly. If you like implicit ref then why did you choose to use pointers when implementing std.getopt?
Re: Would like to see ref and out required for function calls
On 9/7/12 4:55 PM, Andrej Mitrovic wrote: On 9/7/12, Andrei Alexandrescuseewebsiteforem...@erdani.org wrote: Actually the darndest thing is that C# has retired the syntax in 5.0 (it used to be required up until 4.0). Apparently users complained it was too unsightly. If you like implicit ref then why did you choose to use pointers when implementing std.getopt? At the time ref variadics weren't implemented. I should also add I joined D after ref was there. I don't have strong feelings one way or another. Andrei
Re: Would like to see ref and out required for function calls
On Friday, September 07, 2012 13:34:02 Kevin McTaggart wrote: I look forward to seeing feedback from D experts. This is the only significant change that I could think of recommending for the language. Regardless of the pros and cons of requiring explicit ref and out, it would break a lot of code if we started requiring it, so I don't think that there's any chance of such a change being made at this point. If/When we create D3 (which is years off), it could be discussed and possibly changed then, but I think that it's clearly too large a change for D2 at this point. - Jonathan M Davis
Re: Formatted read consumes input
On Friday, September 07, 2012 10:52:07 Steven Schveighoffer wrote: We have three situations: 1. input range is a ref type already (i.e. a class or a pImpl struct), no need to pass this by ref, just wastes cycles doing double dereference. 2. input range is a value type, and you want to preserve the original. 3. input range is a value type, and you want to update the original. I'd like to see the library automatically make the right decision for 1, and give you some mechanism to choose between 2 and 3. To preserve existing code, 3 should be the default. Does it _ever_ make sense for a range to be an input range and not a forward range and _not_ have it be a reference type? Since it would be implicitly saving it if it were a value type, it would then make sense that it should have save on it. So, I don't think that input ranges which aren't forward ranges make any sense unless they're reference types, in which case, there's no point in taking them by ref, and you _can't_ preserve the original. - Jonathan M Davis
Re: Would like to see ref and out required for function calls
Am 07.09.2012 16:38, schrieb Andrei Alexandrescu: Actually the darndest thing is that C# has retired the syntax in 5.0 (it used to be required up until 4.0). Apparently users complained it was too unsightly. reference link?
Re: Formatted read consumes input
On Friday, 7 September 2012 at 14:51:45 UTC, Steven Schveighoffer
wrote:
On Fri, 07 Sep 2012 10:35:37 -0400, monarch_dodra
This looks ugly. Returning a tuple and having to split the
result is horrible, I hated dealing with that in C++ (and I
even wrote stuff that returned pairs!)
Not only that, but there are possible ranges which may not be
reassignable.
I'd rather have a way to wrap a string into a ref-based input
range.
We have three situations:
1. input range is a ref type already (i.e. a class or a pImpl
struct), no need to pass this by ref, just wastes cycles doing
double dereference.
2. input range is a value type, and you want to preserve the
original.
3. input range is a value type, and you want to update the
original.
I'd like to see the library automatically make the right
decision for 1, and give you some mechanism to choose between 2
and 3. To preserve existing code, 3 should be the default.
-Steve
True...
Still, I find it horrible to have to create a named dummy
variable just when I simply want to pass a copy of my range.
I think I found 2 other solutions:
1: auto ref.
2: Kind of like auto ref: Just provide a non-ref overload. This
creates less executable bloat.
Like this:
//Formatted read for R-Value input range.
uint formattedRead(R, Char, S...)(R r, const(Char)[] fmt, S args)
{
return formattedRead(r, fmt, args);
}
//Standard formated read
uint formattedRead(R, Char, S...)(ref R r, const(Char)[] fmt, S
args)
This allows me to write, as I would expect:
void main()
{
string s = x42xT;
int v;
formattedRead(s.save, x%dx, v); //Pyssing a copy
writefln([%s][%s], v, s);
formattedRead(s, x%dx, v); //Please consusme me
writefln([%s][%s], v, s);
}
[42][x42xT] //My range is unchanged
[42][T] //My range was consumed
I think this is a good solution. Do you see anything I may have
failed to see?
Re: Would like to see ref and out required for function calls
On 09/07/2012 04:38 PM, Andrei Alexandrescu wrote: ... Actually the darndest thing is that C# has retired the syntax in 5.0 (it used to be required up until 4.0). Apparently users complained it was too unsightly. Andrei How do they deal with the increased ambiguity in overload resolution?
Re: Modulo Bug?
On 8/11/2012 11:54 AM, Thiez wrote: A few extra instructions (a CMOV followed by ADD should suffice, yes?) seems like a small price to pay if it can prevent bugs. Why hasn't the Python-modulo been made the default back when D was designed? The ever-so-slightly more efficient C-modulo could be provided in a library. Of course it's way too late to change it now... Because then C code translated to D will have subtle, silent and unexpected bugs.
Re: Would like to see ref and out required for function calls
On 09/07/2012 05:51 PM, Timon Gehr wrote: How do they deal with the increased ambiguity in overload resolution? Actually, it is simple. They just have to call the non-out overload when there is no out at the call site, regardless of the actual argument.
Re: core.simd 3 operand instructions?
Am 06.09.2012 22:45, schrieb Walter Bright: On 9/6/2012 12:21 PM, Benjamin Thaut wrote: Looking at core.simd I noticed that all simd instructions that take 3 operands (usually two operands and some kind of constant third value), are commented out for the opcodes. Most likely because __simd() does not have a 4th parameter which could be used to pass in the additional value for some of the opcodes. Are there plans to fix this? Because for example the shuffle instructions are pretty important (try doing a cross product without simd shuffle instructions...) simd support is very important, but I put it on the back burner for the moment while applying the paddles to the Win64 compiler. That is nice to hear, I would prefer 64 bit support on windows over simd any time ;-) Kind Regards Benjamin Thaut
Re: Modulo Bug?
Walter Bright: Because then C code translated to D will have subtle, silent and unexpected bugs. I agree. So the solution is to introduce a new Phobos function or new built-in operator that works more correctly with negative numbers too. A new Phobos function named mod() is a very simple solution. While a new infix operator has the advantage of being more natural to use, this allows programmers to better remember to use it instead of the C %, so the maybe a built-in operator avoids some bugs compared to the function. Bye, bearophile
Re: Would like to see ref and out required for function calls
Andrei Alexandrescu: Actually the darndest thing is that C# has retired the syntax in 5.0 (it used to be required up until 4.0). Apparently users complained it was too unsightly. Are you sure? This page about the Visual Studio 2012 shows that ref and out are required: http://msdn.microsoft.com/en-us/library/14akc2c7.aspx I know they have relaxed the requirement in one case, in C#4 or something. The idea of requiring ref/out at the all site was discussed some times in past. This idea has both advantages and disadvantages. It makes the code a bit longer, but gives the reader more information about what the call will do. In D there are also ref at the return value, I presume this is never going to require a ref at the call site. Bye, bearophile
Re: Formatted read consumes input
On Friday, 7 September 2012 at 15:34:12 UTC, monarch_dodra wrote: I think this is a good solution. Do you see anything I may have failed to see? I've made a pull request out of it. https://github.com/D-Programming-Language/phobos/pull/777
Re: Formatted read consumes input
On Fri, 07 Sep 2012 11:04:36 -0400, Jonathan M Davis jmdavisp...@gmx.com wrote: On Friday, September 07, 2012 10:52:07 Steven Schveighoffer wrote: We have three situations: 1. input range is a ref type already (i.e. a class or a pImpl struct), no need to pass this by ref, just wastes cycles doing double dereference. 2. input range is a value type, and you want to preserve the original. 3. input range is a value type, and you want to update the original. I'd like to see the library automatically make the right decision for 1, and give you some mechanism to choose between 2 and 3. To preserve existing code, 3 should be the default. Does it _ever_ make sense for a range to be an input range and not a forward range and _not_ have it be a reference type? No it doesn't. That is case 1. However, it's quite easy to forget to define save when your range really is a forward range. I don't really know a good way to fix this. To assume that an input-and-not-forward range has reference semantics is prone to inappropriate code compiling just fine. Clearly we can say classes are easily defined as not needing ref. -Steve
Re: Formatted read consumes input
On Fri, 07 Sep 2012 11:34:28 -0400, monarch_dodra monarchdo...@gmail.com
wrote:
On Friday, 7 September 2012 at 14:51:45 UTC, Steven Schveighoffer wrote:
On Fri, 07 Sep 2012 10:35:37 -0400, monarch_dodra
This looks ugly. Returning a tuple and having to split the result is
horrible, I hated dealing with that in C++ (and I even wrote stuff that
returned pairs!)
Not only that, but there are possible ranges which may not be
reassignable.
I'd rather have a way to wrap a string into a ref-based input range.
We have three situations:
1. input range is a ref type already (i.e. a class or a pImpl struct),
no need to pass this by ref, just wastes cycles doing double
dereference.
2. input range is a value type, and you want to preserve the original.
3. input range is a value type, and you want to update the original.
I'd like to see the library automatically make the right decision for
1, and give you some mechanism to choose between 2 and 3. To preserve
existing code, 3 should be the default.
-Steve
True...
Still, I find it horrible to have to create a named dummy variable
just when I simply want to pass a copy of my range.
I think I found 2 other solutions:
1: auto ref.
2: Kind of like auto ref: Just provide a non-ref overload. This creates
less executable bloat.
Like this:
//Formatted read for R-Value input range.
uint formattedRead(R, Char, S...)(R r, const(Char)[] fmt, S args)
{
return formattedRead(r, fmt, args);
}
//Standard formated read
uint formattedRead(R, Char, S...)(ref R r, const(Char)[] fmt, S args)
This allows me to write, as I would expect:
void main()
{
string s = x42xT;
int v;
formattedRead(s.save, x%dx, v); //Pyssing a copy
writefln([%s][%s], v, s);
formattedRead(s, x%dx, v); //Please consusme me
writefln([%s][%s], v, s);
}
[42][x42xT] //My range is unchanged
[42][T] //My range was consumed
I think this is a good solution. Do you see anything I may have failed
to see?
Well, this does work. But I don't like that the semantics depend on
whether the value is an rvalue or not.
Note that even ranges that are true input ranges (i.e. a file) still
consume their data, even as rvalues, there is no way around it.
-Steve
Re: Formatted read consumes input
On Friday, 7 September 2012 at 18:15:00 UTC, Steven Schveighoffer wrote: Well, this does work. But I don't like that the semantics depend on whether the value is an rvalue or not. Note that even ranges that are true input ranges (i.e. a file) still consume their data, even as rvalues, there is no way around it. -Steve Yes, but that is another issue, it is a copy vs save semantic issue. In theory, one should assume that *even* with pass by value, if you want your range to not be consumed, you have to call save. Most ranges are value types, so we tend to forget it. std.algorithm had a few save-related bugs like that as a matter of fact. But, contrary to post 1, that is not the actual issue being fixed here. It is merely a compile with unnamed fix: formattedRead(file.save, ...) And now it compiles fine. AND the range is saved. That's it. Nothing more, nothing less. ... That's *if* file provides save. I do not know much about file/stream handling in D, but you get my save point.
Re: Would like to see ref and out required for function calls
On Friday, 7 September 2012 at 16:46:36 UTC, bearophile wrote: Andrei Alexandrescu: Actually the darndest thing is that C# has retired the syntax in 5.0 (it used to be required up until 4.0). Apparently users complained it was too unsightly. Are you sure? This page about the Visual Studio 2012 shows that ref and out are required: http://msdn.microsoft.com/en-us/library/14akc2c7.aspx +1
Re: Would like to see ref and out required for function calls
On 2012-09-07 13:34, Kevin McTaggart wrote: I've been looking at migrating a reasonably large ship motion library (tens of thousands of lines) from C# to D. I've become quite enthusiastic about D, and most of my problems have been relatively minor (e.g., inconsistent bugs with std.container.Array, would like orange serialization to give me an error telling me I didn't register a class before calling serialize). Please report any bugs about Orange to https://github.com/jacob-carlborg/orange and I'll see what I can do about it. -- /Jacob Carlborg
Status on Precise GC
This issue on bugzilla hasn't been updated since July 2011, but it's assigned to Sean Kelly: http://d.puremagic.com/issues/show_bug.cgi?id=3463 I've found these threads concerning a precise GC: http://www.digitalmars.com/d/archives/digitalmars/D/learn/Regarding_the_more_precise_GC_35038.html http://www.digitalmars.com/d/archives/digitalmars/D/How_can_I_properly_import_functions_from_gcx_in_object.di_171815.html Is this issue obsolete, or is it being worked on? Reason being, I'm writing a game in D and I plan to write it in nearly 100% D (with the exception being OpenGL libraries and the like), but I know I'll run into problems with the GC eventually. If this is an active project that may get finished in the relative near term (less than a year), then I'd feel comfortable knowing that eventually problems may go away. I want to eventually make this work with ARM (Raspberry PI cubieboard), and the GC is a major blocker here (well, and a cross-compiler, but I'll work that out when I get there). I'm using dmd atm if that matters. Thanks! Jameson
Re: Status on Precise GC
Here's the GSoC project I mentored this summer. A little integration work still needs to be done, and I've been meaning to ping the student about the status of this. If you want, I'd welcome some beta testers. https://github.com/Tuna-Fish/druntime/tree/gc_poolwise_bitmap On Saturday, 8 September 2012 at 01:55:44 UTC, Tyler Jameson Little wrote: This issue on bugzilla hasn't been updated since July 2011, but it's assigned to Sean Kelly: http://d.puremagic.com/issues/show_bug.cgi?id=3463 I've found these threads concerning a precise GC: http://www.digitalmars.com/d/archives/digitalmars/D/learn/Regarding_the_more_precise_GC_35038.html http://www.digitalmars.com/d/archives/digitalmars/D/How_can_I_properly_import_functions_from_gcx_in_object.di_171815.html Is this issue obsolete, or is it being worked on? Reason being, I'm writing a game in D and I plan to write it in nearly 100% D (with the exception being OpenGL libraries and the like), but I know I'll run into problems with the GC eventually. If this is an active project that may get finished in the relative near term (less than a year), then I'd feel comfortable knowing that eventually problems may go away. I want to eventually make this work with ARM (Raspberry PI cubieboard), and the GC is a major blocker here (well, and a cross-compiler, but I'll work that out when I get there). I'm using dmd atm if that matters. Thanks! Jameson
offsetof + foreach
I have a struct buffer, and I want to print out its members' offsetof.
This:
foreach(i,_t; buffer.tupleof) {
writefln(%s@: %s, _t.stringof, _t.offsetof);
}
complains
Error: undefined identifier 'offsetof'
what should I be doing?
Re: offsetof + foreach
On 09/07/2012 10:31 AM, Ellery Newcomer wrote:
I have a struct buffer, and I want to print out its members' offsetof.
This:
foreach(i,_t; buffer.tupleof) {
writefln(%s@: %s, _t.stringof, _t.offsetof);
}
complains
Error: undefined identifier 'offsetof'
what should I be doing?
nevermind, I remember tupleof + foreach has always been broken
writefln(%s@: %s, buffer.tupleof[i].stringof, buffer.tupleof[i].offsetof);
Re: bigint - python long
On 09/06/2012 09:48 AM, Ellery Newcomer wrote: On 09/05/2012 11:19 PM, Jacob Carlborg wr Associative arrays? check. eh, that was check as in yes, not check as in look it up yourself. didn't seem ambiguous at the time.
Re: bigint - python long
On 09/06/2012 12:07 AM, Russel Winder wrote: I am guessing this is interfacing to CPython, remember there is also PyPy and ActiveState, they have different ways of doing things. Well the ActiveState C API will be very close to the CPython C API, but PyPy (which is the best Python 2.7 just now) doesn't have a C API since it is written in RPython. Yep, CPython for now. If activestate supports the CPython C API, then supporting it will probably just be a matter of linkage. Googling, it looks like PyPy is/was trying to grow some CPython C API compatibility, so hopefully we can squeeze it in at some point. Oh yes. NumPy is basically a subsystem that Python applications make calls into. Although the data structure can be accessed and amended, algorithms on the data structures should never be written in Python, they should always be function calls into the NumPy framework. I had a look at numpy, and at least ndarray supports the new style buffer interface (which is pretty freaking complicated), so convertion is totally doable. I'll fold in support as soon as I can get dmd to stop stabbing me in the face. just used your scons fork to build the pyd embedded unittests. works pretty nice
typeof(enum)
import std.stdio;
enum PI = 3.14;
void main()
{
writeln(typeid(typeof(PI)));
}
It prints double. Shouldn't it be immutable(double). I think it
would make more sense, as it is a constant. Plus, it could be
shared among threads.
Re: bigint - python long
Ellery Newcomer: I had a look at numpy, and at least ndarray supports the new style buffer interface (which is pretty freaking complicated), so convertion is totally doable. I'll fold in support as soon as I can get dmd to stop stabbing me in the face. If you support NumPy well and efficiently through Pyd, I think some people will start using the D language just for this :-) NumPy is good but it usually forces you to program vectorially, like Matlab. Sometimes this is not nice, so people write some routines in Fortran, C, etc. With Pyd some scientific programmers maybe will want to use D instead. Bye, bearophile
Re: typeof(enum)
On 09/07/2012 03:55 PM, Minas wrote:
import std.stdio;
enum PI = 3.14;
void main()
{
writeln(typeid(typeof(PI)));
}
It prints double. Shouldn't it be immutable(double). I think it would
make more sense, as it is a constant. Plus, it could be shared among
threads.
immutable makes sense with variables (I know, it's an oxymoron. :)) PI
in your code is just a manifest constant (i.e. it is just 3.14, nothing
more).
In other words, its immutability comes from being an rvalue.
Ali
Re: typeof(enum)
On Saturday, September 08, 2012 00:55:24 Minas wrote:
import std.stdio;
enum PI = 3.14;
void main()
{
writeln(typeid(typeof(PI)));
}
It prints double. Shouldn't it be immutable(double). I think it
would make more sense, as it is a constant. Plus, it could be
shared among threads.
PI isn't even a variable. It's a manifest constant. Its value gets copy-pasted
everywhere you use it (which is why using enums with array literals or AA
literals is generally a bad idea - each usage allocates a new one). So, making
it immutable wouldn't really buy you anything. There's nothing there to share
across threads, and whether what it's assigned to should be immutable or not
depends on what it's being assigned to. And since double is a value type, it
can be assigned to a variable of any constancy, making the constness or
immutability of the enum pretty much a mute point. Pretty much the _only_
place that it would matter would be type inferrence.
- Jonathan M Davis
linker @_@
playing with some old headers I had lying around,
dmd libdw_test.d {{header files}} -L-ldw
gives me
/usr/bin/ld: /usr/lib64/dmd-2.060/libphobos2.a(memory_4a8_620.o):
undefined reference to symbol '_end'
/usr/bin/ld: note: '_end' is defined in DSO /lib64/liblzma.so.5 so try
adding it to the linker command line
/lib64/liblzma.so.5: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
any english suggestions?
int[3][4]*
alright what's the deal?
void main () {
alias int[3][4] fooz;
int[3][4]* i = new fooz;
}
wiz.d(6): Error: new can only create structs, dynamic arrays or class
objects, not int[3LU][4LU]'s
Re: int[3][4]*
Ellery Newcomer:
alright what's the deal?
This is one of the clean ways to do it:
void main () {
static struct Mat {
int[3][4] m;
alias m this;
}
Mat* fooz = new Mat;
fooz[1][3] = 5;
}
Bye,
bearophile
Re: typeof(enum)
Accidentally replied to your private email first.
On 09/08/2012 12:55 AM, Minas wrote:
import std.stdio;
enum PI = 3.14;
void main()
{
writeln(typeid(typeof(PI)));
}
It prints double. Shouldn't it be immutable(double).
No.
auto x = PI;
x++;
I think it would make more sense, as it is a constant.
It never makes sense to have mutable values, but their type may still
allow mutation of variables of that type.
Plus, it could be shared among threads.
The symbol PI does not exist at runtime.
Re: int[3][4]*
On 09/08/2012 04:19 AM, bearophile wrote:
Ellery Newcomer:
alright what's the deal?
This is one of the clean ways to do it:
void main () {
static struct Mat {
int[3][4] m;
alias m this;
}
Mat* fooz = new Mat;
fooz[1][3] = 5;
This may corrupt your heap.
}
Bye,
bearophile
I prefer this:
void main(){
alias int[3][4] fooz;
int[3][4]* i = (new fooz[1]).ptr;
}
But I think the original example should just work.
[Issue 8624] Regression: CTFE: long comparisons completely broken
http://d.puremagic.com/issues/show_bug.cgi?id=8624
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||CTFE, wrong-code
CC||clugd...@yahoo.com.au
Summary|CTFE: 0x6161636772 == |Regression: CTFE: long
|0x4161636772|comparisons completely
||broken
Severity|normal |regression
--- Comment #1 from Don clugd...@yahoo.com.au 2012-09-06 23:44:46 PDT ---
This is one of the worst bugs of all time. I can't believe this slipped through
the test suite. The top 32 bits of longs is entirely ignored in CTFE == and !=
comparisons. Reduced test case:
int bug8624()
{
long m = 0x1__;
assert(m != 0);
return 1;
}
static assert( bug8624() );
It's a typo in interpret.c, which results in an implicit conversion from long
to int.
This might be worth an emergency release.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8627] New: Internal error: ../ztc/cgcs.c 343
http://d.puremagic.com/issues/show_bug.cgi?id=8627
Summary: Internal error: ../ztc/cgcs.c 343
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: blocker
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: blo...@hotmail.com
--- Comment #0 from Christopher Crouzet blo...@hotmail.com 2012-09-07
01:44:05 PDT ---
The code below errors with an internal error:
// --
import std.stdio;
class Test
{
public:
auto whatever()
{
float[1] tmp;
return tmp;
}
}
void main()
{
auto test = new Test;
writeln( test.whatever()[0] );
}
// --
This looks quite simple, hopefully I'm not doing anything wrong?
It's working when I initialize tmp with a size of at least 3 elements.
Cheers,
Christopher.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5637] Anonymous structs/unions should have their own context
http://d.puremagic.com/issues/show_bug.cgi?id=5637 Iain Buclaw ibuc...@ubuntu.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #1 from Iain Buclaw ibuc...@ubuntu.com 2012-09-07 02:20:49 PDT --- Pathological case no longer shows up in gdc. Closing old report. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8628] New: IntegerExp::toInteger(): Assertion `0' failed
http://d.puremagic.com/issues/show_bug.cgi?id=8628
Summary: IntegerExp::toInteger(): Assertion `0' failed
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: ellery-newco...@utulsa.edu
--- Comment #0 from Ellery Newcomer ellery-newco...@utulsa.edu 2012-09-07
15:11:01 PDT ---
dmd 2.060 x64 linux
code:
//a.d
import b;
void main() {
d_type!double(null);
}
//b.d
T d_type(T) () {
Dim!T.initArr;
}
template Dim(T) {
int[] tuple2arr()() {
}
bool check() {
if(dims) return false;
}
enum int[] dims = tuple2arr!()();
}
compile:
dmd b a
produces fireworks:
e = 0x220d6b0, ty = 35
_error_ 0x21845a0
dmd: expression.c:2073: virtual dinteger_t IntegerExp::toInteger(): Assertion
`0' failed.
Aborted (core dumped)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8624] Regression: CTFE: long comparisons completely broken
http://d.puremagic.com/issues/show_bug.cgi?id=8624 Brad Roberts bra...@puremagic.com changed: What|Removed |Added CC||bra...@puremagic.com --- Comment #2 from Brad Roberts bra...@puremagic.com 2012-09-07 17:41:58 PDT --- In which version did it last work correctly? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Status on Precise GC
This issue on bugzilla hasn't been updated since July 2011, but it's assigned to Sean Kelly: http://d.puremagic.com/issues/show_bug.cgi?id=3463 I've found these threads concerning a precise GC: http://www.digitalmars.com/d/archives/digitalmars/D/learn/Regarding_the_more_precise_GC_35038.html http://www.digitalmars.com/d/archives/digitalmars/D/How_can_I_properly_import_functions_from_gcx_in_object.di_171815.html Is this issue obsolete, or is it being worked on? Reason being, I'm writing a game in D and I plan to write it in nearly 100% D (with the exception being OpenGL libraries and the like), but I know I'll run into problems with the GC eventually. If this is an active project that may get finished in the relative near term (less than a year), then I'd feel comfortable knowing that eventually problems may go away. I want to eventually make this work with ARM (Raspberry PI cubieboard), and the GC is a major blocker here (well, and a cross-compiler, but I'll work that out when I get there). I'm using dmd atm if that matters. Thanks! Jameson
Re: Status on Precise GC
On Saturday, September 08, 2012 02:44:47 Tyler Jameson Little wrote: Thanks! Please do not post to this list. It's intended for messages posted by bugzilla only. You subscribe to it if you want to see the messages from bugzilla. Please ask questions about learning D in digitalmars-d-learn and general D- related questions in digitalmals-d. - Jonathan M Davis
