Re: float[] → Vertex[] – decreases performance by 1000%
Am 26.07.2012 21:18, schrieb David: Hm. Do you ever do pointer arithmetic on Vertex*? Is the size and offsets are correct (like in Vertex vs float)? No, yes. I really have no idea why this happens, I saved the contents of my buffers and compared them with the buffers of the `float[]` version (thanks to `git checkout`) and they were exactly 100% the same. It's a mystery. can you create a version of you code thats allows switching (version(Vertex) else ...) between array and Vertex? or provide both versions here again you checked dmd and ldc output so it can't be a backend thing (maybe frontend or GC) - or mysterious GL bugs
Re: Writing very large files 50+ GB
On Friday, 27 July 2012 at 01:50:57 UTC, wmunger wrote: I need to write to a file that is 50 to 250GB on all three major operating systems. I tried to use the c function pwrite64. But it is not available on the Mac. I have seen where some have used the iostream in C++ but this does not seem to work on the Mac. Is there any way to write in D very large files. After all I would rather write in D than wrap C or C++ code. Thank you. What are you going to be writing? Depending on the issue, it may be a Filesystem/OS limitation than a language limitation.
Writing very large files 50+ GB
I need to write to a file that is 50 to 250GB on all three major operating systems. I tried to use the c function pwrite64. But it is not available on the Mac. I have seen where some have used the iostream in C++ but this does not seem to work on the Mac. Is there any way to write in D very large files. After all I would rather write in D than wrap C or C++ code. Thank you.
Re: Why are scope variables being deprecated?
On 07/26/2012 09:19 PM, Jonathan M Davis wrote:
On Thursday, July 26, 2012 21:09:09 Chad J wrote:
I keep hearing that scope variables are going away. I missed the
discussion on it. Why is this happening?
When I read about this, I have these in mind:
void someFunc()
{
// foo is very likely to get stack allocated
scope foo = new SomeClass();
foo.use();
// ~foo is called.
}
It's inherently unsafe. What happens if you returned a reference to foo from
someFunc? Or if you assigned a reference to foo to anything and then tried to
use it after someFunc has returned? You get undefined behavior, because foo
doesn't exist anymore. If you really need foo to be on the stack, then maybe
you should make it a struct. However, if you really do need scope for some
reason, then you can use std.typecons.scoped, and it'll do the same thing.
OK, so std.typecons.scoped will completely replace the use-case for the
scope keyword. That makes it OK ;)
Just making things structs isn't always sufficient because the data type
in question might be in a 3rd party's code and cannot be simply
redesigned. The scope keyword gave us a way to force stack-allocation
in cases that would be otherwise inaccessible. But it seems like
std.typecons.scoped can be used for this, so 'scope' isn't need anymore.
And it simplifies the compiler. Cool.
Erm, yeah I'm sure you've probably seen this discussed to death already.
I know how these things go ;)
scope on local variables is going away for pretty much the same reason that
delete is. They're unsafe, and the fact that they're in the core language
encourages their use. So, they're being removed and put into the standard
library instead.
- Jonathan M Davis
Alright. Thanks for the good explanation!
Re: Why are scope variables being deprecated?
On Thursday, July 26, 2012 21:09:09 Chad J wrote:
> I keep hearing that scope variables are going away. I missed the
> discussion on it. Why is this happening?
>
> When I read about this, I have these in mind:
>
> void someFunc()
> {
> // foo is very likely to get stack allocated
> scope foo = new SomeClass();
> foo.use();
> // ~foo is called.
> }
It's inherently unsafe. What happens if you returned a reference to foo from
someFunc? Or if you assigned a reference to foo to anything and then tried to
use it after someFunc has returned? You get undefined behavior, because foo
doesn't exist anymore. If you really need foo to be on the stack, then maybe
you should make it a struct. However, if you really do need scope for some
reason, then you can use std.typecons.scoped, and it'll do the same thing.
scope on local variables is going away for pretty much the same reason that
delete is. They're unsafe, and the fact that they're in the core language
encourages their use. So, they're being removed and put into the standard
library instead.
- Jonathan M Davis
Why are scope variables being deprecated?
I keep hearing that scope variables are going away. I missed the
discussion on it. Why is this happening?
When I read about this, I have these in mind:
void someFunc()
{
// foo is very likely to get stack allocated
scope foo = new SomeClass();
foo.use();
// ~foo is called.
}
Re: normal function and template function conflict
On Thursday, July 26, 2012 21:49:35 Andrej Mitrovic wrote:
> On 7/26/12, Jacob Carlborg wrote:
> > void seed () (UIntType value = default_seed)
> >
> > Less typing as well.
>
> Yep. It's funny how this works at all. I mean a template with no
> template parameters is somehow still a template. :)
It _is _ bit funny, but Ibelieve that it comes from permitting empty template
parameter lists. Without that, recursion with eponymous templates would become
problematic. e.g.
enum template myTemplate(T...)
{
static if(T.length == 0)
enum myTemplate = 42;
else
enum myTemplate = T[0] * 3 + myTemplate!(T[1 .. $]);
}
needs to be able to take an empty parameter list. It's probably possible to
make that work without allowing an outright empty parameter list that isn't
even a variadic template, but I suspect that it's just easier to allow it.
- Jonathan M Davis
Re: normal function and template function conflict
On 7/26/12, Jacob Carlborg wrote: > void seed () (UIntType value = default_seed) > > Less typing as well. Yep. It's funny how this works at all. I mean a template with no template parameters is somehow still a template. :)
Re: float[] → Vertex[] – decreases performance by 1000%
Hm. Do you ever do pointer arithmetic on Vertex*? Is the size and offsets are correct (like in Vertex vs float)? No, yes. I really have no idea why this happens, I saved the contents of my buffers and compared them with the buffers of the `float[]` version (thanks to `git checkout`) and they were exactly 100% the same. It's a mystery.
Re: normal function and template function conflict
On 2012-07-26 19:57, Simen Kjaeraas wrote: 2) Is there a "correct" workaround? Exactly what you did. Though, for brevity, you would write this: void seed(T : UIntType)(T value = default_seed) Since a template function is actually not wanted this would be the correct workaround: void seed () (UIntType value = default_seed) Less typing as well. -- /Jacob Carlborg
Re: normal function and template function conflict
On Thursday, 26 July 2012 at 18:21:18 UTC, Ali Çehreli wrote: Search for "specialization" in the following resources: Oh... "Specialization". What with D's ability to conditionally implement, I had completely forgotten about specialization. So that's how it's done in D. Cool. Thanks a lot.
Re: normal function and template function conflict
On Thu, 26 Jul 2012 20:14:10 +0200, monarch_dodra
wrote:
On Thursday, 26 July 2012 at 17:57:31 UTC, Simen Kjaeraas wrote:
On Thu, 26 Jul 2012 19:18:21 +0200, monarch_dodra
wrote:
2) Is there a "correct" workaround?
Exactly what you did. Though, for brevity, you would write this:
void seed(T : UIntType)(T value = default_seed)
Thanks
I haven't seen this construct before. Can you tell me a bit more
about it, or link me to some documentation about it?
I suppose it means "T must be UIntType", but I'd enjoy having a broader
understanding of it :)
Ali gave the general, I'll give the specifics.
is(T : Foo), void bar(T : Foo)(T t), and a few others (not really others,
they're exactly the same!) means 'T is implicitly convertible to Foo'.
What's the difference, you ask?
Consider:
void foo(T)(T value) if (is(T == uint)) {}
Could you call this function like this:
foo(3);
The answer is no. The compiler translates this to:
foo!(typeof(3))(3);
And typeof(3) is not uint, it's int.
In contrast,
void foo(T : uint)(T value) {}
foo(3);
is also translated to
foo!(typeof(3))(3);
and the compiler then checks if int is implicitly convertible to uint.
And so it is, so the compiler moves happily onwards.
There is a reason I included is(T : Foo) in the beginning, for you
can write the exact same constraint like this:
void foo(T)(T value) if (is(T : uint)) {}
and it will compile just the same.
For more information on this construct, I would, in addition to the
links Ali provided, recommend you read this:
http://dlang.org/expression.html#IsExpression
IsExpressions are, however, probably the most hairy part of D, and
their understanding has proven troublesome to many (myself included,
though I believe I have grasped them now). Hence, most of their
functionality is wrapped in more easily understandable templates in
std.traits.
--
Simen
Re: normal function and template function conflict
On 07/26/2012 11:14 AM, monarch_dodra wrote: On Thursday, 26 July 2012 at 17:57:31 UTC, Simen Kjaeraas wrote: On Thu, 26 Jul 2012 19:18:21 +0200, monarch_dodra wrote: 2) Is there a "correct" workaround? Exactly what you did. Though, for brevity, you would write this: void seed(T : UIntType)(T value = default_seed) Thanks I haven't seen this construct before. Can you tell me a bit more about it, or link me to some documentation about it? I suppose it means "T must be UIntType", but I'd enjoy having a broader understanding of it :) Search for "specialization" in the following resources: http://dlang.org/template.html https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/dtemplates.pdf http://ddili.org/ders/d.en/templates.html Ali
Re: normal function and template function conflict
On Thursday, 26 July 2012 at 17:57:31 UTC, Simen Kjaeraas wrote: On Thu, 26 Jul 2012 19:18:21 +0200, monarch_dodra wrote: 2) Is there a "correct" workaround? Exactly what you did. Though, for brevity, you would write this: void seed(T : UIntType)(T value = default_seed) Thanks I haven't seen this construct before. Can you tell me a bit more about it, or link me to some documentation about it? I suppose it means "T must be UIntType", but I'd enjoy having a broader understanding of it :)
Re: normal function and template function conflict
On Thu, 26 Jul 2012 19:18:21 +0200, monarch_dodra wrote: So here are my two questions: 1) Is what I was originally trying to do actually illegal, or is it some sort of compiler limitation? TDPL implies this should work perfectly fine... Compiler limitation. It's supposed to work. 2) Is there a "correct" workaround? Exactly what you did. Though, for brevity, you would write this: void seed(T : UIntType)(T value = default_seed) -- Simen
profiling with -profile
I have this code:
import std.stdio;
void main()
{
f();
g();
}
void f()
{
writeln("f()");
}
void g()
{
writeln("g()");
}
I compile with the command:
dmd test.d -profile
Then I execute it. It prints:
f()
g()
as expected. Shouldn't it print profiling information as well?
Re: profiling with -profile
Sorry, I just saw the generated file... :p
normal function and template function conflict
I was trying to write a PRNG, and I wanted to give it two seed
methods. The first is to seed from a unique UIntType, and the
other is to seed from an entire range of seeds. Like so:
void seed(UIntType value = default_seed)
{...}
void seed(Range)(Range range)
if (isInputRange!Range)
{...}
Where UIntType is a template parameter of the struct.
However, this makes the compiler complain, because of a
conflict...? Is mixing normal functions with parametrized ones
impossible?
I *fixed* the issue by contemplating the first call with:
void seed(T)(T value = default_seed)
if (is(typeof(T == UIntType)))
{...}
Problems:
1) It is ugly as sin.
2) The default parameter doesn't work anymore.
So here are my two questions:
1) Is what I was originally trying to do actually illegal, or is
it some sort of compiler limitation? TDPL implies this should
work perfectly fine...
2) Is there a "correct" workaround?
Re: an enum inside another enum
On Thu, 26 Jul 2012 18:08:24 +0200, maarten van damme
wrote:
The newly generated ExtendEnum will try to convert my old enum with
string fields to integer fields. the mixin should generated
"ExtendEnum : string" when passing in an enum with type string. Same
problem apply's to the second line of this sniped. enum a doesn't have
a type yet so it will try to convert everything to ints.
As I seem to run into problems few others have, is my usage of enum's
incorrect?
I had not considered non-int enums in the first version. There is nothing
wrong with the way you use enums, though I haven't yet found a good reason
to extend them (I just like to :p).
Fixed version below:
import std.traits : OriginalType;
string EnumDefAsString(T)() if (is(T == enum)) {
string result = "";
foreach (e; __traits(allMembers, T))
result ~= e ~ " = T." ~ e ~ ",";
return result;
}
template ExtendEnum(T, string s)
if (is(T == enum) &&
is(typeof({mixin("enum a: OriginalType!T {"~s~"}");})))
{
mixin(
"enum ExtendEnum : OriginalType!T {"
~ EnumDefAsString!T() ~ s
~ "}");
}
enum bar : string {
a = "a",
b = "r",
c = "t",
}
enum baz {
a = 1,
b = 2,
c = 3,
}
unittest {
alias ExtendEnum!(bar, q{ // Usage example here.
d = "Text"
}) bar2;
foreach (i, e; __traits(allMembers, bar2)) {
static assert( e == ["a", "b", "c", "d"][i] );
}
assert( bar2.a == bar.a );
assert( bar2.b == bar.b );
assert( bar2.c == bar.c );
assert( bar2.d == "Text" );
static assert(!is(typeof( ExtendEnum!(int, "a";
static assert(!is(typeof( ExtendEnum!(bar, "25";
}
unittest {
alias ExtendEnum!(baz, q{ // Usage example here.
d = 25
}) baz2;
foreach (i, e; __traits(allMembers, baz2)) {
static assert( e == ["a", "b", "c", "d"][i] );
}
assert( baz2.a == baz.a );
assert( baz2.b == baz.b );
assert( baz2.c == baz.c );
assert( baz2.d == 25 );
static assert(!is(typeof( ExtendEnum!(baz, "25";
}
void main() {
}
--
Simen
Re: an enum inside another enum
Such a shame that enums do not allow mixins to be made. This
(mixin(EnumInh!First)) would've been an imho way cleaner solution then
declaring your own kind off enum and doing template magic on that.
I still have some problems with Simen's code (the first one, haven't
yet experimented with enumeration.d)
template ExtendEnum(T, string s)
if (is(T == enum) && is(typeof({mixin("enum a {"~s~"}");}))){
mixin(
"enum ExtendEnum {"
~ EnumDefAsString!T() ~ s
~ "}");
}
The newly generated ExtendEnum will try to convert my old enum with
string fields to integer fields. the mixin should generated
"ExtendEnum : string" when passing in an enum with type string. Same
problem apply's to the second line of this sniped. enum a doesn't have
a type yet so it will try to convert everything to ints.
As I seem to run into problems few others have, is my usage of enum's incorrect?
Re: float[] → Vertex[] – decreases performance by 1000%
On 26-Jul-12 14:14, David wrote: Ok, interesting thing. I switched my buffer from Vertex* to void* and I cast every Vertex I get to void[] and add it to the buffer (slice → memcopy) and everything works fine now. I can live with that (once the basic functions are implemented it's not even a pain to use), but still, I wonder where the problem is. Hm. Do you ever do pointer arithmetic on Vertex*? Is the size and offsets are correct (like in Vertex vs float)? -- Dmitry Olshansky
Re: an enum inside another enum
I've also written this implementation of enumerations. It's a bit different from normal D enums, but supports inheritance, guarantees unique values, as is much more conservative in what conversions and operations it allows. I'm considering adding addition and subtraction of integers as valid operations, but I'm not sure I want to. Feel free to critique, hack, improve upon and otherwise use and abuse the code. -- Simen enumeration.d Description: Binary data
Re: an enum inside another enum
On Thu, 26 Jul 2012 15:07:56 +0200, bearophile wrote: but isn't D supporting mixins inside enums? Nope. "The text contents of the string must be compilable as a valid StatementList, and is compiled as such." And enums don't allow statements in their body. -- Simen
Re: an enum inside another enum
maarten van damme:
enum first : string{
a="a",
b="b"
}
enum second : string{
a=first.a,
b=first.b,
c="c"
}
Is there a way to make this cleaner?
By convention in D enum names start with an upper case.
I have tried this, partially derived by Simen Kjaeraas code (with
T.stringof), but isn't D supporting mixins inside enums?
string EnumInh(T)() if (is(T == enum)) {
string result;
foreach (e; __traits(allMembers, T))
result ~= e ~ " = " ~ T.stringof ~"." ~ e ~ ",\n";
return result;
}
enum First : string {
a = "a",
b = "b"
}
enum Second : string {
mixin(EnumInh!First),
c = "c"
}
void main() {}
Bye,
bearophile
Re: an enum inside another enum
On Thu, 26 Jul 2012 13:40:06 +0200, maarten van damme
wrote:
enum first : string{
a="a",
b="b"
}
enum second : string{
a=first.a,
b=first.b,
c="c"
}
Is there a way to make this cleaner?
string EnumDefAsString(T)() if (is(T == enum)) {
string result = "";
foreach (e; __traits(allMembers, T))
result ~= e ~ " = T." ~ e ~ ",";
return result;
}
template ExtendEnum(T, string s)
if (is(T == enum) &&
is(typeof({mixin("enum a{"~s~"}");})))
{
mixin(
"enum ExtendEnum {"
~ EnumDefAsString!T() ~ s
~ "}");
}
enum bar
{
a = 1,
b = 7,
c = 19
}
import std.typetuple;
void main() {
//---
alias ExtendEnum!(bar, q{ // Usage example here.
d = 25
}) bar2;
//---
foreach (i, e; __traits(allMembers, bar2)) {
static assert( e == TypeTuple!("a", "b", "c", "d")[i] );
}
assert( bar2.a == bar.a );
assert( bar2.b == bar.b );
assert( bar2.c == bar.c );
assert( bar2.d == 25 );
static assert(!is(typeof( ExtendEnum!(int, "a";
static assert(!is(typeof( ExtendEnum!(bar, "25";
}
--
Simen
Re: an enum inside another enum
On 2012-07-26 13:40, maarten van damme wrote:
Hi, would the response to this question :
http://stackoverflow.com/questions/757684/enum-inheritance be the same
for D?
I have these two enums:
enum first : string{
a="a",
b="b"
}
enum second : string{
a=first.a,
b=first.b,
c="c"
}
Is there a way to make this cleaner? I don't mind having something like
second.firstchar.a
with firstchar beeing a "first" enum.
To do that I would need to tell the enum that it can also use the type
"first" because in the end, that is a string too...
I'm pretty sure it's possible to do with some meta programming magic.
--
/Jacob Carlborg
Re: Simple D Questions (static if / #pragma / int[3][3])
On Thu, 26 Jul 2012 13:34:34 +0200, bearophile wrote: static assert(0, "..."); But in release mode it doesn't print the message. Now that'd be something. :p -- Simen
Re: Simple D Questions (static if / #pragma / int[3][3])
On 2012-07-26 13:22, Wes wrote:
2. Is there a command such as #error or #warning in D?
I assume this is maybe #pragma (msg, "error message") static
assert(0);?
D doesn't really have any of these, but you can emulate them. You can use:
pragma(msg, "warning: message")
To emulate a warning. This will be printed during compilation. For
#error you can use:
static assert(0, "error message");
This will halt the compilation with the given message.
3. Can you use static if() {} with the {} block?
None of the examples had it. I know it's because of scope
issues... but I'd hate to have to write static if(x) 5 times in a
row for 5 variables.
Yes, you can use {} after a static-if:
static if (a) {}
else {}
Note that even though you use {} it will not introduce a new scope:
import std.stdio;
static if (true) { int a = 3; }
void main () { writeln(a); }
--
/Jacob Carlborg
an enum inside another enum
Hi, would the response to this question :
http://stackoverflow.com/questions/757684/enum-inheritance be the same
for D?
I have these two enums:
enum first : string{
a="a",
b="b"
}
enum second : string{
a=first.a,
b=first.b,
c="c"
}
Is there a way to make this cleaner? I don't mind having something like
second.firstchar.a
with firstchar beeing a "first" enum.
To do that I would need to tell the enum that it can also use the type
"first" because in the end, that is a string too...
Re: Simple D Questions (static if / #pragma / int[3][3])
Wes:
1. Is int[3,3] the same in memory as int[3][3]?
I can't really tell based on the description.
http://dlang.org/arrays.html
Your first syntax is more like C#, not D.
In D there are fixed-sized arrays like your second one, and it's
rectangular, it's nine adjacent integers.
A dynamic array of length 3 of a dynamic of 3 integers, created
like this:
new int[][](3, 3)
is a very different data structure. It's a 2-word that contains
length and pointer, the pointer points to 3 2-words that contain
length and pointer, each one pointing to a 3-int chunk of memory
(plus on each row a bit of bookeeping for the GC and to append
new items).
2. Is there a command such as #error or #warning in D?
I assume this is maybe #pragma (msg, "error message") static
assert(0);?
pragma(msg, "...") is for compile time messages.
Maybe an alternative is to use:
static assert(0, "...");
But in release mode it doesn't print the message.
3. Can you use static if() {} with the {} block?
Yes, also the "else" part supports the braces {}. But keep in
mind the braces don't create a scope for the names.
Bye,
bearophile
Simple D Questions (static if / #pragma / int[3][3])
1. Is int[3,3] the same in memory as int[3][3]?
I can't really tell based on the description.
http://dlang.org/arrays.html
2. Is there a command such as #error or #warning in D?
I assume this is maybe #pragma (msg, "error message") static
assert(0);?
3. Can you use static if() {} with the {} block?
None of the examples had it. I know it's because of scope
issues... but I'd hate to have to write static if(x) 5 times in a
row for 5 variables.
Re: float[] → Vertex[] – decreases performance by 1000%
Ok, interesting thing. I switched my buffer from Vertex* to void* and I cast every Vertex I get to void[] and add it to the buffer (slice → memcopy) and everything works fine now. I can live with that (once the basic functions are implemented it's not even a pain to use), but still, I wonder where the problem is.
Re: Tid is not a process id?
On Wednesday, 25 July 2012 at 02:05:14 UTC, Chris NS wrote: Not sure yet what your exactly issue is, but have you tried to reproduce it using register/lookup? Bad post, that example was OK. The places where I was having errors was from exceptions being lost. Thanks.
