Re: D / GtkD for SQL Server
On 11/06/2013 02:36 AM, Jacob Carlborg wrote: On 2013-11-06 08:28, John J wrote: Thanks Jacob, I guess I have to compile and distribute a FreeTDS.dll, and it only works for win32 FreeTDS works on Posix platforms. I wrote that code on Mac OS X. We use FreeTDS in production, running servers on Linux, every day. Sorry, I meant to say FreeTDS doesn't seem to support 64-bit Windows.
How to compile and test samples under Windows?
I installed the DMD32 D Compiler v2.063.2 into C:\ I try to complie and test the dserver.d sample specifically, but when I run build.bat in the dmd2\samples\d directory, I've got the following errors. C:\D\dmd2\samples\d..\..\windows\bin\shell all.sh shell 1.05 ..\..\windows\bin\dmd d2html d2html.d(38): Error: undefined identifier whitespace d2html.d(45): Error: undefined identifier letters d2html.d(51): Error: undefined identifier digits d2html.d(57): Error: undefined identifier hexdigits d2html.d(63): Error: undefined identifier octdigits --- errorlevel 1 What did I do wrong? What could be missing?
Re: Small troubles with private
On Wednesday, 6 November 2013 at 07:46:00 UTC, Jacob Carlborg wrote: Which other languages? private in Ruby and Java is not the same. The one's which implement private as meaning accessible to the class only.
Re: Small troubles with private
On Wednesday, 6 November 2013 at 07:46:00 UTC, Jacob Carlborg wrote: Which other languages? private in Ruby and Java is not the same. The one's which implement private as meaning accessible to the class only.
Re: How to compile and test samples under Windows?
On Wednesday, 6 November 2013 at 09:02:57 UTC, Adam Ryczkowski wrote: I installed the DMD32 D Compiler v2.063.2 into C:\ I try to complie and test the dserver.d sample specifically, but when I run build.bat in the dmd2\samples\d directory, I've got the following errors. C:\D\dmd2\samples\d..\..\windows\bin\shell all.sh shell 1.05 ..\..\windows\bin\dmd d2html d2html.d(38): Error: undefined identifier whitespace d2html.d(45): Error: undefined identifier letters d2html.d(51): Error: undefined identifier digits d2html.d(57): Error: undefined identifier hexdigits d2html.d(63): Error: undefined identifier octdigits --- errorlevel 1 What did I do wrong? What could be missing? you are running .sh script instead of .bat on windows. and looks like this samples a bit outdated, though d2html looks fine.
Re: Module or Dictionary corrupt
On Wednesday, 6 November 2013 at 01:04:10 UTC, Jonathan M Davis wrote: On Wednesday, November 06, 2013 00:22:13 Namespace wrote: OPTLINK (R) for Win32 Release 8.00.13 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html Debug\Foo.obj Offset 0H Record Type 0064 Error 138: Module or Dictionary corrupt Building Debug\Foo.exe failed! That's what I get when I compile with-m64. What is wrong? -m64 shouldn't even be using optlink. On Windows, 64-bit links with the Visual Studio linker, not optlink. I think that you may have to set up your sc.ini differently for that though, which would mean that you couldn't simply switch between -m32 and -m64 on Windows. But I don't know for sure, because I almost never build in Windows, and I have yet to mess around with 64-bit D on Windows. - Jonathan m Davis Should I open a bug for this?
UFCS with constructors
import std.typecons: Typedef;
alias Foo = Typedef!double;
void main() {
auto a1 = Foo(1);
pragma(msg, typeof(a1));
auto a2 = 1.Foo;
pragma(msg, typeof(a2));
auto a3 = Foo(-1);
pragma(msg, typeof(a3));
auto a4 = -1.Foo;
pragma(msg, typeof(a4));
}
It prints:
Typedef!(double, nan)
Typedef!(double, nan)
Typedef!(double, nan)
double
Is this expected/acceptable/good?
Bye,
bearophile
Re: How to compile and test samples under Windows?
Thank you for the answer. This is the contents of the build.bat, which is shipped with the D instalation: ..\..\windows\bin\shell all.sh Can you tell me, what is outdated?
Re: Module or Dictionary corrupt
On Wednesday, 6 November 2013 at 10:13:07 UTC, Namespace wrote: Should I open a bug for this? you should fix ur sc.ini first to use visual studio linker for x64 and optlink for x86, you can use dmd 2.064.2 installer now to do so automatically.
Re: UFCS with constructors
On Wednesday, 6 November 2013 at 11:04:05 UTC, bearophile wrote:
import std.typecons: Typedef;
alias Foo = Typedef!double;
void main() {
auto a1 = Foo(1);
pragma(msg, typeof(a1));
auto a2 = 1.Foo;
pragma(msg, typeof(a2));
auto a3 = Foo(-1);
pragma(msg, typeof(a3));
auto a4 = -1.Foo;
pragma(msg, typeof(a4));
}
It prints:
Typedef!(double, nan)
Typedef!(double, nan)
Typedef!(double, nan)
double
Is this expected/acceptable/good?
Operator precedence of . is higher than unary minus. That
should be the explanation, why the fourth output is different
than the others.
However, what is Typedef for?
Limiting template functions to template instantiations of a struct
The title isn't very clear but I wasn't sure how to phrase it
without code. Basically what I want to do is this (won't compile):
struct Foo(int N) {
}
void func(T)(T obj) if(is(T:Foo)) {
}
void func(T)(T obj) if(!is(T:Foo)) {
}
Foo by itself isn't a type, but I don't want to limit func
instantiation in the 1st case to just e.g. Foo!3 but to _any_ Foo
regardless of N. I came up with two workarouds: make Foo a class
that derives from an empty FooBase (then is(T:FooBase) works), or
adding a secret enum within Foo that I can check with
std.traits.hasMember in a static if. I don't really like either
of them. Is what I want to do possible?
Atila
Re: Small troubles with private
On Tue, 05 Nov 2013 16:00:41 -, bearophile bearophileh...@lycos.com wrote: 1) I usually write more than one class or struct inside each D module, unlike in Java. But sometimes when I move that class or struct elsewhere (during refactoring, or in other situations) I get access errors to private fields. Those errors were already in my code, but I didn't see them because private in D means module-private. 2) My unittests are useful to catch bugs when I run them at run-time, but they are also use to exercise code, this means to actually use it, and catch some bugs statically (instantiating templates, etc). But unfortunately such unittests can't catch protection bugs because most of my unittests are inside the same module, so private gets ignored. 3) A third problem with module-private is that newbies coming from Python, C, and other languages that don't have private/protected attributes and write little experimental D programs, have less chances to _learn_ the true semantics of the privacy attributes until they start to spread their classes in different modules. How to solve such little troubles? A possible idea is to add to D another attribute, a kind of private private that is enforced inside the same module. It could be named super private because D has the super keyword :-) But this idea doesn't solve all the problems, because sometimes you don't want to use a super private attribute. I think a compiler flag is the best option. The flag would cause warnings to appear for each violation of strict privacy between classes in the same module. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Limiting template functions to template instantiations of a struct
On Wednesday, 6 November 2013 at 13:00:17 UTC, Atila Neves wrote:
The title isn't very clear but I wasn't sure how to phrase it
without code. Basically what I want to do is this (won't
compile):
struct Foo(int N) {
}
void func(T)(T obj) if(is(T:Foo)) {
}
void func(T)(T obj) if(!is(T:Foo)) {
}
Foo by itself isn't a type, but I don't want to limit func
instantiation in the 1st case to just e.g. Foo!3 but to _any_
Foo regardless of N. I came up with two workarouds: make Foo a
class that derives from an empty FooBase (then is(T:FooBase)
works), or adding a secret enum within Foo that I can check
with std.traits.hasMember in a static if. I don't really like
either of them. Is what I want to do possible?
Atila
Here's a couple of different ways to do this.
import std.stdio;
struct Foo(int N) {
}
void func(T)(T obj) if(is(T:Foo!U, int U)) {
writeln(It's a Foo!);
}
void func(T)(T obj) if(!is(T:Foo!U, int U)) {
writeln(No Foo :();
}
template isFoo(T) {
static if(is(T:Foo!U, int U))
enum isFoo = true;
else
enum isFoo = false;
}
void gunc(T)(T obj) if(isFoo!T) {
writeln(Gunc isFoo);
}
void gunc(T)(T obj) if(!isFoo!T) {
writeln(Gunc !isFoo);
}
void hunk(T)(T obj) {
static if(isFoo!T)
writeln(Hunk!);
else
writeln(No hunk!);
}
void main() {
Foo!3 f;
func(f); // It's a Foo!
struct S {}
S s;
func(s); // No Foo :(
gunc(f); // Gunc isFoo
gunc(s); // Gunc !isFoo
hunk(f); // Hunk!
hunk(s); // No hunk!
}
Re: fieldPostBlit - what is wrong with this and workarounds
On Friday, 1 November 2013 at 20:29:54 UTC, Jonathan M Davis
wrote:
On Friday, November 01, 2013 14:28:55 Daniel Davidson wrote:
On Thursday, 31 October 2013 at 19:39:44 UTC, Jonathan M Davis
Deep copying is not the only reason to have a postblit. Smart
pointers such as
std.typecons.RefCounted require a postblit (or copy constructor
if we had
those) to do their job. Also, even if all you want is a deep
copy, it's
possible that the member being deep copied was allocated via
something like
malloc, in which case, the compiler couldn't take care of it
for you.
So, deepCopy is a reason for postblit and I probably common for
those not wanting shared state. You have mentioned two more uses
for postblit, ref counting and dealing with something allocated
with malloc. Honestly I am not sure the impact of the latter. Are
you referring to `struct T { S *s }` where the s was allocated
with malloc? I think you give up on const/immutable when ref
counting anyway? Regardless, I imagine both of those cases are on
the less common side and are probably not too troubled by const
issues. I'm not suggesting getting rid of postblit. Neither am I
against constructors. It just sounds like adding constructors is
overkill if support for immutable language generated postblit
were available. And I think it would be easy to add.
I'm just suggesting add an annotation that marks fields to be
duped by a language generated postblit. The developer would not
need to implement the postblit and it would be clear when/where
sharing occurs. Then the language is still guaranteed immutable
correct when using the language generated postblit.
I am now convinced avoiding `const(T) t` as a member is wise
advice. The suggestion of leaving it non-const and providing a
const accessor is good - but it won't prevent module code from
modifying it. I really want to make sure it is not being
mutated.
So I'm now leaning toward this approach:
struct S {
const(T) *rc;
}
so I won't have the copy/postblit issues. Doesn't this bypass
the
problems with `const(T) t`. The new risk is that somehow that
member variable is initialized with a stack variable.
If you do that, then rc can be mutated (and so the struct can
be mutated), but
what it points to can't be. So, from the sounds if it, it does
what you want.
Though honestly, I wouldn't worry about the rest of a module
mutating your
member variable just because it has access to it.
Correct - I'm not worried about rc being modified as it is pretty
easy to control that.
I was under the impression it is pretty easy to
innocently/unknowingly mutate data. Suppose a member function
passes that member `t` to any function in any other module. With
slices and maps, what is really being passed around are pointers.
Once you start passing them around in a non-const or
non-immutable context you have objects sharing the same pieces
data and eventually it could be changed, even though not in your
module.
If you simply name member
variables differently than the public API (e.g _rc instead of
rc) and then
provide a const property to access the member, then the odds
are very low that
you're going to accidentally access the member directly. And if
you can't keep
track of what's in a single module well enough to avoid this
sort of problem,
then your module is probably too big.
Not sure I agree because passing non-const instances to functions
anywhere in the system is now allowed if the member is non-const.
So it has less to do with the size of your module and more to do
with where you are passing it. If you are passing it around
non-const the door is wide open.
But if you're paranoid, you can
certainly add an extra layer indirection like you're
suggesting. I wouldn't
bother though.
- Jonathan M Davis
Clearly I am paranoid :-)
But I think it is the case that const(T) and immutable(T) would
be just fine and your reservations would be gone if the postblit
were in fact immutable. If this were the case, wouldn't you
change your stance and recommend const(T) or immutable(T) if in
fact that is what the expectation is for the developer.
Thanks
Dan
Re: Small troubles with private
On 11/05/2013 05:00 PM, bearophile wrote: 1) I usually write more than one class or struct inside each D module, unlike in Java. But sometimes when I move that class or struct elsewhere (during refactoring, or in other situations) I get access errors to private fields. Those errors were already in my code, but I didn't see them because private in D means module-private. 2) My unittests are useful to catch bugs when I run them at run-time, but they are also use to exercise code, this means to actually use it, and catch some bugs statically (instantiating templates, etc). But unfortunately such unittests can't catch protection bugs because most of my unittests are inside the same module, so private gets ignored. 3) A third problem with module-private is that newbies coming from Python, C, and other languages that don't have private/protected attributes and write little experimental D programs, have less chances to _learn_ the true semantics of the privacy attributes until they start to spread their classes in different modules. How to solve such little troubles? A possible idea is to add to D another attribute, a kind of private private that is enforced inside the same module. It could be named super private because D has the super keyword :-) But this idea doesn't solve all the problems, because sometimes you don't want to use a super private attribute. Bye, bearophile How about just adding full granularity? By condition: @visibleIf!true // public @visibleIf!(isSubtypeOf!(typeof(this))) // protected By explicit enumeration: @visible!(getModule!(typeof(this))) // private @visible!(typeof(this), T) // visible to type 'T' @visible!(typeof(this)) // 'super private' @visible!foo // only (member) function 'foo' can access it @visible!() // nobody can access it
Re: How to compile and test samples under Windows?
On Wednesday, 6 November 2013 at 10:38:29 UTC, Adam Ryczkowski wrote: Thank you for the answer. This is the contents of the build.bat, which is shipped with the D instalation: ..\..\windows\bin\shell all.sh Can you tell me, what is outdated? pi sample at least has compile errors.
Re: How to compile and test samples under Windows?
...All the samples I use are shipped with the DMD32 D Compiler v2.063.2 instalation package for Windows. I've just reinstalled D to make sure that.
Re: How to compile and test samples under Windows?
On Wednesday, 6 November 2013 at 10:46:39 UTC, Adam Ryczkowski wrote: ...All the samples I use are shipped with the DMD32 D Compiler v2.063.2 instalation package for Windows. I've just reinstalled D to make sure that. no, i mean its not get updated to fetch with phobos changes. though it should be simple to fix.
Re: Operator Precedence and Associativity
On 11/06/2013 04:34 AM, Tyro[17] wrote: I’m sure the following table is missing a few items but am unclear what they are. For starters these , =, , , !, != belong on the table but I’m not sure where. I am also not sure if these ..., @, # belong there at all. There might be other errors or missing operators. Request assist to complete correctly. ... I have some time ago compiled my own table, which can be found here: http://wiki.dlang.org/Operator_precedence
Re: Limiting template functions to template instantiations of a struct
On Wednesday, 6 November 2013 at 13:00:17 UTC, Atila Neves wrote:
The title isn't very clear but I wasn't sure how to phrase it
without code. Basically what I want to do is this (won't
compile):
struct Foo(int N) {
}
void func(T)(T obj) if(is(T:Foo)) {
}
void func(T)(T obj) if(!is(T:Foo)) {
}
Foo by itself isn't a type, but I don't want to limit func
instantiation in the 1st case to just e.g. Foo!3 but to _any_
Foo regardless of N. I came up with two workarouds: make Foo a
class that derives from an empty FooBase (then is(T:FooBase)
works), or adding a secret enum within Foo that I can check
with std.traits.hasMember in a static if. I don't really like
either of them. Is what I want to do possible?
Atila
This works:
http://dpaste.dzfl.pl/f98f4783
Re: UFCS with constructors
qznc: Operator precedence of . is higher than unary minus. Is this good? However, what is Typedef for? It's to create a differently named type, useful for stronger static typing, to increase code clarity and avoid some bugs. If you have a function like this: double foo(in double x, in double k) pure nothrow You can give it swapped arguments (also because D still lacks named arguments). But if you define a: alias Coordinate = Typedef!double; Coordinate foo(in Coordinate x, in double k) pure nothrow You will have less mistakes. Currently Typedef has some bugs. Bye, bearophile
How to re-initialise an associative array.
A simple request but i'm failing hard. How do i re-init an
associative array? This is obviously not the way:
import std.stdio;
void main(string[] args)
{
int[string] x;
x[hello] = 1;
x[world] = 2;
writefln(%s, x);
x = new int[string];
writefln(%s, x); // Should be empty.
}
Re: How to re-initialise an associative array.
On Wednesday, 6 November 2013 at 16:15:36 UTC, Gary Willoughby
wrote:
A simple request but i'm failing hard. How do i re-init an
associative array? This is obviously not the way:
import std.stdio;
void main(string[] args)
{
int[string] x;
x[hello] = 1;
x[world] = 2;
writefln(%s, x);
x = new int[string];
writefln(%s, x); // Should be empty.
}
Maybe there's a neater way but x = x.init works.
Re: How to re-initialise an associative array.
On Wednesday, 6 November 2013 at 16:15:36 UTC, Gary Willoughby
wrote:
A simple request but i'm failing hard. How do i re-init an
associative array? This is obviously not the way:
import std.stdio;
void main(string[] args)
{
int[string] x;
x[hello] = 1;
x[world] = 2;
writefln(%s, x);
x = new int[string];
writefln(%s, x); // Should be empty.
}
x.clear();
Re: How to re-initialise an associative array.
On Wednesday, 6 November 2013 at 16:41:19 UTC, Gary Willoughby wrote: x.clear(); I looked at that but apparently it leaves the array in an unsafe state. Source: http://forum.dlang.org/thread/iu3ll6$2d48$1...@digitalmars.com Wow! Good to know, thanks!
Re: How to re-initialise an associative array.
On Wednesday, 6 November 2013 at 16:34:13 UTC, Daniel Davidson
wrote:
On Wednesday, 6 November 2013 at 16:15:36 UTC, Gary Willoughby
wrote:
A simple request but i'm failing hard. How do i re-init an
associative array? This is obviously not the way:
import std.stdio;
void main(string[] args)
{
int[string] x;
x[hello] = 1;
x[world] = 2;
writefln(%s, x);
x = new int[string];
writefln(%s, x); // Should be empty.
}
x.clear();
I looked at that but apparently it leaves the array in an unsafe
state.
Source:
http://forum.dlang.org/thread/iu3ll6$2d48$1...@digitalmars.com
Re: How to re-initialise an associative array.
On Wednesday, 6 November 2013 at 16:41:19 UTC, Gary Willoughby
wrote:
I looked at that but apparently it leaves the array in an
unsafe state.
Source:
http://forum.dlang.org/thread/iu3ll6$2d48$1...@digitalmars.com
Is that still the case? The following seems to work just fine.
Maybe Kenji has been working his magic :-) ?
import std.stdio;
void main() {
string[string] foo = [a : a, b : B];
writeln(foo);
foo.clear();
writeln(foo);
writeln(foo.length);
foo[x] = this is a test;
writeln(foo);
writeln(foo.length);
}
-
[a:a, b:B]
[]
0
[x:this is a test]
1
Re: How to re-initialise an associative array.
On Wednesday, 6 November 2013 at 16:49:44 UTC, Daniel Davidson
wrote:
On Wednesday, 6 November 2013 at 16:41:19 UTC, Gary Willoughby
wrote:
I looked at that but apparently it leaves the array in an
unsafe state.
Source:
http://forum.dlang.org/thread/iu3ll6$2d48$1...@digitalmars.com
Is that still the case? The following seems to work just fine.
Maybe Kenji has been working his magic :-) ?
import std.stdio;
void main() {
string[string] foo = [a : a, b : B];
writeln(foo);
foo.clear();
writeln(foo);
writeln(foo.length);
foo[x] = this is a test;
writeln(foo);
writeln(foo.length);
}
-
[a:a, b:B]
[]
0
[x:this is a test]
1
I'm not taking the chance and currently using:
x = (int[string]).init;
Re: UFCS with constructors
On 11/06/2013 03:04 AM, bearophile wrote:
import std.typecons: Typedef;
alias Foo = Typedef!double;
void main() {
auto a1 = Foo(1);
pragma(msg, typeof(a1));
auto a2 = 1.Foo;
pragma(msg, typeof(a2));
auto a3 = Foo(-1);
pragma(msg, typeof(a3));
auto a4 = -1.Foo;
pragma(msg, typeof(a4));
}
It prints:
Typedef!(double, nan)
Typedef!(double, nan)
Typedef!(double, nan)
double
Is this expected/acceptable/good?
Bye,
bearophile
I would be very surprised if unary - produced a different type from
the operand:
import std.typecons: Typedef;
alias Foo = Typedef!double;
void main() {
auto a = 1.Foo;
auto b = -a;
static assert (is (typeof(a) == typeof(b)));// FAILS!
}
After all, we are used to hidden bugs based on that expectation: ;)
void main()
{
uint a = 1;
auto b = -a;
assert(b == uint.max); // WT?
static assert(is (typeof(b) == uint)); // -- the reason
}
Seriously though, yeah, unary - must return Typedef!(double, nan).
Ali
Re: How to re-initialise an associative array.
On Wed, Nov 06, 2013 at 05:15:34PM +0100, Gary Willoughby wrote:
A simple request but i'm failing hard. How do i re-init an
associative array?
[...]
Just assign null to it:
import std.stdio;
void main() {
int[string] aa;
aa[a] = 1;
aa[b] = 2;
writeln(aa);
aa = null;
aa[a] = 2;
aa[b] = 1;
writeln(aa);
}
Output:
[a:1, b:2]
[a:2, b:1]
The GC will take care of cleaning up the old data.
T
--
Don't get stuck in a closet---wear yourself out.
Re: UFCS with constructors
On Wednesday, 6 November 2013 at 17:10:34 UTC, Ali Çehreli wrote: I would be very surprised if unary - produced a different type from the operand: Ali Operator does not produce type, it produces value of expression, and type of expression happens not to be the type you expected. But such expectations need not correspond to language rules (try to think from from language laywer perspective). In bearophile case, I guess Typedef!double overloads unary operator which returns double which is primary reason for such behavior.
Re: How to re-initialise an associative array.
On Wednesday, 6 November 2013 at 17:49:41 UTC, H. S. Teoh wrote: The GC will take care of cleaning up the old data. T Unfortunately it will not take care of calling struct destructors.
Re: UFCS with constructors
On 11/06/2013 09:46 AM, Maxim Fomin wrote: On Wednesday, 6 November 2013 at 17:10:34 UTC, Ali Çehreli wrote: I would be very surprised if unary - produced a different type from the operand: Ali Operator does not produce type, it produces value of expression, and type of expression happens not to be the type you expected. Thanks. That's what I meant. :) But such expectations need not correspond to language rules (try to think from from language laywer perspective). I still argue that the expression -expr must have the same type as expr. In bearophile case, I guess Typedef!double overloads unary operator which returns double which is primary reason for such behavior. That's what I deduced from qznc's post and tried to mean that such behavior would be confusing to programmers. Ali
Re: Associative Array: reasonable limits?
06-Nov-2013 00:36, Charles Hixson пишет: On 11/05/2013 05:34 AM, Dmitry Olshansky wrote: 05-Nov-2013 02:20, Charles Hixson пишет: On 11/03/2013 01:46 AM, Dmitry Olshansky wrote: 03-Nov-2013 02:37, Charles Hixson пишет: I'm contemplating an associative array that will eventually grow to be an estimated 64KB in size, assuming it's about half full. It would then be holding around 90,000 entries. Is this reasonable, or should I go with a sorted array, and do binary searches? I estimate that binary searches would average around 15 accesses/hit, but that's still a lot faster than disk access. The array would be nearly full, so there would be less wasted space, but, of course, insertions would become quite expensive. (Deletions aren't expected.) In either case the keys would be fixed length character arrays, and the values would also be simple structs without reference types (so the garbage collector could pretty much ignore things). 90k elements is a small AA. It would work just fine with any sane hash function (e.g. the built-in one). At around 10M+ elements it may be worth to consider space saving techniques. That said on x64 100M+ is perfectly OK, on 32bit I'd advise against it but only because of GC. FWIW I'm expecting this array to be around the entire time the program is running, but it would probably be rolled out most of the time, as frequently accessed items would be pulled into a much smaller structure, and if I go with the array rather than the hash table I may only do updates as a batch. (Since it's linear with the size of the array, but essentially ignores the number of items being added.) My temptation is to go with the hash table...but I'm not sure of the underlying mechanics. Think of it as a sparse array that has holes and takes around ~2-4 times the size of normal array. It's not only because of holes but because a slot is a bit bigger. In return lookups/inserts/deletions are cheap O(1) with high probability. Thanks, I'd been assuming that it would just be around 128 bytes larger (i.e., two pointers) and around a 50% fill rate. Sounds like a bit worse than I was estimating...not hugely worse though. OTOH, that's an argument in favor of using a small cache that is a hash table, and a large array as a backing store, where infrequently accessed items could be kept. Probably if the cache could hold around 2,000 entries it would have over a 90% hit rate (though that would need to be tested). What's your requirements for this data-structure anyway? Still no answer. I'm asking it only because designing any data-structure w/o answering this first is an exercise in futility. It seems like priority is lookup speed and data size. Search for succint data-structures if you really want to dive that deep. I'd recommend it only for fun, not for the task at hand. I'm not sure about the batch adds. I certainly won't do it at first, while the data is small. The thing is, I want to keep as much as feasible rolled out most of the time. That means that while it's active in RAM that RAM is actually pages on the disk of virtual memory. With a large hash table, that's not likely to be controllable. What I'm doing here is optimizing for speed and... where and includes active memory use (as opposed to rolled out virtual memory). A part of what makes a hash table efficient is that it's always in RAM. The moment you start using data it all gets in RAM pretty soon (potentially with a few of page faults). After that point you may as well forget about page system and virtual memory. The thing is that number of page faults is environment dependent anyway an is a constant cost compared to any operations on data. If you need to roll it in to access it, then you lose most of the efficiency. A sorted array is a pretty straightforwards data structure. It's reasonably quick to access, though not as fast as a hash table. The real killer is insertion (or deletion). And it doesn't lose anywhere near as much by being rolled out (for one thing, each page holds about twice as much data, so you don't need as many reads). I doubt you'll ever be able to measure this effect on top of OS induced noise. Thing is OS will keep pages forever in RAM anyway if there is plenty of it. And if it's paging on every call to your tiny dataset - you have far-far bigger problems anyway. And it's easy to save to external disk. (You can size it easily so that when starting up the program again, the array is initialized at the correct size.) *Yawn* Anyhow you'd serialize it in some format. Maybe even text ;) I had actually for a long time considered just using a database, but I can't control how the database caches things in RAM. I want the cache to have a long term usage memory as well as recent use, and doing that with a database is just too complex. Yes, this is sort of like a database, but except for some databases that store everything in RAM, it's not the same. There is this moment
Re: UFCS with constructors
On Wednesday, 6 November 2013 at 18:02:32 UTC, Ali Çehreli wrote: But such expectations need not correspond to language rules (try to think from from language laywer perspective). I still argue that the expression -expr must have the same type as expr. In bearophile case, I guess Typedef!double overloads unary operator which returns double which is primary reason for such behavior. That's what I deduced from qznc's post and tried to mean that such behavior would be confusing to programmers. Ali I think that reason for such behavior is the way used defined operator overloading functions are implemented, not the language per se, so programmers confuse themselves.
Re: UFCS with constructors
On Wednesday, 6 November 2013 at 18:16:04 UTC, Maxim Fomin wrote: I think that reason for such behavior is the way used defined operator overloading functions are implemented, not the language per se, so programmers confuse themselves. What about other possible reason - Typedef implementation sucks? ;)
How to iterate through all modules for use with the new getUnitTests trait?
As part of developing the DUnit framework i'm looking into
executing the unit test at a more fine grain level. The new
'getUnitTests' trait looks interesting but it's value is a symbol
of an aggregate (e.g. struct/class/module).
foreach (module_; ModuleInfo)
{
if (module_)
{
foreach (unitTest; __traits(getUnitTests, module_.name))
{
...
}
}
}
Obviously the 'module_.name' property doesn't work in this
scenario so i wondered how can i iterate through the all of the
compiling modules to make this code work?
who to use -allinst
Could someone please explain the new -allinst compiler flag? Is it supposed to be used on static libraries or on the executable using templates from those static libraries? Kind Regards Benjamin Thaut
Re: who to use -allinst
On Wednesday, 6 November 2013 at 19:33:10 UTC, Benjamin Thaut wrote: Could someone please explain the new -allinst compiler flag? Is it supposed to be used on static libraries or on the executable using templates from those static libraries? Kind Regards Benjamin Thaut It is a hack that returns old template instantiation behavior because Walter did not have time to track all failures of new implementation and did not want to revert it. Use it as soon as you encounter weird linker errors unexplainable by anything else.
Re: How to iterate through all modules for use with the new getUnitTests trait?
module aaa;
import std.string;
template Alias(alias S)
{
alias Alias = S;
}
void main()
{
import std.string;
foreach (symbol_name; __traits(allMembers, aaa))
{
alias symbol = Alias!(__traits(getMember, aaa, symbol_name));
static if (symbol.stringof.startsWith(module ))
{
}
else static if (symbol.stringof.startsWith(package ))
{
// recursion
}
}
}
Re: who to use -allinst
Am 06.11.2013 20:48, schrieb Dicebot: On Wednesday, 6 November 2013 at 19:33:10 UTC, Benjamin Thaut wrote: Could someone please explain the new -allinst compiler flag? Is it supposed to be used on static libraries or on the executable using templates from those static libraries? Kind Regards Benjamin Thaut It is a hack that returns old template instantiation behavior because Walter did not have time to track all failures of new implementation and did not want to revert it. Use it as soon as you encounter weird linker errors unexplainable by anything else. Well I encounter strange linker errors since 2.064. The question is if it is supposed to be used when compiling the executable or when compiling the static library. Kind Regards Benjamin Thaut.
Re: who to use -allinst
On Wednesday, 6 November 2013 at 20:02:42 UTC, Benjamin Thaut wrote: Well I encounter strange linker errors since 2.064. The question is if it is supposed to be used when compiling the executable or when compiling the static library. You are trying to think about it about a normal feature with intended use cases. It is not. For now I'd recommend to always use it in release builds but remove it time to time and report all linker failures without it to bugzilla - maybe we will manage to implement it properly until 2.065 tl; dr: it is rollback switch for broken feature that was not reverted
Re: who to use -allinst
Am 06.11.2013 21:14, schrieb Dicebot: On Wednesday, 6 November 2013 at 20:02:42 UTC, Benjamin Thaut wrote: Well I encounter strange linker errors since 2.064. The question is if it is supposed to be used when compiling the executable or when compiling the static library. You are trying to think about it about a normal feature with intended use cases. It is not. For now I'd recommend to always use it in release builds but remove it time to time and report all linker failures without it to bugzilla - maybe we will manage to implement it properly until 2.065 tl; dr: it is rollback switch for broken feature that was not reverted Ok. I have linker issue with the released 2.064.2 version. Everything worked just fine with git head from about 1 week ago. But I don't have the time right now to dustmite it. I'm also getting tired of it, I submitted so many bugs for 2.064 ... Kind Regards Benjamin Thaut
Re: who to use -allinst
Sorry about that, I have already spent all my rage on this decision but with no result. Releasing incomplete features as in good old times.
Re: How to iterate through all modules for use with the new getUnitTests trait?
On Wednesday, 6 November 2013 at 21:07:47 UTC, Gary Willoughby wrote: Unfortunately this still suffers the same problem in that you need a module symbol name to do anything. I need to get all module symbols at compile time. You need only symbol name of your root compiled module which imports all others. All imported ones will be available in its member list, exactly what this snippet shows.
Re: How to iterate through all modules for use with the new getUnitTests trait?
On Wednesday, 6 November 2013 at 21:26:09 UTC, Dicebot wrote: On Wednesday, 6 November 2013 at 21:07:47 UTC, Gary Willoughby wrote: Unfortunately this still suffers the same problem in that you need a module symbol name to do anything. I need to get all module symbols at compile time. You need only symbol name of your root compiled module which imports all others. All imported ones will be available in its member list, exactly what this snippet shows. I think what OP wants to do is not as straightforward. I believe the goal is to have a module somewhere out there that looks at all other modules in the executable. I don't think it works that way, as how could a compile time test module know about modules that have pulled it in? Have a look at (https://github.com/patefacio/d-help/blob/master/d-help/opmix/ut.d) where I used dicebot's previous example code to find all unittests of the *current module*. The trick is to mixin code that examines the current __MODULE__ for your tests. This may not be the best way but it is working well for me. The thread was `selectively running unittest functions` http://forum.dlang.org/post/xjcgtbyrqzbosajxb...@forum.dlang.org
Re: How to iterate through all modules for use with the new getUnitTests trait?
On Wednesday, 6 November 2013 at 21:36:52 UTC, Daniel Davidson wrote: I don't think it works that way, as how could a compile time test module know about modules that have pulled it in? Exactly. __traits work during compile-time. If module is not imported, it is not known during compile-time - no trait unittest access possible. In lot of programs it will be accessible recursively via some indirect import though.
Re: Limiting template functions to template instantiations of a struct
Wow. It didn't even occur to me that `is` could be used like that. I think that operator is the hardest part of the language for me to grok. Thanks guys!
Re: Limiting template functions to template instantiations of a struct
On Wednesday, 6 November 2013 at 21:49:52 UTC, Atila Neves wrote: Wow. It didn't even occur to me that `is` could be used like that. I think that operator is the hardest part of the language for me to grok. Thanks guys! http://dlang.org/expression.html#IsExpression ;)
Re: UFCS with constructors
Dicebot: Typedef implementation sucks? ;) So do you suggest to open some enhancement request/bug report on Typedef? Bye, bearophile
Re: How to iterate through all modules for use with the new getUnitTests trait?
foreach (module_; ModuleInfo)
{
auto func = module_.unitTest;
func(); // run tests;
}
The above code retrieves all of the current project's modules and
then grabs each module's unit test blocks. The only trouble is
that the module's unit tests are kinda rolled into one function
as show by the 'func' variable above. It would be nice to do this
but get each individual unit test instead of dealing with these
rolled up versions.
Re: How to iterate through all modules for use with the new getUnitTests trait?
On Wednesday, 6 November 2013 at 22:33:48 UTC, Gary Willoughby wrote: The above code retrieves all of the current project's modules and then grabs each module's unit test blocks. The only trouble is that the module's unit tests are kinda rolled into one function as show by the 'func' variable above. It would be nice to do this but get each individual unit test instead of dealing with these rolled up versions. It is done via runtime reflection and completely different from __traits approach. You will also 100% loose all User Defined Attributes attached to test blocks because of their compile-time nature. This is IMHO why it was somewhat abandoned as less promising approach.
Re: Limiting template functions to template instantiations of a struct
On Wednesday, 6 November 2013 at 21:52:04 UTC, Dicebot wrote: On Wednesday, 6 November 2013 at 21:49:52 UTC, Atila Neves wrote: Wow. It didn't even occur to me that `is` could be used like that. I think that operator is the hardest part of the language for me to grok. Thanks guys! http://dlang.org/expression.html#IsExpression ;) I know, but I keep having to refer back to that and even then I didn't know about the syntax these guys just posted! ;)
Re: Limiting template functions to template instantiations of a struct
On Wednesday, 6 November 2013 at 22:41:08 UTC, Atila Neves wrote: I know, but I keep having to refer back to that and even then I didn't know about the syntax these guys just posted! ;) Well, it is mentioned in the list of `is` usage cases down that link. It is very ugly part of the language but definitely worth spending some time to carefully investigate all the patterns - damn powerful stuff.
Re: Limiting template functions to template instantiations of a struct
On Wednesday, 6 November 2013 at 22:43:18 UTC, Dicebot wrote: On Wednesday, 6 November 2013 at 22:41:08 UTC, Atila Neves wrote: I know, but I keep having to refer back to that and even then I didn't know about the syntax these guys just posted! ;) Well, it is mentioned in the list of `is` usage cases down that link. It is very ugly part of the language but definitely worth spending some time to carefully investigate all the patterns - damn powerful stuff. There are so much more uglier things ... :P Take a look at the scoped or ref counted implementation.
Re: Limiting template functions to template instantiations of a struct
On Wed, Nov 06, 2013 at 11:52:56PM +0100, Namespace wrote:
On Wednesday, 6 November 2013 at 22:43:18 UTC, Dicebot wrote:
On Wednesday, 6 November 2013 at 22:41:08 UTC, Atila Neves wrote:
I know, but I keep having to refer back to that and even then I
didn't know about the syntax these guys just posted! ;)
Well, it is mentioned in the list of `is` usage cases down that
link. It is very ugly part of the language but definitely worth
spending some time to carefully investigate all the patterns -
damn powerful stuff.
There are so much more uglier things ... :P
Take a look at the scoped or ref counted implementation.
Are you sure about that? Do you know that this does?
int func(ref int x, string y, float z = 3.14159) { ... }
// This is possibly the single nastiest bit of syntax in all of D:
static if (is(func X == __parameters)) {
// Quick, without looking at the docs: what does X refer
// to?
// If you manage to figure that one out, can you say
// with certainty what's the type of X? Are you sure? :P
alias Y = X[0];
// Quick, without looking at the docs: what is Y?
// (If your answer was, the first element of X, you're
// wrong!)
// Quiz: how do you get a single element of X? (And no,
// X[i] is the wrong answer, see above.)
// If you got it right thus far: how do you access the
// name of a single element of X? The default value?
// (Note: if you didn't get the previous questions
// right, don't even attempt this one; it's one of those
// things that nobody can possibly guess unless they've
// seen it before.)
}
Almost every part of the above is so completely counterintuitive and
impossible to predict from the syntax that I honestly doubt if the
scoped or RefCounted implementation could beat it for ugliness. :P
T
--
Notwithstanding the eloquent discontent that you have just respectfully
expressed at length against my verbal capabilities, I am afraid that I must
unfortunately bring it to your attention that I am, in fact, NOT verbose.
Re: UFCS with constructors
On Wednesday, 6 November 2013 at 21:57:47 UTC, bearophile wrote: Dicebot: Typedef implementation sucks? ;) So do you suggest to open some enhancement request/bug report on Typedef? Bye, bearophile Sure. get enough such reports and we may even get it back as language feature :) (I think getting Typedef to act properly in all cases is damn hard task to do)
struct Unique(T)
Hi, I've been following the D language off and on for several
years, have read Andrei's D book, but haven't ever posted here
before. Mostly, I come from a C++ and C# background. Recently, I
was playing with D using the derelict bindings for the SDL
library.
The SDL library uses handles in the form of struct pointers for
resource management. In C++ I like using unique and shared
pointers to manage C handles. Additionally, I like being able to
specify custom clean up functions for specific resources. For
example:
typedef std::unique_ptrHandleType, HandleDeleter handle_ptr;
My question is: what's the status of D's struct Unique? It looks
like struct RefCounted is current, but I can't tell with Unique.
There's several comments in the source that say: doesn't work
yet. It seems like some of it could be made to work as intended.
For example, the commented out code to disallow construction via
an lvalue:
// this(U)(ref Unique!(U) u) = null; // commented out
// this(this) = null;
Couldn't this be written:
@disable this(U)(ref Unique!(U) u);
@disable this(this);
Seems to work when I try it. It stopped the copy from working,
but I can still do a move. Like this:
Unique!(int) i1 = new int;
Unique!(int) i2 = move(i1); // works!
Next, I'd like to be able to use a custom deleter. For example, a
naive implementation I could write would be something like:
struct Unique2(T, string D = delete)
{
...
~this()
{
debug(Unique2) writeln(Unique destructor of , (_p is
null)? null: _p);
if (_p !is null)
{
mixin(~D~ (_p);); // delete _p;
_p = null;
}
}
...
So, I could do things like:
Unique2!(int, free) i1 = cast(int*)malloc(int.sizeof); // lame
example
A real implementation would allow more interesting deleters in
the form of delegates, but I'm already stretching my D skillz.
Anyway, am I missing something here? Is there a better D language
feature I'm not thinking about that provides the same
functionality as C++'s std::unique_ptr with custom deleters;
besides putting scope (exit) everywhere?
-Chris
Re: Small troubles with private
On Tuesday, 5 November 2013 at 21:01:40 UTC, John J wrote: On 11/05/2013 11:00 AM, bearophile wrote: How to solve such little troubles? A possible idea is to add to D another attribute, a kind of private private that is enforced inside the same module. It could be named super private because D has the super keyword :-) But this idea doesn't solve all the problems, because sometimes you don't want to use a super private attribute. How about strict private I think static private is the best option (just kidding).
Re: struct Unique(T)
On Thursday, 7 November 2013 at 00:07:25 UTC, ChrisG wrote: My question is: what's the status of D's struct Unique? It looks like struct RefCounted is current, but I can't tell with Unique. There's several comments in the source that say: doesn't work yet. It seems like some of it could be made to work as intended. For example, the commented out code to disallow construction via an lvalue: I'm pretty sure things like Unique have been neglected for awhile. Probably for a decent reason, but a lot of language features have been landing that could help polish it up a bit more. Next, I'd like to be able to use a custom deleter. For example, a naive implementation I could write would be something like: ... snip ... So, I could do things like: Unique2!(int, free) i1 = cast(int*)malloc(int.sizeof); // lame example A real implementation would allow more interesting deleters in the form of delegates, but I'm already stretching my D skillz. I think Unique will probably be getting something along those lines reasonably shortly, but std.allocator will have to be fully completed first. http://forum.dlang.org/thread/l4btsk$5u8$1...@digitalmars.com Once that's done we'll see some memory management schemes like what you're suggesting be implemented. But it's probably not a good idea to add that stuff before we figure out a good way to use it with the new std.allocator effectively.
Re: Small troubles with private
On Wednesday, 6 November 2013 at 12:19:26 UTC, Timon Gehr wrote: How about just adding full granularity? By condition: @visibleIf!true // public @visibleIf!(isSubtypeOf!(typeof(this))) // protected By explicit enumeration: @visible!(getModule!(typeof(this))) // private @visible!(typeof(this), T) // visible to type 'T' @visible!(typeof(this)) // 'super private' @visible!foo // only (member) function 'foo' can access it @visible!() // nobody can access it Dear Santa, ...
Reflecting on a module
How does one reflect on all the classes in a module? I would like to read their attributes and generate an enum from attributes on said classes.
Re: Reflecting on a module
On Thursday, 7 November 2013 at 01:37:24 UTC, Shammah Chancellor wrote: How does one reflect on all the classes in a module? __traits(allMembers, your_module) There's two easy ways to get your_module: __traits(parent, some_top_level_symbol0 or mixin(module.name.here); allMembers gives a list of strings, which are the names of everything. Then you do __traits(getMember, your_module, name) in the loop to get it and see if it is a class. If you need more details, I can write a sample function too. I used this technique in my terminal emulator utility module: https://github.com/adamdruppe/terminal-emulator/blob/master/utility.d check the main function there. Here, I look for functions marked export, but looking for classes and UDAs isn't much different. static if(is(T == class)), __traits(getAttributes), etc instead of getProtection.
BinaryHeap
I'm trying to use BinaryHeap and i found out that i cannot use foreach(). My question is, there is any other way to do it?, can i iterate a BinaryHeap?
Re: Module or Dictionary corrupt
On Wednesday, 6 November 2013 at 10:32:01 UTC, Namespace wrote: On Wednesday, 6 November 2013 at 10:21:38 UTC, evilrat wrote: On Wednesday, 6 November 2013 at 10:13:07 UTC, Namespace wrote: Should I open a bug for this? you should fix ur sc.ini first to use visual studio linker for x64 and optlink for x86, you can use dmd 2.064.2 installer now to do so automatically. I only have a VS shell for VisualD. I assume that I need a regular version, e.g. C++ Express? well, yes, and also windows sdk i think
