Map Purity
My understanding of pure is that a function labeled pure can only
include pure functions. I've been confused by the fact that a
function calling map (like below) can be labeled pure without any
problems. The only way I can rationalize it is that map really
isn't a function, it's (if I'm understanding it correctly) a
template that creates a template function that calls a struct
template.
auto test_map(T)(T x) pure
{
return x.map!(a = a + a);
}
This is related to
http://forum.dlang.org/thread/ppmokalxdgtszzllz...@forum.dlang.org?page=1
but maybe my question is more basic.
Re: Typed Message Passing between D Processes
On Friday, 26 June 2015 at 21:40:49 UTC, Atila Neves wrote: I'd have to benchmark it against something, but I'm pretty sure cerealed is fast. Faster than msgpack?
Re: Map Purity
On Sunday, 28 June 2015 at 16:28:20 UTC, jmh530 wrote: Thanks for the reply. Two follow ups: 1) Does labeling a template as pure matter if the compiler infers it anyway? 2) Does the compiler also infer anything for @safe/nothrow in templates? 1) It means you can't instantiate the template function with arguments that would make it non-pure. 2) Yes, pure, nothrow, @safe, @nogc are all inferred.
Re: Map Purity
On Sunday, 28 June 2015 at 16:15:31 UTC, Marc Schütz wrote: Secondly, `map` is indeed a template function, as you write. For templates functions, the compiler infers many properties, including purity. Thanks for the reply. Two follow ups: 1) Does labeling a template as pure matter if the compiler infers it anyway? 2) Does the compiler also infer anything for @safe/nothrow in templates?
Re: Map Purity
On Sunday, 28 June 2015 at 15:55:51 UTC, jmh530 wrote:
My understanding of pure is that a function labeled pure can
only include pure functions. I've been confused by the fact
that a function calling map (like below) can be labeled pure
without any problems. The only way I can rationalize it is that
map really isn't a function, it's (if I'm understanding it
correctly) a template that creates a template function that
calls a struct template.
auto test_map(T)(T x) pure
{
return x.map!(a = a + a);
}
This is related to
http://forum.dlang.org/thread/ppmokalxdgtszzllz...@forum.dlang.org?page=1
but maybe my question is more basic.
Map isn't explicitly marked as pure. D can infer purity for
templated functions, so as long as you give it a pure predicate,
map can be inferred as pure. This only works for templated
functions; non-templated functions must be explicitly marked as
pure.
Re: Map Purity
On Sunday, 28 June 2015 at 15:55:51 UTC, jmh530 wrote:
My understanding of pure is that a function labeled pure can
only include pure functions. I've been confused by the fact
that a function calling map (like below) can be labeled pure
without any problems. The only way I can rationalize it is that
map really isn't a function, it's (if I'm understanding it
correctly) a template that creates a template function that
calls a struct template.
auto test_map(T)(T x) pure
{
return x.map!(a = a + a);
}
This is related to
http://forum.dlang.org/thread/ppmokalxdgtszzllz...@forum.dlang.org?page=1
but maybe my question is more basic.
There are two aspects to that. First, purity in D is less strict
than the concept in functional programming languages. It allows
access (even mutation) to anything that is reachable through the
parameters. David Nadlinger has written a nice article about the
concept and its implications:
http://klickverbot.at/blog/2012/05/purity-in-d/
Secondly, `map` is indeed a template function, as you write. For
templates functions, the compiler infers many properties,
including purity. Neither the `map` function nor the constructor
of the struct it returns do anything impure, therefore they are
treated as pure. And indeed, the return value of `test_map` will
only depend on its arguments, which is the first requirement for
purity, and of course it doesn't change global state either,
which fulfills the second requirement.
Re: tkd - basic compilation problem
On Tuesday, 30 June 2015 at 13:22:43 UTC, Paul wrote: On Tuesday, 30 June 2015 at 13:19:25 UTC, Marc Schütz wrote: If you don't want to use DUB, you need to download the other two packages from code.dlang.org and specifiy -I/path/to/tcltk -I/path/to/x11 -I/path/to/tkd in the DMD invocation. Thank you, I'll try that. Added info: I wanted to avoid using dub so I could manually figure out what would be required to distribute the application.
Re: Static constructors guaranteed to run?
On Monday, 29 June 2015 at 11:36:42 UTC, ketmar wrote: it doesn't, afair, but it's quite natural. if user type was throwed out as unused, it would be very strange to insist on keeping it's initialization code. Personally I would be kinda pissed if the compiler did this, I expect the static ctor to run, even if I don't use the type.
Re: tkd - basic compilation problem
On Tuesday, 30 June 2015 at 13:19:25 UTC, Marc Schütz wrote: If you don't want to use DUB, you need to download the other two packages from code.dlang.org and specifiy -I/path/to/tcltk -I/path/to/x11 -I/path/to/tkd in the DMD invocation. Thank you, I'll try that.
Re: tkd - basic compilation problem
If you don't want to use DUB, you need to download the other two packages from code.dlang.org and specifiy -I/path/to/tcltk -I/path/to/x11 -I/path/to/tkd in the DMD invocation.
tkd - basic compilation problem
I downloaded the archive from https://github.com/nomad-software/tkd and files are same as in the git repo. Tcl/tk is installed on this machine (test 'hello world' script works fine) but I get this error when compiling the example from the github page: tkd/interpreter/tcl.d(16): Error: module tcl is in file 'tcltk/tcl.d' which cannot be read import path[0] = /usr/include/dmd/phobos import path[1] = /usr/include/dmd/druntime/import As far as I can see there is no tcltk directory - can someone tell me where I'm going wrong or if something is missing? TIA Paul
Re: tkd - basic compilation problem
On Tuesday, 30 June 2015 at 15:25:27 UTC, Alex Parrill wrote: On Tuesday, 30 June 2015 at 14:28:49 UTC, Paul wrote: Using dub I get this during linking: Building tkd-test ~master configuration application, build type debug. Compiling using dmd... Linking... /usr/bin/ld: cannot find -ltcl /usr/bin/ld: cannot find -ltk ...any suggestions please? You need to install the libraries. Ex `sudo apt-get install libtcl8.5 libtk8.5` Or the corresponding -dev packages.
Re: Nullable with reference types
On Tuesday, 30 June 2015 at 15:17:00 UTC, Jonathan M Davis wrote: I tend to think that it's incredibly stupid to use something like Nullable for a type that's already Nullable. Unfortunately, we're stuck with it as changing that would break code. It's just silly. If a type is already nullable, then just use that and stop being adding extra overhead for no good reason. I agree. There are several minuscule advantages you get from wrapping a nullable type with Nullable, but they're almost negligible.
Re: Bug or feature?
On Monday, 29 June 2015 at 14:28:06 UTC, anonymous wrote: On Monday, 29 June 2015 at 12:04:46 UTC, Jonathan M Davis wrote: You haven't declared an immutable constructor, so you can't construct an immutable Foo. That's not what's happening. Constructing an immutable Foo works just fine. Then I stand corrected. - Jonathan M Davis
Re: Template mixin can not introduce overloads
On Thursday, 25 June 2015 at 03:49:04 UTC, Tofu Ninja wrote:
Is this intended or is it a bug?
On Thursday, 25 June 2015 at 03:53:58 UTC, Adam D. Ruppe wrote:
Intended, the mixin template works on the basis of names. This
The extra step is easy though: alias the name in:
I would like to to this with constructors instead of normal
methods. I have tried to mix in a constructor as follows:
#!/usr/bin/rdmd
import std.stdio;
mixin template MyConstructor() {
this(int x, float y) { writefln(%d, %f, x, y); }
}
class Base {
mixin MyConstructor my_ctor;
this(string s) { writefln(s); }
alias my_ctor this;
}
void main()
{
Base b = new Base(3, 4.5);
}
$ ./mixinctor.d
./mixinctor.d(17): Error: constructor mixinctor.Base.this (string
s) is not callable using argument types (int, double)
Failed: [dmd, -v, -o-, ./mixinctor.d, -I.]
Doing it with
alias this = my_ctor;
errors out too, and demands me to use alias my_ctor this; as in
the original code.
Can I get this to work at all? Or does alias this (for multiple
subtyping) fundamentally clash here with alias my_ctor this?
-- Simon
Re: Static constructors guaranteed to run?
On 6/26/15 6:00 PM, Tofu Ninja wrote: Also are static constructors in templated types guaranteed to run for every instantiation? I'd hazard to guess that the current compiler does run them, but that they probably aren't guaranteed to run by a sufficiently smart future compiler. Note, I strongly would discourage having static ctors inside templates: https://issues.dlang.org/show_bug.cgi?id=14517 -Steve
Re: tkd - basic compilation problem
On Tuesday, 30 June 2015 at 14:28:49 UTC, Paul wrote: Using dub I get this during linking: Building tkd-test ~master configuration application, build type debug. Compiling using dmd... Linking... /usr/bin/ld: cannot find -ltcl /usr/bin/ld: cannot find -ltk ...any suggestions please? You need to install the libraries. Ex `sudo apt-get install libtcl8.5 libtk8.5`
Re: is it safe to call `GC.removeRange` in dtor?
On 6/27/15 5:53 PM, ketmar wrote: is it safe to call `GC.removeRange` in dtor? i believe it should be safe, so one can perform various cleanups, but documentation says nothing about guarantees. Hm... I can't see any reason why it wouldn't be allowed. removeRange shouldn't allocate, so the one forbidden thing is not used. And removing a range, by definition, means it's not being collected. So you can be assured that the data still exists. I'm not 100% sure, though. -Steve
Re: goroutines vs vibe.d tasks
On Tuesday, 30 June 2015 at 15:18:36 UTC, Jack Applegame wrote: Just creating a bunch (10k) of sleeping (for 100 msecs) goroutines/tasks. Compilers go: go version go1.4.2 linux/amd64 vibe.d: DMD64 D Compiler v2.067.1 linux/amd64, vibe.d 0.7.23 Code go: http://pastebin.com/2zBnGBpt vibe.d: http://pastebin.com/JkpwSe47 go version build with go build test.go vibe.d version built with dub build --build=release test.d Results on my machine: go: 168.736462ms (overhead ~ 68ms) vibe.d: 1944ms (overhead ~ 1844ms) Why creating of vibe.d tasks is so slow (more then 10 times)??? I think this might be a problem with vibe.d's `sleep`. Putting a `writeln(...);` there is a lot faster than `sleep`ing even the tiniest amount of time.
Re: Replacement of std.stream
On Sunday, 28 June 2015 at 05:04:48 UTC, DlangLearner wrote: I will convert a Java program into D. The original Java code is based on the class RandomeAccessFile which essentially defines a set of methods for read/write Int/Long/Float/String etc. The module std.stream seems to be a good fit for this job, but in its documentation, it is marked deprecated. So I'd like to know what is the replacement for this module. If I don't use this module, what is the other apporach I should use. Thanks for help. It should be noted that you can always take the code from std.stream and use it as a classical non-standard library.
Re: goroutines vs vibe.d tasks
On Tuesday, 30 June 2015 at 16:43:58 UTC, anonymous wrote: On Tuesday, 30 June 2015 at 15:18:36 UTC, Jack Applegame wrote: Just creating a bunch (10k) of sleeping (for 100 msecs) goroutines/tasks. Compilers go: go version go1.4.2 linux/amd64 vibe.d: DMD64 D Compiler v2.067.1 linux/amd64, vibe.d 0.7.23 Code go: http://pastebin.com/2zBnGBpt vibe.d: http://pastebin.com/JkpwSe47 go version build with go build test.go vibe.d version built with dub build --build=release test.d Results on my machine: go: 168.736462ms (overhead ~ 68ms) vibe.d: 1944ms (overhead ~ 1844ms) Why creating of vibe.d tasks is so slow (more then 10 times)??? I think this might be a problem with vibe.d's `sleep`. Putting a `writeln(...);` there is a lot faster than `sleep`ing even the tiniest amount of time. Sleep will almost certainly pause and block the fiber. Vibe.d only switches between them when there's IO to be done or something else from the event loop. A better way of comparing would be to actually do something: use channels to ping-pong back between the goroutines and use vibe.d's concurrency to send messages betweeen fibers. Whatever you do, don't sleep. Atila
Re: goroutines vs vibe.d tasks
Don't have go installed, but for me, the timings don't change very much depending on compiler and optimization flags: dub --compiler=dmd 13346ms dub --compiler=dmd --build=release 12348ms dub --compiler=ldc212082ms dub --compiler=ldc2 --build=release 9351ms
proper way to calculate toHash() for string
I would like to know proper way to calculate
hash for given member fields.
class Foo {
int value;
string str;
override nothrow @safe size_t toHash() {
// calculate hash based on field value.
// value and str in this example.
}
}
boost::hash provides easy and systematic way
to calculate hash.
I found std.digest.crc is useful.
override nothrow @safe size_t toHash() {
if (str is null) return value;
ubyte[4] hash = crc32Of(str);
return value^((hash[0]24)|(hash[1]16)|(hash[2]8)|hash[3]);
}
Please suggest me if anyone have an idea.
Regards, aki.
Re: Nullable with reference types
On Tuesday, 30 June 2015 at 00:02:38 UTC, Meta wrote:
On Monday, 29 June 2015 at 19:29:37 UTC, sigod wrote:
Hi, everyone.
```
import std.typecons : Nullable;
class Test {}
Nullable!Test test;
assert(test.isNull);
```
Why does `Nullable` allowed to be used with reference types
(e.g. classes)?
P.S. I have experience with C#, where `NullableT` cannot be
used with reference types. And it sounds logical to me.
It's a design mistake in Nullable. I would suggest that either
never use Nullable with a type that already has a null value,
or use the overload of Nullable that takes a null value, and
set it to null. Example:
Class Test {}
alias NullableTest = Nullable!(Test, null);
I tend to think that it's incredibly stupid to use something like
Nullable for a type that's already Nullable. It's just silly. If
a type is already nullable, then just use that and stop being
adding extra overhead for no good reason. However, it _is_ true
that if you need to have a nullable variable in generic code
where the type that you need to be nullable could be any type,
then having Nullable work with all types - and work with them all
in the same way - is useful. Without that, you'd have to special
case your code for types which were naturally nullable (and thus
used null) and those which required Nullable. So, I can see why
it could be useful to have Nullable work with classes, but I also
question how common such a use case is.
- Jonathan M Davis
Re: Best way to count character spaces.
On Tue, Jun 30, 2015 at 06:33:32PM +, Taylor Hillegeist via Digitalmars-d-learn wrote: So I am aware that Unicode is not simple... I have been working on a boxes like project http://boxes.thomasjensen.com/ it basically puts a pretty border around stdin characters. like so: /\ \ \_|Different all twisty a| |of in maze are you, | |passages little. | | ___|_ \_/_/ but I find that I need to know a bit more than the length of the string because of encoding differences [...] Use std.uni.byGrapheme. That's the only reliable way to count anything remotely resembling the display length of the string, which is not to be confused with the number of code points, which is also different from the length of the string in bytes or the number of code units. Note that even with byGrapheme, you may still need some post-processing, because certain terminals may output Asian block characters in double width, meaning that 1 grapheme takes up two columns on the screen. But byGrapheme should get you started on the right footing. T -- If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher
Adam Ruppe's COM library - calling COM object from dynamic code eg VBA
Hi. With a few changes, I have got the source working for the client and server code for hello. The COM object isn't recognised by dynamic languages such as Python and VBA, even after registering. I think I need to add type library fields in the registry. Any tips or sample code from someone who has done this ? I have two COM books here, but will have to find the time to read them... Thanks. Laeeth.
Re: Replacement of std.stream
On Sunday, June 28, 2015 11:14:57 Baz via Digitalmars-d-learn wrote: On Sunday, 28 June 2015 at 05:04:48 UTC, DlangLearner wrote: I will convert a Java program into D. The original Java code is based on the class RandomeAccessFile which essentially defines a set of methods for read/write Int/Long/Float/String etc. The module std.stream seems to be a good fit for this job, but in its documentation, it is marked deprecated. So I'd like to know what is the replacement for this module. If I don't use this module, what is the other apporach I should use. Thanks for help. You can use std.stream. There is no candidate to replace it. Even if tomorrow someone comes with one, it has to be reviewed, accepted in std.experimental and after a while it would totally replace the old one. I think it's safe to say that std.stream will exist for at least 2 years in its current shape. No. It was decided at dconf that it was going to be deprecated and then removed within a relatively short period of time. In fact, it would have been deprecated with the next release, but there was a problem with the deprecation and the ddoc build, so the deprecation was temporarily reverted. But once that's sorted out, it's going to be deprecated, and it won't be around much longer at all. We decided that it was worse to leave it in saying that it was going to be replaced without having come up with anything for years than to leave it in. And given that std.stream rarely even comes up in discussions and that no one has proposed a replacement, Andrei thinks that it's a sign that there really isn't much demand for it anyway. For the most part, simply using std.stdio.File or std.mmfile.MmFile with ranges does what streams need to do just fine. Maybe someone will come up with a replacement for std.stream eventually, but there really doesn't seem to be much call for it. Regardless, until someone comes up with a replacement, we're simply not going have a stream-based I/O (though ranges are close - which is part of why no one has felt the need to replace std.stream strongly enough to actually do it). - Jonathan M Davis
Setting um makefile for dmd
Hello, i get myself a nice makefile from here: https://gist.github.com/darkstalker/2221824 How can I modify it so that I can use the run option of dmd? I tried to add another compiler flag variable which would be only used with run but then it messed with -of$@ option and said it couldn't read it. Thanks
Re: Static constructors guaranteed to run?
On Monday, 29 June 2015 at 02:07:57 UTC, ketmar wrote: On Sat, 27 Jun 2015 22:49:13 +, Tofu Ninja wrote: On Saturday, 27 June 2015 at 22:20:40 UTC, ketmar wrote: 2. no. Hmm... any reason why? if instantiated template was not used in any code that makes into compiled binary, compiler is free to remove it with all it's ctors. it may do that, or may not, but removal is allowed. so while that can work now (i didn't checked), it may stop working in next version (or with another compiler), and that will not be a bug. Does the specification really say that? This isn't obvious to me at all. I would expect static ctors to be treated as if they were referenced by the initialization logic (though I understand it's not an explicit reference, they just end up in a special section that the runtime can inspect).
Re: Bug or feature?
On Sunday, June 28, 2015 11:37:59 Jack Applegame via Digitalmars-d-learn wrote:
I don't see any reason why it should not compile.
import std.array;
import std.range;
import std.algorithm;
class Foo {
}
void main() {
auto result = iota(3).map!(i = new immutable Foo).array();
}
/usr/include/dmd/phobos/std/conv.d(4028): Error: cannot
implicitly convert expression (arg) of type immutable(Foo) to
test.Foo
/usr/include/dmd/phobos/std/conv.d(3931): Error: template
instance
std.conv.emplaceImpl!(immutable(Foo)).emplaceImpl!(immutable(Foo)) error
instantiating
/usr/include/dmd/phobos/std/array.d(115):instantiated
from here: emplaceRef!(immutable(Foo), Foo, immutable(Foo))
test.d(9):instantiated from here:
array!(MapResult!(__lambda1, Result))
You haven't declared an immutable constructor, so you can't construct an
immutable Foo. If the default constructor were pure, then it could be used
to construct immutable objects even if it weren't immutable, but the default
constructor is neither pure nor immutable, and purity isn't inferred for
normal functions.
It might make sense as a feature request to request that a class' default
constructor be pure (assuming that its base class constructor is pure),
since theoretically, it should be able to be pure, but that would be a
change in the language. What you're seeing is not a bug. It's how the
current design works.
- Jonathan M Davis
Re: Typed Message Passing between D Processes
On Monday, 29 June 2015 at 08:45:15 UTC, Atila Neves wrote: On Sunday, 28 June 2015 at 17:02:42 UTC, Nordlöw wrote: On Friday, 26 June 2015 at 21:40:49 UTC, Atila Neves wrote: I'd have to benchmark it against something, but I'm pretty sure cerealed is fast. Faster than msgpack? I guess I'm going to have benchmark this now... :) Atila In release builds, _nearly_. Here's the benchmark program: http://dpaste.dzfl.pl/17b0ed9c0204. Results below. msgpack is... fast. From the docs, cerealed seems to have more features that I actually use and need though. Results: DMD debug: Cerealed: 4 secs, 987 ms, 700 μs, and 5 hnsecs MsgPack: 1 sec, 771 ms, 713 μs, and 7 hnsecs DMD release: Cerealed: 2 secs, 556 ms, 714 μs, and 6 hnsecs MsgPack: 1 sec, 89 ms, 561 μs, and 3 hnsecs GDC debug: Cerealed: 4 secs, 863 ms, 501 μs, and 1 hnsec MsgPack: 2 secs, 32 ms, 53 μs, and 1 hnsec GDC release: Cerealed: 1 sec, 740 ms, 726 μs, and 4 hnsecs MsgPack: 1 sec, 20 ms, 287 μs, and 3 hnsecs LDC debug: Cerealed: 7 secs, 711 ms, 154 μs, and 4 hnsecs MsgPack: 3 secs, 694 ms, 566 μs, and 2 hnsecs LDC release: Cerealed: 1 sec, 795 ms, 380 μs, and 7 hnsecs MsgPack: 931 ms, 355 μs, and 5 hnsecs
Re: Static constructors guaranteed to run?
On Mon, 29 Jun 2015 10:19:33 +, Marc Schütz wrote: On Monday, 29 June 2015 at 02:07:57 UTC, ketmar wrote: On Sat, 27 Jun 2015 22:49:13 +, Tofu Ninja wrote: On Saturday, 27 June 2015 at 22:20:40 UTC, ketmar wrote: 2. no. Hmm... any reason why? if instantiated template was not used in any code that makes into compiled binary, compiler is free to remove it with all it's ctors. it may do that, or may not, but removal is allowed. so while that can work now (i didn't checked), it may stop working in next version (or with another compiler), and that will not be a bug. Does the specification really say that? This isn't obvious to me at all. I would expect static ctors to be treated as if they were referenced by the initialization logic (though I understand it's not an explicit reference, they just end up in a special section that the runtime can inspect). it doesn't, afair, but it's quite natural. if user type was throwed out as unused, it would be very strange to insist on keeping it's initialization code. signature.asc Description: PGP signature
Re: Typed Message Passing between D Processes
On Sunday, 28 June 2015 at 17:02:42 UTC, Nordlöw wrote: On Friday, 26 June 2015 at 21:40:49 UTC, Atila Neves wrote: I'd have to benchmark it against something, but I'm pretty sure cerealed is fast. Faster than msgpack? I guess I'm going to have benchmark this now... :) Atila
Re: Porting from D1 to D2
On Sunday, 28 June 2015 at 21:26:52 UTC, Walter Bright wrote: On 6/28/2015 2:48 AM, ponce wrote: I don't quite get what code could be generating that reference, since I don't call format or toString on a Throwable. You can grep the .obj files for the symbol. Thanks. Fixed by upgrading. I think I had messed up sc.ini.
Re: Bug or feature?
On Monday, 29 June 2015 at 12:04:46 UTC, Jonathan M Davis wrote: You haven't declared an immutable constructor, so you can't construct an immutable Foo. That's not what's happening. Constructing an immutable Foo works just fine.
Re: goroutines vs vibe.d tasks
On Tuesday, 30 June 2015 at 15:18:36 UTC, Jack Applegame wrote: Just creating a bunch (10k) of sleeping (for 100 msecs) goroutines/tasks. Compilers go: go version go1.4.2 linux/amd64 vibe.d: DMD64 D Compiler v2.067.1 linux/amd64, vibe.d 0.7.23 Code go: http://pastebin.com/2zBnGBpt vibe.d: http://pastebin.com/JkpwSe47 go version build with go build test.go vibe.d version built with dub build --build=release test.d Results on my machine: go: 168.736462ms (overhead ~ 68ms) vibe.d: 1944ms (overhead ~ 1844ms) Why creating of vibe.d tasks is so slow (more then 10 times)??? Use GDC or LDC for profiling code; the DMD optimizer isn't as good. Also, its likely that go has spent a lot more effort optimizing coroutines specifically than D has.
Re: proper way to calculate toHash() for string
On Tuesday, 30 June 2015 at 14:19:39 UTC, aki wrote:
I would like to know proper way to calculate
hash for given member fields.
class Foo {
int value;
string str;
override nothrow @safe size_t toHash() {
// calculate hash based on field value.
// value and str in this example.
}
}
boost::hash provides easy and systematic way
to calculate hash.
I found std.digest.crc is useful.
override nothrow @safe size_t toHash() {
if (str is null) return value;
ubyte[4] hash = crc32Of(str);
return
value^((hash[0]24)|(hash[1]16)|(hash[2]8)|hash[3]);
}
Please suggest me if anyone have an idea.
Regards, aki.
Well, technically, it really doesn't matter so long as it's
consistent with opEquals (though having a hashing algorithm which
has a low collision rate can definitely help performance; you
still don't want it to be expensive though if you can help it).
Effective Java had one that made sense which I'd probably use as
a starting point if was going to write one, but I'd have to dig
out the book to see what it was. It might make sense to add
something to Phobos which took a list of member variables and
generated an appropriate hash function for you, but we don't have
anything like that right now. But if you really want to find a
good hashing function, you'll probably need to go searching
online. There's nothing special about D with regards to how
hashing functions need to work, so it's probably pretty easy to
find some good algorithms online. But someone here may already
have a link that they can point you to.
- Jonathan M Davis
Re: Bug or feature?
https://issues.dlang.org/show_bug.cgi?id=14751
Re: tkd - basic compilation problem
On Tuesday, 30 June 2015 at 12:58:21 UTC, Paul wrote:
I downloaded the archive from
https://github.com/nomad-software/tkd and files are same as in
the git repo. Tcl/tk is installed on this machine (test 'hello
world' script works fine) but I get this error when compiling
the example from the github page:
tkd/interpreter/tcl.d(16): Error: module tcl is in file
'tcltk/tcl.d' which cannot be read
import path[0] = /usr/include/dmd/phobos
import path[1] = /usr/include/dmd/druntime/import
As far as I can see there is no tcltk directory - can someone
tell me where I'm going wrong or if something is missing?
TIA
Paul
AFAICS tkd requires too additional libraries (bindings): tcltk
and x11. Its easiest to
use DUB for building, it will download all required dependencies
and pass the correct import paths to the compiler. The following
works for me:
dub.json:
{
name: tkd-test-app,
dependencies: {
tkd: ~1.1.4
}
}
source/app.d:
(the example program)
Running dub successfully builds and executes the example
program.
Re: Nullable with reference types
On Tuesday, 30 June 2015 at 00:02:38 UTC, Meta wrote:
It's a design mistake in Nullable. I would suggest that either
never use Nullable with a type that already has a null value,
or use the overload of Nullable that takes a null value, and
set it to null. Example:
Class Test {}
alias NullableTest = Nullable!(Test, null);
Can we not specialize the other overload for references,
pointers, and maybe slices?
Re: Nullable with reference types
On Tuesday, 30 June 2015 at 11:50:19 UTC, Marc Schütz wrote:
On Tuesday, 30 June 2015 at 00:02:38 UTC, Meta wrote:
It's a design mistake in Nullable. I would suggest that either
never use Nullable with a type that already has a null value,
or use the overload of Nullable that takes a null value, and
set it to null. Example:
Class Test {}
alias NullableTest = Nullable!(Test, null);
Can we not specialize the other overload for references,
pointers, and maybe slices?
Not now, as that would break code relying on this behaviour. I've
created a replacement for Nullable that does this, though, and it
works quite well.
goroutines vs vibe.d tasks
Just creating a bunch (10k) of sleeping (for 100 msecs) goroutines/tasks. Compilers go: go version go1.4.2 linux/amd64 vibe.d: DMD64 D Compiler v2.067.1 linux/amd64, vibe.d 0.7.23 Code go: http://pastebin.com/2zBnGBpt vibe.d: http://pastebin.com/JkpwSe47 go version build with go build test.go vibe.d version built with dub build --build=release test.d Results on my machine: go: 168.736462ms (overhead ~ 68ms) vibe.d: 1944ms (overhead ~ 1844ms) Why creating of vibe.d tasks is so slow (more then 10 times)???
Re: tkd - basic compilation problem
Using dub I get this during linking: Building tkd-test ~master configuration application, build type debug. Compiling using dmd... Linking... /usr/bin/ld: cannot find -ltcl /usr/bin/ld: cannot find -ltk ...any suggestions please?
Re: Pure delegate not quite pure?
On Tuesday, 30 June 2015 at 22:23:40 UTC, Tofu Ninja wrote:
On Tuesday, 30 June 2015 at 22:05:43 UTC, Steven Schveighoffer
wrote:
Have you tried placing const on the function signature? i.e.:
pure int delegate() const d = () const {...
That's how you'd do it (I think, didn't test) if the delegate
context pointer was a class/struct.
-Steve
Nah, says its only available for non-static member functions.
hmm, it seems that this would be an appropriate enhancement. It
doesn't make sense on a function, but as it relates to delegates
I'd say it makes sense to allow const to be added.
Re: Pure delegate not quite pure?
On Wednesday, 1 July 2015 at 00:13:36 UTC, Jesse Phillips wrote:
On Tuesday, 30 June 2015 at 22:23:40 UTC, Tofu Ninja wrote:
On Tuesday, 30 June 2015 at 22:05:43 UTC, Steven Schveighoffer
wrote:
Have you tried placing const on the function signature? i.e.:
pure int delegate() const d = () const {...
That's how you'd do it (I think, didn't test) if the delegate
context pointer was a class/struct.
-Steve
Nah, says its only available for non-static member functions.
hmm, it seems that this would be an appropriate enhancement. It
doesn't make sense on a function, but as it relates to
delegates I'd say it makes sense to allow const to be added.
const, immutable, shared, inout. Not sure if they all make sense
on delegates, but those are the options for member functions, so
they might apply to delegates as well.
Re: Best way to count character spaces.
On 1/07/2015 6:33 a.m., Taylor Hillegeist wrote: So I am aware that Unicode is not simple... I have been working on a boxes like project http://boxes.thomasjensen.com/ it basically puts a pretty border around stdin characters. like so: /\ \ \_|Different all twisty a| |of in maze are you, | |passages little. | | ___|_ \_/_/ but I find that I need to know a bit more than the length of the string because of encoding differences I had a thought at one point to do this: MyString.splitlines.map!(a = a.toUTF32.length).reduce!max(); Should get me the longest line. but this has a problem too because control characters might not take up space (backspace?). https://en.wikipedia.org/wiki/Unicode_control_characters leaving an unwanted nasty space :( or take weird amount of space \t. And perhaps the first isn't really something to worry about. Or should i do something like: MyString.splitLines .map!(a = a .map!(a = a .isGraphical) .map!(a = cast(int) a?1:0) .array .reduce!((a,b) = a+b)) .reduce!max Mostly I am just curious of best practice in this situation. Both of the above fail with the input: hello \n People \nP\u0008ofEARTH on my command prompt at least. Well I would personally use isWhite[0]. I would also use filter and count along with it. So something like this: size_t[] lengths = MyString.splitLines .filter!isWhite .count .array; Untested of course, but may give you ideas :) [0] http://dlang.org/phobos/std_uni.html#.isWhite
Re: Pure delegate not quite pure?
On Tuesday, 30 June 2015 at 22:23:40 UTC, Tofu Ninja wrote:
On Tuesday, 30 June 2015 at 22:05:43 UTC, Steven Schveighoffer
wrote:
Have you tried placing const on the function signature? i.e.:
pure int delegate() const d = () const {...
That's how you'd do it (I think, didn't test) if the delegate
context pointer was a class/struct.
-Steve
Nah, says its only available for non-static member functions.
Also wouldn't being able to annotate it immutable(also doesn't
work) solve both problems. If the context was immutable then
everything in it would have to be as well, d couldn't change it
and foo wouldn't be able to as well because every thing in the
context would have to be immutable. Or maybe I am understanding
it wrong.
Re: Template Declarations - Why not Template definitions?
I was reading D Templates: A Tutorial by Philippe Sigaud which
says:
--- quote
What is a Template? In the next chapters, you’ll see how to
define function, struct and class templates.
But before that, I’d like to introduce what a template really is,
because this
definition is the most fundamental of the whole document. As I
said, a template
is a way to define a blueprint to generate some code, be it a
class definition, a
function or. . . what? What could be the most abstract unit of
code?
But where is the basic unit to hold this code? Well, a code block
of course, or a
scope.
This is what a template is, at its core: a named, parameterized,
code block, ready to be instantiated just for you.
--- end quote
so thinking that I had reached a first principle, I wrote the
above template.
But then when this failed to compile, I then read further and it
says:
--- quote
Template Declarations
Here is the syntax for a template declaration:
template templateName(list, of, parameters)
{
// Some syntactically correct declarations here
// The arguments are accessible inside the template scope.
}
--- end quote
so the code block must consist only of declarations. Which lead
to me to ask my original question.
mixins could work but I'm just trying to understand templates and
this particular limitation.
Re: Pure delegate not quite pure?
On Tuesday, 30 June 2015 at 22:05:43 UTC, Steven Schveighoffer
wrote:
Have you tried placing const on the function signature? i.e.:
pure int delegate() const d = () const {...
That's how you'd do it (I think, didn't test) if the delegate
context pointer was a class/struct.
-Steve
Nah, says its only available for non-static member functions.
Re: Multi-dimensional fixed arrays
On Tuesday, 30 June 2015 at 21:02:39 UTC, DLearner wrote: On Tuesday, 30 June 2015 at 20:33:31 UTC, jmh530 wrote: On Tuesday, 30 June 2015 at 20:17:12 UTC, Justin Whear wrote: [...] I think this is a good explanation. Looking through http://dlang.org/arrays.html I see that the multidimensional array indexing is not particularly focused on (could be improved?). I tend to prefer reasoning things through than relying on a rule (more likely to forget the rule). Thus, I would recommend the OP looks at the way they describe the prefix array declarations for multidimensional arrays. They have the example int[4][3] b; // array of 3 arrays of 4 ints each So you can think of b as an array containing 3 arrays with 4 ints each. For the OP's foo, he should think of foo as an array containing 2 arrays with 1 int each. Moreover, it's more likely that you want to index the arrays and then what's in the arrays, i.e. it's more likely that you would want to do something with the first array of foo and then the second array of foo. This notation makes it a little bit easier to do that. Out of curiosity, why can't D define a 2-dim array by something like: int(2,1) foo; which defines two elements referred to as: foo(0,0) and foo(1,0)? It just seems unnatural (if not actually dangerous) to me to have the array index order reverse between definition and use. The notation comes from C. While I think there are many things that could be improved wrt arrays, I'm not sure this is one (in that exact way). However, improved ways to access multidimensional arrays is important to me. There is some work on improved multidimensional array support that may allow access that way I think.
Array operations, dynamic arrays and length
int[] a = [1,1,1,1]; int[] b = [1,1,1,1]; int[] c; c[] = a[] - b[]; c.writeln; This outputs []. This feels wrong, it feels like something that should have exploded or set the length to 4. If the lengths of a and b are mismatched it throws an exception. It also throws an exception if a dynamic array is longer or a static array is not the same length but is happy when a dynamic array is shorter. Is this intended behaviour and if so why?
Re: Pure delegate not quite pure?
On 6/30/15 5:44 PM, Tofu Ninja wrote:
On Tuesday, 30 June 2015 at 21:31:05 UTC, Steven Schveighoffer wrote:
On 6/30/15 5:23 PM, Tofu Ninja wrote:
On Sunday, 28 June 2015 at 10:19:05 UTC, anonymous wrote:
[...]
Is there any way to annotate the context as const?
const x = 4 ;)
But even if you could annotate just the *reference* as const, it
doesn't stop foo from changing it as you did in the example.
Yeah, but I am more worried about d changing x by itself(though foo
changing it is still a problem), I have a piece of code that takes a
delegate and I want to ensure that it runs in the same way every time
once it's given to me.
Have you tried placing const on the function signature? i.e.:
pure int delegate() const d = () const {...
That's how you'd do it (I think, didn't test) if the delegate context
pointer was a class/struct.
-Steve
Re: Multi-dimensional fixed arrays
On Tue, 30 Jun 2015 21:02:37 +, DLearner wrote: Out of curiosity, why can't D define a 2-dim array by something like: int(2,1) foo; which defines two elements referred to as: foo(0,0) and foo(1,0)? Work is being done on multidimensional slicing, see this thread: http://forum.dlang.org/post/dyvzmjfcjzoxvitwb...@forum.dlang.org It just seems unnatural (if not actually dangerous) to me to have the array index order reverse between definition and use. Think about it this way: alias IntList = int[10]; IntList[3] myIntLists; int[10][3] myOtherIntLists; // same type as above You build the type up from the innermost layer to the outermost and when you access the data you reverse that operation, slicing deeper and deeper.
Re: goroutines vs vibe.d tasks
On Tuesday, 30 June 2015 at 15:18:36 UTC, Jack Applegame wrote: Just creating a bunch (10k) of sleeping (for 100 msecs) goroutines/tasks. Compilers go: go version go1.4.2 linux/amd64 vibe.d: DMD64 D Compiler v2.067.1 linux/amd64, vibe.d 0.7.23 Code go: http://pastebin.com/2zBnGBpt vibe.d: http://pastebin.com/JkpwSe47 go version build with go build test.go vibe.d version built with dub build --build=release test.d Results on my machine: go: 168.736462ms (overhead ~ 68ms) vibe.d: 1944ms (overhead ~ 1844ms) Why creating of vibe.d tasks is so slow (more then 10 times)??? how do they compare if you replace the sleep with yield?
Re: Static constructors guaranteed to run?
On Monday, 29 June 2015 at 02:07:57 UTC, ketmar wrote: On Sat, 27 Jun 2015 22:49:13 +, Tofu Ninja wrote: On Saturday, 27 June 2015 at 22:20:40 UTC, ketmar wrote: 2. no. Hmm... any reason why? if instantiated template was not used in any code that makes into compiled binary, compiler is free to remove it with all it's ctors. it may do that, or may not, but removal is allowed. so while that can work now (i didn't checked), it may stop working in next version (or with another compiler), and that will not be a bug. Can you say the same about non templated static constructors? Like if a type is never used but it has a static constructor, is the compiler free to remove that as well?
Re: Static constructors guaranteed to run?
p.s. also note that module can has several static ctors, i.e. this works
fine:
=== z00.d ===
module z00;
import std.stdio;
static this () { writeln(ctor0); }
static this () { writeln(ctor1); }
=== z01.d ===
module z01;
import z00;
void main () {}
this prints:
ctor0
ctor1
so you can several initialization functions to module with, for example,
mixins.
signature.asc
Description: PGP signature
Re: generic cast(unshared) ?
On Sunday, 28 June 2015 at 23:42:47 UTC, Timothee Cour wrote: How would I cast away shared for a given expression? I can write it for a specific type but I'd like to have a generic way to do so. Also, Unqual doesn't help here. Normally, cast() removes shared from a type. BUT, sometimes it doesn't work for me, and forces me to type the type of variable again.
generic cast(unshared) ?
How would I cast away shared for a given expression? I can write it for a specific type but I'd like to have a generic way to do so. Also, Unqual doesn't help here.
Re: Bug or feature?
I'd say bug, I think the array function is trying an optimization it shouldn't be trying for immutable classes.
Re: generic cast(unshared) ?
Note: should work with any types, eg: shared(T[])* = T[]* etc... On Sun, Jun 28, 2015 at 4:42 PM, Timothee Cour thelastmamm...@gmail.com wrote: How would I cast away shared for a given expression? I can write it for a specific type but I'd like to have a generic way to do so. Also, Unqual doesn't help here.
Re: Static constructors guaranteed to run?
On Monday, 29 June 2015 at 02:31:18 UTC, ketmar wrote: yes. it doesn't do that now, afair, but i can't see any sense in running code that obviously does nothing, as it's owner is not used. module ctors was designed for such things -- i.e. to run some code on startup. if someone is doing some vital initialization in static ctor of struct or class, and that struct or class aren't used anywhere else in his code, he's doing it wrong. it *may* work now, but that's simply 'cause compiler is not very well at removing unused code. That seems wrong, what if I am doing separate compilation, how would the compiler know if the type is going to be used or not...
Re: Static constructors guaranteed to run?
On Sat, 27 Jun 2015 22:49:13 +, Tofu Ninja wrote: On Saturday, 27 June 2015 at 22:20:40 UTC, ketmar wrote: 2. no. Hmm... any reason why? p.s. note that static ctors are *intended* to run in runtime, not in compile time. if compiler decides that some code is not required in runtime, it is free to remove all that code, including static ctors. signature.asc Description: PGP signature
Re: Static constructors guaranteed to run?
On Mon, 29 Jun 2015 03:10:44 +, Tofu Ninja wrote: On Monday, 29 June 2015 at 02:31:18 UTC, ketmar wrote: yes. it doesn't do that now, afair, but i can't see any sense in running code that obviously does nothing, as it's owner is not used. module ctors was designed for such things -- i.e. to run some code on startup. if someone is doing some vital initialization in static ctor of struct or class, and that struct or class aren't used anywhere else in his code, he's doing it wrong. it *may* work now, but that's simply 'cause compiler is not very well at removing unused code. That seems wrong, what if I am doing separate compilation, how would the compiler know if the type is going to be used or not... it doesn't really matter if you compiled your code separate or not: compiler *has* to know everything to successfully link the program. and it knows. for now it doesn't do much with that info, though, as using binutils for languages like D sux: D needs it's own compiled module format and optimising linker. but as i told ealier, this is the limitiation of current implementation, not guarantee. signature.asc Description: PGP signature
Re: Porting from D1 to D2
On 6/28/2015 2:48 AM, ponce wrote: I don't quite get what code could be generating that reference, since I don't call format or toString on a Throwable. You can grep the .obj files for the symbol.
Re: Static constructors guaranteed to run?
On Sat, 27 Jun 2015 22:49:13 +, Tofu Ninja wrote: On Saturday, 27 June 2015 at 22:20:40 UTC, ketmar wrote: 2. no. Hmm... any reason why? if instantiated template was not used in any code that makes into compiled binary, compiler is free to remove it with all it's ctors. it may do that, or may not, but removal is allowed. so while that can work now (i didn't checked), it may stop working in next version (or with another compiler), and that will not be a bug. signature.asc Description: PGP signature
std.concurrent Tid vector initialization problem
I'm planning an application where a series of threads each need to be aware of the Tids of all the others. The number won't be known at compile time, but that doesn't seem to change the design. All I've been able to come up with is a pair of loops, one to spawn the threads, and collect their Tids, and a second for each one to send its Tid to all the others. receive doesn't seem to want to work with shared Tids. My original design was to have a file level shared array of Tids, but receive (or possibly send) objected to attempts to use them. They aren't known until they've been spawned, so I can't pass them as spawn parameters. Etc. This seems like a very clumsy initialization design. Does anyone have a better idea? (The rough estimate of the number of Tids is six, but that's likely to change from run to run.)
Re: how to iterate on Array?
On Sunday, 28 June 2015 at 10:16:47 UTC, Marc Schütz wrote:
On Saturday, 27 June 2015 at 17:43:13 UTC, aki wrote:
But when I compile it by DMD 2.062 on Windows
it says:
testArray.d(5): Error: cannot infer argument types
(line 5 is at foreach(i, v; a[]) { )
2.062 is really ancient, we're about to release 2.068 soon.
Consider upgrading, because there have been tons of bugfixes
since your version.
On current DMD, the error message is slightly clearer:
Error: cannot infer argument types, expected 1 argument, not 2
Ah, you answered my another question.
Even if I put all the types like foreach(size_t i, int v; a[])
he still said cannot infer. I wonder why he need to infer?
Now I got it. I'm looking forward 2.068.
Aki.
Re: std.concurrent Tid vector initialization problem
On 06/28/2015 01:50 PM, Charles Hixson via Digitalmars-d-learn wrote: I'm planning an application where a series of threads each need to be aware of the Tids of all the others. The original thread did receive a couple of responses: http://forum.dlang.org/thread/mailman.5134.1435453322.7663.digitalmars-d-le...@puremagic.com Ali
Re: Static constructors guaranteed to run?
On Mon, 29 Jun 2015 02:19:54 +, Tofu Ninja wrote: On Monday, 29 June 2015 at 02:07:57 UTC, ketmar wrote: On Sat, 27 Jun 2015 22:49:13 +, Tofu Ninja wrote: On Saturday, 27 June 2015 at 22:20:40 UTC, ketmar wrote: 2. no. Hmm... any reason why? if instantiated template was not used in any code that makes into compiled binary, compiler is free to remove it with all it's ctors. it may do that, or may not, but removal is allowed. so while that can work now (i didn't checked), it may stop working in next version (or with another compiler), and that will not be a bug. Can you say the same about non templated static constructors? Like if a type is never used but it has a static constructor, is the compiler free to remove that as well? yes. it doesn't do that now, afair, but i can't see any sense in running code that obviously does nothing, as it's owner is not used. module ctors was designed for such things -- i.e. to run some code on startup. if someone is doing some vital initialization in static ctor of struct or class, and that struct or class aren't used anywhere else in his code, he's doing it wrong. it *may* work now, but that's simply 'cause compiler is not very well at removing unused code. signature.asc Description: PGP signature
Re: Nullable with reference types
On Monday, 29 June 2015 at 19:29:37 UTC, sigod wrote:
Hi, everyone.
```
import std.typecons : Nullable;
class Test {}
Nullable!Test test;
assert(test.isNull);
```
Why does `Nullable` allowed to be used with reference types
(e.g. classes)?
P.S. I have experience with C#, where `NullableT` cannot be
used with reference types. And it sounds logical to me.
It does feel wrong but there is another feature of Nullable where
you can define the value of null. Which might be handy in some
cases where you don't want a reference type to actually be null?
I don't know if this is the case but it may be useful.
Why D doesn't have an equivalent to C#'s readonly?
I believe it's a design choice, if so, could someone explain why? is immutable better than C#'s readonly so that the readonly keyword isn't even needed? for example, I'd like to declare a member as readonly but I can't do it directly because immutable create a new type (since it's a type specific, correct?) isn't really the same thing. MyClass x = new MyClass(); if I do auto x = new immutable(MyClass)(); give errors
Re: Nullable with reference types
On Monday, 29 June 2015 at 19:29:37 UTC, sigod wrote:
Hi, everyone.
```
import std.typecons : Nullable;
class Test {}
Nullable!Test test;
assert(test.isNull);
```
Why does `Nullable` allowed to be used with reference types
(e.g. classes)?
P.S. I have experience with C#, where `NullableT` cannot be
used with reference types. And it sounds logical to me.
It's a design mistake in Nullable. I would suggest that either
never use Nullable with a type that already has a null value, or
use the overload of Nullable that takes a null value, and set
it to null. Example:
Class Test {}
alias NullableTest = Nullable!(Test, null);
Re: Why D doesn't have an equivalent to C#'s readonly?
On Monday, 29 June 2015 at 20:12:12 UTC, Assembly wrote:
I believe it's a design choice, if so, could someone explain
why? is immutable better than C#'s readonly so that the
readonly keyword isn't even needed? for example, I'd like to
declare a member as readonly but I can't do it directly because
immutable create a new type (since it's a type specific,
correct?) isn't really the same thing.
MyClass x = new MyClass();
if I do
auto x = new immutable(MyClass)();
give errors
There are a few ways you can enforce a field to be readonly.
You can use properties:
import std.stdio;
class Foo
{
private int _bar;
this(int bar)
{
this._bar = bar;
}
public @property int bar()
{
return this._bar;
}
}
void main(string[] args)
{
auto foo = new Foo(1337);
writefln(%s, foo.bar);
// Error:
// foo.bar = 10;
}
or a manifest constant:
import std.stdio;
class Foo
{
public enum int bar = 1337;
}
void main(string[] args)
{
auto foo = new Foo();
writefln(%s, foo.bar);
// Error:
// foo.bar = 10;
}
Packing enums
I stumbled upon this interesting programming challenge [0], which
imho should be possible to implement in D. Maybe someone here
wants to try.
Task: Given two enums with less than 256 states, pack them into
one byte and provide convenient accessor functions.
Something like this:
enum X { A, B, C };
enum Y { foo, bar, baz };
alias both = TwoEnums!(X,Y);
static assert(both.sizeof == 1);
both z;
z.X = B;
z.Y = bar;
Of course, you can generalize to n enums packed into a minimal
number of bytes.
[0] https://news.ycombinator.com/item?id=9800231
Re: Why D doesn't have an equivalent to C#'s readonly?
On Monday, 29 June 2015 at 22:11:16 UTC, sigod wrote: `new immutable(MyClass)()` is invalid code. It's perfectly fine, actually.
Re: how do I create an array of objects as member of class?
On Friday, 26 June 2015 at 22:14:56 UTC, Adam D. Ruppe wrote:
On Friday, 26 June 2015 at 21:50:30 UTC, Assembly wrote:
class Baa {
Foo a = new Foo();
Foo b = new Foo();
Foo[] l = [a,b];
I wasn't aware about this. I'm used to have static only when I
request so, like using static keyword in each member that must be
static. Gonna move it to the constructor.
Keep in mind that those instances are *static* and probably not
what you expect; modifying a will be seen across all instances
of Baa unless you actually assign it to a new member.
I know this works:
Doing it in the constructor is really the best way.
Gonna do so, thanks
Re: Packing enums
On Monday, 29 June 2015 at 22:05:47 UTC, qznc wrote:
I stumbled upon this interesting programming challenge [0],
which imho should be possible to implement in D. Maybe someone
here wants to try.
Task: Given two enums with less than 256 states, pack them into
one byte and provide convenient accessor functions.
Something like this:
enum X { A, B, C };
enum Y { foo, bar, baz };
alias both = TwoEnums!(X,Y);
static assert(both.sizeof == 1);
both z;
z.X = B;
z.Y = bar;
Of course, you can generalize to n enums packed into a minimal
number of bytes.
[0] https://news.ycombinator.com/item?id=9800231
Have you tried using bitfields?
enum X : byte { A, B, C };
enum Y : byte { foo, bar, baz };
mixin(bitfields!(
X, x,3,
Y, y,3,
uint, , 2));
Re: Bug or feature?
On Mon, 29 Jun 2015 05:04:36 -0700
Jonathan M Davis via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On Sunday, June 28, 2015 11:37:59 Jack Applegame via
Digitalmars-d-learn wrote:
I don't see any reason why it should not compile.
import std.array;
import std.range;
import std.algorithm;
class Foo {
}
void main() {
auto result = iota(3).map!(i = new immutable Foo).array();
}
/usr/include/dmd/phobos/std/conv.d(4028): Error: cannot
implicitly convert expression (arg) of type immutable(Foo) to
test.Foo
/usr/include/dmd/phobos/std/conv.d(3931): Error: template
instance
std.conv.emplaceImpl!(immutable(Foo)).emplaceImpl!(immutable(Foo))
error
instantiating /usr/include/dmd/phobos/std/array.d(115):
instantiated from here: emplaceRef!(immutable(Foo), Foo,
immutable(Foo)) test.d(9):instantiated from here:
array!(MapResult!(__lambda1, Result))
You haven't declared an immutable constructor, so you can't construct
an immutable Foo. If the default constructor were pure, then it could
be used to construct immutable objects even if it weren't immutable,
but the default constructor is neither pure nor immutable, and purity
isn't inferred for normal functions.
It might make sense as a feature request to request that a class'
default constructor be pure (assuming that its base class constructor
is pure), since theoretically, it should be able to be pure, but that
would be a change in the language. What you're seeing is not a bug.
It's how the current design works.
- Jonathan M Davis
No it is a bug in std.conv.emplaceRef or more probably in std.array.
Re: Typed Message Passing between D Processes
On Monday, 29 June 2015 at 10:22:10 UTC, Atila Neves wrote: I guess I'm going to have benchmark this now... :) What about doing a memory profiling using DMD fresh builtin profiler of http://dpaste.dzfl.pl/17b0ed9c0204 ? I'm guessing the GC might give misguiding results as your testStruct returns a relatively small data structure. I would rather like to see a larger (randomized) structure being tested on. You could make use of my https://github.com/nordlow/justd/blob/master/random_ex.d for random instance generation :)
Re: Static constructors guaranteed to run?
On Monday, 29 June 2015 at 11:36:42 UTC, ketmar wrote: it doesn't, afair, but it's quite natural. if user type was throwed out as unused, it would be very strange to insist on keeping it's initialization code. Yes, but I would instead expect that the static ctor prevents the type from becoming unused in the first place.
Nullable with reference types
Hi, everyone.
```
import std.typecons : Nullable;
class Test {}
Nullable!Test test;
assert(test.isNull);
```
Why does `Nullable` allowed to be used with reference types (e.g.
classes)?
P.S. I have experience with C#, where `NullableT` cannot be
used with reference types. And it sounds logical to me.
Re: Why D doesn't have an equivalent to C#'s readonly?
On Monday, 29 June 2015 at 20:12:12 UTC, Assembly wrote: I believe it's a design choice, if so, could someone explain why? is immutable better than C#'s readonly so that the readonly keyword isn't even needed? for example, I'd like to declare a member as readonly but I can't do it directly because immutable create a new type (since it's a type specific, correct?) isn't really the same thing. MyClass x = new MyClass(); if I do auto x = new immutable(MyClass)(); give errors Why? I think `const` and `immutable` even better than C#'s `readonly`. Also, are you aware that it's recommended to use `const` instead of `readonly`? `new immutable(MyClass)()` is invalid code. Try `immutable MyClass x = new MyClass();`.
Re: Why D doesn't have an equivalent to C#'s readonly?
On Monday, 29 June 2015 at 22:22:46 UTC, anonymous wrote: On Monday, 29 June 2015 at 22:11:16 UTC, sigod wrote: `new immutable(MyClass)()` is invalid code. It's perfectly fine, actually. Yes, you're right. It seems I've mistyped `immutable` when was checking it with compiler.
Re: Setting um makefile for dmd
something like that can help? ``` run: all $(OUT) ```
Re: Pure delegate not quite pure?
On Sunday, 28 June 2015 at 10:19:05 UTC, anonymous wrote: [...] Is there any way to annotate the context as const?
Re: Multi-dimensional fixed arrays
On Tuesday, 30 June 2015 at 20:33:31 UTC, jmh530 wrote: On Tuesday, 30 June 2015 at 20:17:12 UTC, Justin Whear wrote: [...] I think this is a good explanation. Looking through http://dlang.org/arrays.html I see that the multidimensional array indexing is not particularly focused on (could be improved?). I tend to prefer reasoning things through than relying on a rule (more likely to forget the rule). Thus, I would recommend the OP looks at the way they describe the prefix array declarations for multidimensional arrays. They have the example int[4][3] b; // array of 3 arrays of 4 ints each So you can think of b as an array containing 3 arrays with 4 ints each. For the OP's foo, he should think of foo as an array containing 2 arrays with 1 int each. Moreover, it's more likely that you want to index the arrays and then what's in the arrays, i.e. it's more likely that you would want to do something with the first array of foo and then the second array of foo. This notation makes it a little bit easier to do that. Out of curiosity, why can't D define a 2-dim array by something like: int(2,1) foo; which defines two elements referred to as: foo(0,0) and foo(1,0)? It just seems unnatural (if not actually dangerous) to me to have the array index order reverse between definition and use.
Re: is it safe to call `GC.removeRange` in dtor?
On Saturday, 27 June 2015 at 21:53:33 UTC, ketmar wrote: is it safe to call `GC.removeRange` in dtor? i believe it should be safe, so one can perform various cleanups, but documentation says nothing about guarantees It's not documented. Afaik parts of the standard library depend on this behavior so I'd say ok* where the asterisk means submit a specification update.
Re: Multi-dimensional fixed arrays
I am pretty surprised, as the following code gives errors.
void main(){
int [1][2] foo;
foo[0][0] = 1;
foo[0][1] = 2;
foo[1][0] = 3;
foo[1][1] = 4;
}
Those errors are:
app.d(5): Error: array index 1 is out of bounds foo[0][0 .. 1]
app.d(7): Error: array index 1 is out of bounds foo[1][0 .. 1]
Could anyone more experienced than me explain why this is, and
why not it's the other way around?
Template Declarations - Why not Template definitions?
All the stuff I've read about templates always refers to them as
template declarations.
So with the following code segment:
template codeBlockTemplate(T, U)
{
T a = 7;
U b = 'z';
}
codeBlockTemplate!(int, char); // error here
Microsof's Visual Studio IDE tells me identifier expected, ;
found
But aren't templates instantiated at compile time? If so, isn't
memory allocated at compile time, so in theory couldn't templates
support code definitions?
Bonus question: Isn't a Zero-parameter template declaration
pretty much worthless?
Thanks.
Re: std.concurrent Tid vector initialization problem
On Sunday, 28 June 2015 at 09:59:29 UTC, Marc Schütz wrote:
On Sunday, 28 June 2015 at 01:02:02 UTC, Charles Hixson wrote:
I'm planning an application where a series of threads each
...gn. Does anyone have a better idea?
(The rough estimate of the number of Tids is six, but that's
likely to change from run to run.)
The most elegant solution I can think of is this:
struct Go { }
__gshared const Tid[] allTids;
void myfunc(...) {
receiveOnly!Go();
// do the work
}
shared static this() {
Tid[] tids;
foreach(thread; threads)
tids ~= spawn(myfunc, ...);
*cast(const(int)[]*) allTids = tids;
foreach(tid; allTids)
tid.send(Go());
}
I believe the cast is not even undefined behaviour, because
it's not immutable, but I'm not sure. But the const-ness guards
against accidental modification of `allTids` by a thread.
Alternatively, you could make `allTids` private, provide a
public getter, and implement the threads in another module.
Or you could simply leave the global array mutable and be
careful not to modify it.
Thanks. That sounds similar to the approach that I had though
of, except that you're doing it in a static this().
(I'd have answered sooner, but my D email seems to have died.
Only the D groups are currently dead now, though my entire
account was dead for a couple of weeks. [ATT])
Re: Multi-dimensional fixed arrays
On Tue, 30 Jun 2015 20:09:50 +, DLearner wrote: Suppose: 'int [1][2] foo;' Probably I misunderstand, but TDPL seems to say that foo has two elements: foo[0][0] and foo[1][0] as opposed to two elements: foo[0][0] and foo[0][1] Is this correct? No. The order of braces when indexing is the opposite of the order when declaring. The declaration int [1][2] foo; reads innermost to outermost, ((int [1] ) [2]) When indexing foo, you index from outermost to innermost, so foo[1] means the second one-element array and foo[1][0] means the first element of the second one-element array.
Re: Nullable with reference types
On 6/30/15 11:16 AM, Jonathan M Davis wrote:
On Tuesday, 30 June 2015 at 00:02:38 UTC, Meta wrote:
On Monday, 29 June 2015 at 19:29:37 UTC, sigod wrote:
Hi, everyone.
```
import std.typecons : Nullable;
class Test {}
Nullable!Test test;
assert(test.isNull);
```
Why does `Nullable` allowed to be used with reference types (e.g.
classes)?
P.S. I have experience with C#, where `NullableT` cannot be used
with reference types. And it sounds logical to me.
It's a design mistake in Nullable. I would suggest that either never
use Nullable with a type that already has a null value, or use the
overload of Nullable that takes a null value, and set it to null.
Example:
Class Test {}
alias NullableTest = Nullable!(Test, null);
I tend to think that it's incredibly stupid to use something like
Nullable for a type that's already Nullable. It's just silly. If a type
is already nullable, then just use that and stop being adding extra
overhead for no good reason. However, it _is_ true that if you need to
have a nullable variable in generic code where the type that you need to
be nullable could be any type, then having Nullable work with all types
- and work with them all in the same way - is useful. Without that,
you'd have to special case your code for types which were naturally
nullable (and thus used null) and those which required Nullable. So, I
can see why it could be useful to have Nullable work with classes, but I
also question how common such a use case is.
I know this is just back-of-envelope, but what's wrong with:
alias Nullable(T) if(is(T == class)) = T;
bool isNull(T)(T t) if(is(T == class)) { return t is null;}
?
-Steve
Re: goroutines vs vibe.d tasks
On Tuesday, 30 June 2015 at 17:37:38 UTC, Atila Neves wrote: Sleep will almost certainly pause and block the fiber. Vibe.d only switches between them when there's IO to be done or something else from the event loop. Sleep blocks the fiber, but not the event loop. Because it isn't core.thread.Thread.sleep, but vibe.core.core.sleep - http://vibed.org/api/vibe.core.core/sleep
Re: proper way to calculate toHash() for string
On 30/06/15 16:19, aki wrote: Please suggest me if anyone have an idea. You can use TypeInfo.getHash [1] to get the hash of a given value. Something like: string a = foo; typeid(a).getHash(a) [1] http://dlang.org/phobos/object.html#.TypeInfo.getHash -- /Jacob Carlborg
Re: Multi-dimensional fixed arrays
On Tuesday, 30 June 2015 at 20:17:12 UTC, Justin Whear wrote: No. The order of braces when indexing is the opposite of the order when declaring. The declaration int [1][2] foo; reads innermost to outermost, ((int [1] ) [2]) When indexing foo, you index from outermost to innermost, so foo[1] means the second one-element array and foo[1][0] means the first element of the second one-element array. I think this is a good explanation. Looking through http://dlang.org/arrays.html I see that the multidimensional array indexing is not particularly focused on (could be improved?). I tend to prefer reasoning things through than relying on a rule (more likely to forget the rule). Thus, I would recommend the OP looks at the way they describe the prefix array declarations for multidimensional arrays. They have the example int[4][3] b; // array of 3 arrays of 4 ints each So you can think of b as an array containing 3 arrays with 4 ints each. For the OP's foo, he should think of foo as an array containing 2 arrays with 1 int each. Moreover, it's more likely that you want to index the arrays and then what's in the arrays, i.e. it's more likely that you would want to do something with the first array of foo and then the second array of foo. This notation makes it a little bit easier to do that.
Re: Multi-dimensional fixed arrays
Oh, seems I should learn to refresh the page :)
Re: Pure delegate not quite pure?
On 6/30/15 5:23 PM, Tofu Ninja wrote: On Sunday, 28 June 2015 at 10:19:05 UTC, anonymous wrote: [...] Is there any way to annotate the context as const? const x = 4 ;) But even if you could annotate just the *reference* as const, it doesn't stop foo from changing it as you did in the example. -Steve
Best way to count character spaces.
So I am aware that Unicode is not simple... I have been working on a boxes like project http://boxes.thomasjensen.com/ it basically puts a pretty border around stdin characters. like so: /\ \ \_|Different all twisty a| |of in maze are you, | |passages little. | | ___|_ \_/_/ but I find that I need to know a bit more than the length of the string because of encoding differences I had a thought at one point to do this: MyString.splitlines.map!(a = a.toUTF32.length).reduce!max(); Should get me the longest line. but this has a problem too because control characters might not take up space (backspace?). https://en.wikipedia.org/wiki/Unicode_control_characters leaving an unwanted nasty space :( or take weird amount of space \t. And perhaps the first isn't really something to worry about. Or should i do something like: MyString.splitLines .map!(a = a .map!(a = a .isGraphical) .map!(a = cast(int) a?1:0) .array .reduce!((a,b) = a+b)) .reduce!max Mostly I am just curious of best practice in this situation. Both of the above fail with the input: hello \n People \nP\u0008ofEARTH on my command prompt at least.
Multi-dimensional fixed arrays
Suppose: 'int [1][2] foo;' Probably I misunderstand, but TDPL seems to say that foo has two elements: foo[0][0] and foo[1][0] as opposed to two elements: foo[0][0] and foo[0][1] Is this correct?
Re: goroutines vs vibe.d tasks
On Tuesday, 30 June 2015 at 15:18:36 UTC, Jack Applegame wrote: Just creating a bunch (10k) of sleeping (for 100 msecs) goroutines/tasks. Compilers go: go version go1.4.2 linux/amd64 vibe.d: DMD64 D Compiler v2.067.1 linux/amd64, vibe.d 0.7.23 Code go: http://pastebin.com/2zBnGBpt vibe.d: http://pastebin.com/JkpwSe47 go version build with go build test.go vibe.d version built with dub build --build=release test.d Results on my machine: go: 168.736462ms (overhead ~ 68ms) vibe.d: 1944ms (overhead ~ 1844ms) Why creating of vibe.d tasks is so slow (more then 10 times)??? fwiw I have 151ms total time for go; 740 ms for ldc (O2 and singleobj), and 760ms for dmd. on an old zoostorm running 64bit arch linux. microbenchmarks may be testing many strange things, and it requires more expertise than I currently have to know where this might come from.
