Re: Deducing a template retrun parameter type based on an assignment?
Jeremy DeHaan: I figured that it would be smart enough to deduce the parameter type based on the type that it was trying to be assigned to. For that you need languages like Haskell/Rust. D type inference doesn't work from the type something is assigned to. Bye, bearophile
Re: Getting DAllegro 5 to work in Windows
On Friday, 30 January 2015 at 07:34:53 UTC, Mike Parker wrote: On 1/30/2015 3:16 PM, Joel wrote: Update. What happens is, that I run the script file (in DAllegro folder) and it is suppose to create lib files from the DLL ones. On my system, it says its done it but no lib files pop up! It happens on another computer too. (maybe from my dodgy flash drive). The guy at the computer shop said he didn't think it was a virus. There's an idea that the files get wiped off as soon as they are created. So I've just been using an older version of Allegro/DAllegro. FYI, I have a nearly finished dynamic binding to Allegro 5 that doesn't require any link-time dependencies. I'll be adding it to DerelictOrg as soon as it's done. I hope that to be sometime on the other side of this coming weekend. I only have a couple more addons to work through. Ok, cool. What about Mac OS?
Re: Getting DAllegro 5 to work in Windows
On Friday, 30 January 2015 at 07:53:12 UTC, Kagamin wrote: On Friday, 30 January 2015 at 06:16:21 UTC, Joel wrote: What happens is, that I run the script file (in DAllegro folder) and it is suppose to create lib files from the DLL ones. On my system, it says its done it but no lib files pop up! You can try procmon to watch, what happens with files. Ok, I'll have to have a look.
Re: Getting DAllegro 5 to work in Windows
On 1/30/2015 6:48 PM, Joel wrote: FYI, I have a nearly finished dynamic binding to Allegro 5 that doesn't require any link-time dependencies. I'll be adding it to DerelictOrg as soon as it's done. I hope that to be sometime on the other side of this coming weekend. I only have a couple more addons to work through. Ok, cool. What about Mac OS? It should work across all the major platforms.
Re: Deducing a template retrun parameter type based on an assignment?
On Friday, 30 January 2015 at 08:52:41 UTC, bearophile wrote: Jeremy DeHaan: I figured that it would be smart enough to deduce the parameter type based on the type that it was trying to be assigned to. For that you need languages like Haskell/Rust. D type inference doesn't work from the type something is assigned to. But it could, right (for arguments and return expressions, too)? At least I don't see any real obstacles. Just file an enhancement request if you think it's worthwhile, or start a discussion on digitalmars.D. Of course, it cannot work for `auto x = getString();` or `foo(getString())` where there are several overloads of `foo()`. The next step would then be overloading on the return type, which is related.
Thread.sleep( dur!("msecs")( 50 ) ); // sleep for 50 milliseconds
foreach(f; files))
{
if (canFind(to!string(f), " "))
{
writeln("whitespace found:");
writeln(f);
Thread.sleep( dur!("msecs")( 50 ) ); // sleep for 50
milliseconds
}
else
continue;
}
Error: module app struct std.regex.Thread(DataIndex) is private
Error: no property 'sleep' for type 'void'
What's wrong? Why sleeping do not work?
Re: Thread.sleep( dur!("msecs")( 50 ) ); // sleep for 50 milliseconds
Error: module app struct std.regex.Thread(DataIndex) is private Did you import core.thread?
Re: Is it possible to use an UDA to generate a struct inside a class ?
On Thursday, 1 January 2015 at 22:49:40 UTC, Basile Burg wrote: On Thursday, 1 January 2015 at 21:15:27 UTC, Ali Çehreli wrote: On 01/01/2015 09:35 AM, Basile Burg wrote: > On Tuesday, 30 December 2014 at 19:18:41 UTC, Basile Burg wrote: > an ICE (every > compiler crash is an ICE right ?), Yes, the compiler should never crash but produce an error message. Please report it preferably with a reduced code sample: The report is filed. I was not sure of its validity or if it could be a dup. - You realize, all of those foreach'es are processed at compile-time for code generation. There will be no 'o' at run time; so its address cannot be used. Instead, Can I get the *relative offset* of a particular member at compile-time ? Then at run-time I could easily define the delegate, eg: // the AA or some arrays filled at compile-time ptrdiff_t[string] gettersOffset; ptrdiff_t[string] settersOffset; // a delegate, set at run-time, for example in this(). myDelegate.funcptr = gettersOffset["propIdentifier"]; myDelegate.ptr = cast(void*) this; If so then the problem is solved...even if other problems could appends, for example if the methods are final, if they are inlined... Actually I'd be surprised that nobody has already designed something similar for properties (kind of "published" attribute as defined in Pascal-like languages.) This was the way to go (the relative-offset "thing"): 1/ __traits(getVirtualIndex,...) works at compile time 2/ then the method pointer can be constructed using vtbl And it works, though I'm still open to another solution (since now the get/set >>must<< be virtual) Current implementation: https://github.com/BBasile/Iz/blob/master/import/iz/properties.d#L383 :)
Re: Thread.sleep( dur!("msecs")( 50 ) ); // sleep for 50 milliseconds
On 2015-01-30 at 11:55, FG wrote:
Error: module app struct std.regex.Thread(DataIndex) is private
Did you import core.thread?
This is silly. Thread is internal to std.regex, yet when importing both
std.regex and core.thread, you still get an error:
src.d(10): Error: core.thread.Thread at ..\thread.d(514) conflicts with
std.regex.Thread(Dat
aIndex) at ..\src\phobos\std\regex.d(4588)
The way around is of course the use of a fully qualified name:
core.thread.Thread.sleep( dur!("msecs")( 50 ) );
but there really should be no need for this, since std.regex.Thread is private.
Bug or correct behaviour?
Re: Getting DAllegro 5 to work in Windows
On Wednesday, 24 December 2014 at 06:47:26 UTC, Joel wrote: I can't get implib.exe (http://ftp.digitalmars.com/bup.zip) to produce .lib files from dlls (https://www.allegro.cc/files/). I think it works for other people. Thanks for any help. Yep, it works for other people. I've just made the Coedit project for allegro, something like 2 days ago: https://github.com/BBasile/ceprojs/blob/master/dallegro.coedit and the example using the libman: https://github.com/BBasile/ceprojs/blob/master/dallegro_example.coedit Maybe you've get messed with the imports ?
Re: Thread.sleep( dur!("msecs")( 50 ) ); // sleep for 50 milliseconds
On Friday, January 30, 2015 10:39:44 Suliman via Digitalmars-d-learn wrote:
> foreach(f; files))
> {
> if (canFind(to!string(f), " "))
> {
> writeln("whitespace found:");
> writeln(f);
> Thread.sleep( dur!("msecs")( 50 ) ); // sleep for 50
> milliseconds
> }
> else
> continue;
> }
>
> Error: module app struct std.regex.Thread(DataIndex) is private
> Error: no property 'sleep' for type 'void'
>
> What's wrong? Why sleeping do not work?
Did you import std.regex but not core.thread? Or did you import std.regex
with a local import and core.thread with a module-level import?
Unfortunately, private symbols are visible and can cause symbol conflicts
(even though they can't actually be used), so sometimes we end up with
conflicts due to private symbols. Being more specific - e.g.
core.Thread.sleep() - should fix the problem. But it's also possible that
you failed to import core.thread in the first place, in which case,
Thread.sleep isn't even visible to your code.
- Jonathan M Davis
Re: Thread.sleep( dur!("msecs")( 50 ) ); // sleep for 50 milliseconds
On Friday, 30 January 2015 at 11:04:47 UTC, FG wrote: Bug or correct behaviour? Bug: https://issues.dlang.org/show_bug.cgi?id=1238
Re: Thread.sleep( dur!("msecs")( 50 ) ); // sleep for 50 milliseconds
On 2015-01-30 at 12:08, Vladimir Panteleev wrote: On Friday, 30 January 2015 at 11:04:47 UTC, FG wrote: Bug or correct behaviour? Bug: https://issues.dlang.org/show_bug.cgi?id=1238 https://github.com/D-Programming-Language/dmd/pull/3743 The fix is pretty much a one-liner. Probably 2.067 will already include it, right?
foreach - premature optimization vs cultivating good habits
Hi. The standard advice is not to worry about memory usage and execution speed until profiling shows you where the problem is, and I respect Knuth greatly as a thinker. Still, one may learn from others' experience and cultivate good habits early. To say that one should not prematurely optimize is not to say that one should not try to avoid cases that tend to be really bad, and I would rather learn from others what these are then learn only the hard way. For the time being I am still at early development stage and have not yet tested things with the larger data sets I anticipate eventually using. It's cheap to make slightly different design decisions early, but much more painful further down the line, particularly given my context. As I understand it, foreach allocates when a simple C-style for using an array index would not. I would like to learn more about when this turns particularly expensive, and perhaps I could put this up on the wiki if people think it is a good idea. What exactly does it allocate, and how often, and how large is this in relation to the size of the underlying data (structs/classes/ranges)? Are there any cache effects to consider? Happy to go to the source code if you can give me some pointers. Thanks in advice for any thoughts. Laeeth.
Re: foreach - premature optimization vs cultivating good habits
On Friday, 30 January 2015 at 11:55:16 UTC, Laeeth Isharc wrote: Hi. The standard advice is not to worry about memory usage and execution speed until profiling shows you where the problem is, and I respect Knuth greatly as a thinker. Still, one may learn from others' experience and cultivate good habits early. To say that one should not prematurely optimize is not to say that one should not try to avoid cases that tend to be really bad, and I would rather learn from others what these are then learn only the hard way. For the time being I am still at early development stage and have not yet tested things with the larger data sets I anticipate eventually using. It's cheap to make slightly different design decisions early, but much more painful further down the line, particularly given my context. As I understand it, foreach allocates when a simple C-style for using an array index would not. I would like to learn more about when this turns particularly expensive, and perhaps I could put this up on the wiki if people think it is a good idea. What exactly does it allocate, and how often, and how large is this in relation to the size of the underlying data (structs/classes/ranges)? Are there any cache effects to consider? Happy to go to the source code if you can give me some pointers. Thanks in advice for any thoughts. Laeeth. foreach() is good for linked list because it uses a delegate so it avoids to cross the items from 0 to i at each iteration. for() is good for arrays because of the pointer arithmetic. But the D way for foreach'es is to use ranges: popFront etc, although i often feel too lazy to use them... You'll probably get more technical answers...
is it bug?
``` import std.container: RedBlackTree; class Manager(TT, alias Cmp = "a
Input error with readf()
If I run the following example program from the 'Programming in
D' book, the input doesn't 'get stuck' as stated in the book but
instead produces the error message given. Have things changed
since that part of the book was written or is it some other
issue? The version that uses " %s" in the call to readf works as
expected.
import std.stdio;
void main(){
write("How many students are there? ");
int studentCount;
readf("%s", &studentCount);
write("How many teachers are there? ");
int teacherCount;
readf("%s", &teacherCount);
writeln("Got it: There are ", studentCount, " students",
" and ", teacherCount, " teachers.");
}
How many students are there? 67
How many teachers are there? 5
std.conv.ConvException@/usr/include/dmd/phobos/std/conv.d(1968):
Unexpected '5' when converting from type LockingTextReader to
type int
...
Re: foreach - premature optimization vs cultivating good habits
On Friday, 30 January 2015 at 11:55:16 UTC, Laeeth Isharc wrote: As I understand it, foreach allocates when a simple C-style for using an array index would not. foreach is just syntax sugar over a for loop. If there's any allocations, it is because your code had some, it isn't inherit to the loop. The doc definition even lists the translation of foreach to for in the case of ranges explicitly: http://dlang.org/statement.html#ForeachStatement The most likely allocation would be to a user-defined opApply delegate, and you can prevent that by making it opApply(scope your_delegate) - the scope word prevents any closure allocation.
Re: is it bug?
The real problem is if I comment my unittest out then it compiles. Why my unittest causes this behaviour?
Re: is it bug?
On Friday, 30 January 2015 at 12:32:05 UTC, drug wrote: ``` import std.container: RedBlackTree; class Manager(TT, alias Cmp = "ait fails in a RedBlackTree unittest with 2.065 and 2.066, is it bug? Reduced: import std.container: RedBlackTree; alias Container = RedBlackTree!(int, "a
Re: is it bug?
On Friday, 30 January 2015 at 13:11:35 UTC, anonymous wrote: Lines 846-850: static if(less == "a < b") auto vals = [1, 2, 3, 4, 5]; else auto vals = [5, 4, 3, 2, 1]; assert(equal(r, vals)); (Tab + Enter strikes again.) That test looks wrong. So, Phobos bug I think.
Re: is it bug?
On Friday, 30 January 2015 at 12:32:05 UTC, drug wrote:
static init()
{
auto instance = new typeof(this)();
instance._cont = new Container();
return instance;
}
have you tried
---
static typeof(this) init()
{
auto instance = new typeof(this)();
instance._cont = new Container();
return instance;
}
---
?
because currently either "void" or a type is missing.
Re: is it bug?
On 30.01.2015 16:31, BBaz wrote:
On Friday, 30 January 2015 at 12:32:05 UTC, drug wrote:
static init()
{
auto instance = new typeof(this)();
instance._cont = new Container();
return instance;
}
have you tried
---
static typeof(this) init()
{
auto instance = new typeof(this)();
instance._cont = new Container();
return instance;
}
---
?
because currently either "void" or a type is missing.
Type is inferred automatically.
Re: is it bug?
On 30.01.2015 16:14, anonymous wrote: On Friday, 30 January 2015 at 13:11:35 UTC, anonymous wrote: Lines 846-850: static if(less == "a < b") auto vals = [1, 2, 3, 4, 5]; else auto vals = [5, 4, 3, 2, 1]; assert(equal(r, vals)); (Tab + Enter strikes again.) That test looks wrong. So, Phobos bug I think. I guess it is bug in this unittest, because it fails if I set predicate less to "a
Re: is it bug?
On Friday, 30 January 2015 at 13:34:57 UTC, drug wrote:
On 30.01.2015 16:31, BBaz wrote:
On Friday, 30 January 2015 at 12:32:05 UTC, drug wrote:
static init()
{
auto instance = new typeof(this)();
instance._cont = new Container();
return instance;
}
have you tried
---
static typeof(this) init()
{
auto instance = new typeof(this)();
instance._cont = new Container();
return instance;
}
---
?
because currently either "void" or a type is missing.
Type is inferred automatically.
right, i've forgot that init() is a >>built-in<< property.
But it seemsthat i'm not the only one...
Re: is it bug?
On 30.01.2015 16:35, drug wrote: On 30.01.2015 16:14, anonymous wrote: On Friday, 30 January 2015 at 13:11:35 UTC, anonymous wrote: Lines 846-850: static if(less == "a < b") auto vals = [1, 2, 3, 4, 5]; else auto vals = [5, 4, 3, 2, 1]; assert(equal(r, vals)); (Tab + Enter strikes again.) That test looks wrong. So, Phobos bug I think. I guess it is bug in this unittest, because it fails if I set predicate less to "a Filed a bug https://issues.dlang.org/show_bug.cgi?id=14082
Re: is it bug?
On Friday, 30 January 2015 at 13:39:05 UTC, BBaz wrote:
On Friday, 30 January 2015 at 13:34:57 UTC, drug wrote:
On 30.01.2015 16:31, BBaz wrote:
On Friday, 30 January 2015 at 12:32:05 UTC, drug wrote:
static init()
{
auto instance = new typeof(this)();
instance._cont = new Container();
return instance;
}
have you tried
---
static typeof(this) init()
{
auto instance = new typeof(this)();
instance._cont = new Container();
return instance;
}
---
?
because currently either "void" or a type is missing.
Type is inferred automatically.
right, i've forgot that init() is a >>built-in<< property.
But it seemsthat i'm not the only one...
I think that doesn't matter here. Still works fine if you name it
something other than "init". I don't know if this works as
designed, or if an "auto" return type should be required.
Besides, it's a bad idea to call a member "init", because it
steals the name of the default initializer. It doesn't override
the default initializer, it just takes its name. The compiler
should not accept it, in my opinion.
Re: is it bug?
On Friday, 30 January 2015 at 13:56:17 UTC, anonymous wrote:
On Friday, 30 January 2015 at 13:39:05 UTC, BBaz wrote:
On Friday, 30 January 2015 at 13:34:57 UTC, drug wrote:
On 30.01.2015 16:31, BBaz wrote:
On Friday, 30 January 2015 at 12:32:05 UTC, drug wrote:
static init()
{
auto instance = new typeof(this)();
instance._cont = new Container();
return instance;
}
have you tried
---
static typeof(this) init()
{
auto instance = new typeof(this)();
instance._cont = new Container();
return instance;
}
---
?
because currently either "void" or a type is missing.
Type is inferred automatically.
right, i've forgot that init() is a >>built-in<< property.
But it seemsthat i'm not the only one...
I think that doesn't matter here. Still works fine if you name
it something other than "init". I don't know if this works as
designed, or if an "auto" return type should be required.
Besides, it's a bad idea to call a member "init", because it
steals the name of the default initializer. It doesn't override
the default initializer, it just takes its name. The compiler
should not accept it, in my opinion.
Yes, that was the point: "bad idea to call a member "init".
But I've missed something with inference of return type...
let's call this the "BMS" : big-mouth-syndrom...
I didn't know it could be ommitted...I thought it could be if the
function has the'@safe'attribute...
Sorry drug, BMS...
Re: is it bug?
On 30.01.2015 17:04, BBaz wrote: Yes, that was the point: "bad idea to call a member "init". But I've missed something with inference of return type... let's call this the "BMS" : big-mouth-syndrom... I didn't know it could be ommitted...I thought it could be if the function has the'@safe'attribute... static helps to infer type Sorry drug, BMS... there is nothing to sorry
Re: is it bug?
On 30.01.2015 16:56, anonymous wrote: Besides, it's a bad idea to call a member "init", because it steals the name of the default initializer. It doesn't override the default initializer, it just takes its name. The compiler should not accept it, in my opinion. Good remark! I'll rename it.
Re: Deducing a template retrun parameter type based on an assignment?
On 1/30/15 5:06 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= "
wrote:
On Friday, 30 January 2015 at 08:52:41 UTC, bearophile wrote:
Jeremy DeHaan:
I figured that it would be smart enough to
deduce the parameter type based on the type that it was trying to be
assigned to.
For that you need languages like Haskell/Rust. D type inference
doesn't work from the type something is assigned to.
But it could, right (for arguments and return expressions, too)? At
least I don't see any real obstacles. Just file an enhancement request
if you think it's worthwhile, or start a discussion on digitalmars.D.
Of course, it cannot work for `auto x = getString();` or
`foo(getString())` where there are several overloads of `foo()`. The
next step would then be overloading on the return type, which is related.
Walter made a conscious decision not to depend on return types for
overloads or any other deduction. It makes implementation of the
language simpler. C++ has tremendously complex rules for overloading
because of this.
Note, you can easily change this:
string x = getString();
to this:
auto x = getString!(char)();
which is still DRY.
One possible mechanism for working around this for when you already have
a variable is to change the return value into a parameter
void getStringParam(T)(ref T[] x) if ... { x = getString!(T)(); }
-Steve
Re: foreach - premature optimization vs cultivating good habits
On Friday, 30 January 2015 at 12:55:20 UTC, Adam D. Ruppe wrote: On Friday, 30 January 2015 at 11:55:16 UTC, Laeeth Isharc wrote: As I understand it, foreach allocates when a simple C-style for using an array index would not. foreach is just syntax sugar over a for loop. If there's any allocations, it is because your code had some, it isn't inherit to the loop. The doc definition even lists the translation of foreach to for in the case of ranges explicitly: http://dlang.org/statement.html#ForeachStatement The most likely allocation would be to a user-defined opApply delegate, and you can prevent that by making it opApply(scope your_delegate) - the scope word prevents any closure allocation. Thanks, Adam. That's what I had thought (your first paragraph), but something Ola on a different thread confused me and made me think I didn't understand it, and I wanted to pin it down. The second paragraph is very helpful - appreciate it. Laeeth.
Re: foreach - premature optimization vs cultivating good habits
On Friday, 30 January 2015 at 11:55:16 UTC, Laeeth Isharc wrote: Hi. The standard advice is not to worry about memory usage and execution speed until profiling shows you where the problem is, and I respect Knuth greatly as a thinker. Still, one may learn from others' experience and cultivate good habits early. To say that one should not prematurely optimize is not to say that one should not try to avoid cases that tend to be really bad, and I would rather learn from others what these are then learn only the hard way. For the time being I am still at early development stage and have not yet tested things with the larger data sets I anticipate eventually using. It's cheap to make slightly different design decisions early, but much more painful further down the line, particularly given my context. As I understand it, foreach allocates when a simple C-style for using an array index would not. I would like to learn more about when this turns particularly expensive, and perhaps I could put this up on the wiki if people think it is a good idea. What exactly does it allocate, and how often, and how large is this in relation to the size of the underlying data (structs/classes/ranges)? Are there any cache effects to consider? Happy to go to the source code if you can give me some pointers. Thanks in advice for any thoughts. Laeeth. I think you're thinking of java's foreach syntax, which IIRC does cause allocations.
Re: Input error with readf()
On 01/30/2015 04:49 AM, Paul wrote:
> If I run the following example program from the 'Programming in
> D' book, the input doesn't 'get stuck' as stated in the book but
> instead produces the error message given. Have things changed
> since that part of the book was written or is it some other
> issue?
Apparently, things did change since then. I will change the text
accordingly. I would like to add you to the acknowledgments section if
you email your full name to acehr...@yahoo.com. Thank you...
> The version that uses " %s" in the call to readf works as
> expected.
>
>
> import std.stdio;
>
> void main(){
>
> write("How many students are there? ");
> int studentCount;
> readf("%s", &studentCount);
> write("How many teachers are there? ");
> int teacherCount;
> readf("%s", &teacherCount);
>
> writeln("Got it: There are ", studentCount, " students",
> " and ", teacherCount, " teachers.");
> }
>
> How many students are there? 67
> How many teachers are there? 5
> std.conv.ConvException@/usr/include/dmd/phobos/std/conv.d(1968):
> Unexpected '5' when converting from type LockingTextReader to
> type int
> ...
Not the best error message... Saying '5' is unexpected for 'int' is
confusing, right? Unfortunately, I can't come up with a good explanation
for that error message in the book. :)
Ali
Re: class is forward referenced when looking for 'v'
On Friday, 30 January 2015 at 00:09:17 UTC, Amber Thralll wrote:
And the errors dmd returns:
test.d(16): Error: class test.A!int.A is forward referenced
when looking for 'v'
test.d(16): Error: class test.A!int.A is forward referenced
when looking for 'opDot'
test.d(16): Error: class test.A!int.A is forward referenced
when looking for 'opDispatch'
test.d(29): Error: no property 'v' for type 'test.A!int.A'
test.d(10): Error: template instance test.B!int error
instantiating
test.d(16):instantiated from here: Base!int
test.d(35):instantiated from here: A!int
Is this a bug in D? Or am I doing something wrong?
In D, forward reference resolution should have consistent result
for template classes and non-template ones. If the code is
rewritten to non-template version:
import std.stdio;
class Base
{
public void Foo(A a)
{
writeln("Base.Foo(A a)");
}
public void Foo(B a)
{
writeln("Base.Foo(B a)");
}
};
class A : Base
{
public int v;
this(int v)
{
this.v = v;
}
}
class B : Base
{
public override void Foo(A a)
{
writeln("A: ", a.v);
}
}
int main()
{
A a = new A(1);
B b = new B();
a.Foo(b);
b.Foo(a);
return 0;
}
Compiler properly resolves forward references. Therefore, it's
definitely a compiler bug, and the template version should be
accepted.
I filed the issue in bugzilla:
https://issues.dlang.org/show_bug.cgi?id=14083
And will open a new pull request to fix compiler.
Kenji Hara
Re: Input error with readf()
On Friday, 30 January 2015 at 15:03:55 UTC, Ali Çehreli wrote: Not the best error message... Saying '5' is unexpected for 'int' is confusing, right? Unfortunately, I can't come up with a good explanation for that error message in the book. :) Maybe just remove the section with the 'incorrect' syntax? The reader will have to take it as read that " %s" is the correct form :D
std.algorithm sort() and reverse() confusion
Given that myVals is a dynamic array of ints...
writeln("Array contents: ", myVals);
writeln("Sorted: ", sort(myVals));
writeln("Sorted, reversed: ", reverse(myVals));
Gives me...
Error: template std.stdio.writeln cannot deduce function from
argument types !()(string, void)
But, if I bring the reverse out of the call to writeln() it works
as expected:
writeln("Array contents: ", myVals);
writeln("Sorted: ", sort(myVals));
reverse(myVals);
writeln("Sorted, reversed: ", myVals);
Can someone give me a simple explanation as to why this is so? I
guess it might be because reverse is 'in place' and the target is
undefined at compile time but surely that would still be the case
in the second instance. Somehow it doesn't seem logical to a noob
like me.
Re: std.algorithm sort() and reverse() confusion
writeln("Sorted, reversed: ", retro(sort(myVals)));
?
Re: class is forward referenced when looking for 'v'
class Base
{
public void Foo(A a)
{
writeln("Base.Foo(A a)");
}
public void Foo(B a)
{
writeln("Base.Foo(B a)");
}
};
Compiler properly resolves forward references. Therefore, it's
definitely a compiler bug, and the template version should be
accepted.
I filed the issue in bugzilla:
https://issues.dlang.org/show_bug.cgi?id=14083
And will open a new pull request to fix compiler.
Kenji Hara
In the mean time I've found removing the overridden methods from
the Base class, works with templates.
Re: std.algorithm sort() and reverse() confusion
On Friday, 30 January 2015 at 16:21:24 UTC, Kagamin wrote:
writeln("Sorted, reversed: ", retro(sort(myVals)));
?
Or...
writeln("Reverse sorted: ", sort!("a > b")(vals));
but I still don't understand the original 'error'.
Re: std.algorithm sort() and reverse() confusion
On Friday, 30 January 2015 at 17:07:17 UTC, Paul wrote:
On Friday, 30 January 2015 at 16:21:24 UTC, Kagamin wrote:
writeln("Sorted, reversed: ", retro(sort(myVals)));
?
Or...
writeln("Reverse sorted: ", sort!("a > b")(vals));
but I still don't understand the original 'error'.
Take a look at the return type of reverse.
Re: std.algorithm sort() and reverse() confusion
On 2015-01-30 at 17:07, Paul wrote:
writeln("Sorted, reversed: ", reverse(myVals));
Gives me...
Error: template std.stdio.writeln cannot deduce function from argument types
!()(string, void)
As it should, because reverse returns nothing, void.
But you may wonder what the design choice behind that was that reverse doesn't
return the range itself while sort does (a SortedRange, specifically).
Re: Thread.sleep( dur!("msecs")( 50 ) ); // sleep for 50 milliseconds
On Friday, January 30, 2015 12:30:35 FG via Digitalmars-d-learn wrote: > On 2015-01-30 at 12:08, Vladimir Panteleev wrote: > > On Friday, 30 January 2015 at 11:04:47 UTC, FG wrote: > >> Bug or correct behaviour? > > > > Bug: https://issues.dlang.org/show_bug.cgi?id=1238 > > https://github.com/D-Programming-Language/dmd/pull/3743 > > The fix is pretty much a one-liner. > Probably 2.067 will already include it, right? Last I heard, no one had been able to convince Walter that private symbols should be hidden. They aren't in C++, but C++ doesn't have access levels for anything other than classes, so the effect is _very_ different. Though maybe someone convinced Walter that the status quo is stupid, and I didn't see it. I don't know. Pretty much everyone else thinks that it should be changed, so it'll probably be changed at some point, but who knows when. The fact that there's a PR for it will help, but it obviously isn't being dealt with particularly quickly, so there's really no way to know when it'll be merged (and it doesn't even fix the whole problem with private symbols - just some of it). It could be merged tomorrow, or it could be months from now. - Jonathan M Davis
Re: std.algorithm sort() and reverse() confusion
On 2015-01-30 at 18:42, FG wrote: But you may wonder what the design choice behind that was that reverse doesn't return the range itself while sort does (a SortedRange, specifically). Although, after thinking about it, it makes sense. sort is used mostly to enforce that something is sorted in case it isn't already, so chaining it with other functions is reasonable, while in case of reverse you don't normally call it very often, it's cheaper to wrap the range in a retro range and iterate backwards when required, without touching the original.
Re: std.algorithm sort() and reverse() confusion
On Friday, January 30, 2015 18:42:57 FG via Digitalmars-d-learn wrote:
> On 2015-01-30 at 17:07, Paul wrote:
> > writeln("Sorted, reversed: ", reverse(myVals));
> >
> > Gives me...
> >
> > Error: template std.stdio.writeln cannot deduce function from argument
> > types !()(string, void)
>
> As it should, because reverse returns nothing, void.
> But you may wonder what the design choice behind that was that reverse
> doesn't return the range itself while sort does (a SortedRange, specifically).
sort returns a different type rather than the original type, and that type
indicates that its sorted, and some algoritms are able to take advantage of
that. No algorithm is going to care that the data was reversed at some
point, so there's no benefit it returning a new range type from reverse. And
it's arguably better that a function that mutates something in place does
not return it - especially with ranges - because that very easily gives the
impression that the original is not mutated (since most range-based
functions don't alter their arguments - they just wrap them in a new range
type or return a portion of the original range).
Regardless, I think that the difference between sort and reverse comes down
to the fact that there's a definite benefit in returning a new type from
sort, whereas there is no such benefit with reverse, so there's no need to
return anything. So, whether it _should_ return anything is then a very
different question than it is with sort.
- Jonathan M Davis
Re: std.algorithm sort() and reverse() confusion
On 01/30/2015 09:55 AM, Jonathan M Davis via Digitalmars-d-learn wrote: > sort returns a different type rather than the original type, and that type > indicates that its sorted, and some algoritms are able to take advantage of > that. I covered that a little bit during DConf 2014, at around 4:30 minute mark here: http://www.youtube.com/watch?x-yt-cl=85114404&v=oF8K4-bieaw&feature=player_detailpage&x-yt-ts=1422579428#t=267 > there is no such benefit with reverse, so there's no need to > return anything. Still, returning the original range would help with chaining calls: arr.reverse.map!sqrt Side note: There is the confusion between the .reverse property of arrays and std.algorithm.reverse. :-/ Ali
Class inside a Struct?
Hello everyone,
I am currently learning D by coding a project, but I encountered
a problem with one of my structures. I managed to reduce the code
to the minimum:
import std.stdio;
import std.container.rbtree;
struct Container {
private RedBlackTree!int _rbtree = new RedBlackTree!int;
void add (int elt) {
_rbtree.insert(elt);
}
void print () {
if (_rbtree.empty) {
writeln("empty");
} else {
foreach (l; _rbtree) {
write(l, " ");
}
writeln();
}
}
}
int main () {
Container c1, c2;
c1.add(1);
c1.print();
c2.print();
return 0;
}
I don't understand why the output of this program is:
1
1
I expect it to be:
1
empty
I thank you in advance for your help!
Re: std.algorithm sort() and reverse() confusion
On Friday, 30 January 2015 at 18:46:55 UTC, Ali Çehreli wrote: > there is no such benefit with reverse, so there's no need to > return anything. Still, returning the original range would help with chaining calls: arr.reverse.map!sqrt Side note: There is the confusion between the .reverse property of arrays and std.algorithm.reverse. :-/ Ali Thanks all, I now understand why this happens, although as a newcomer, it seems a little odd that these 'utility functions' have to be handled differently. Paul
Re: Thread.sleep( dur!("msecs")( 50 ) ); // sleep for 50 milliseconds
On 1/30/15 12:49 PM, Jonathan M Davis via Digitalmars-d-learn wrote: On Friday, January 30, 2015 12:30:35 FG via Digitalmars-d-learn wrote: On 2015-01-30 at 12:08, Vladimir Panteleev wrote: On Friday, 30 January 2015 at 11:04:47 UTC, FG wrote: Bug or correct behaviour? Bug: https://issues.dlang.org/show_bug.cgi?id=1238 https://github.com/D-Programming-Language/dmd/pull/3743 The fix is pretty much a one-liner. Probably 2.067 will already include it, right? Last I heard, no one had been able to convince Walter that private symbols should be hidden. They aren't in C++, but C++ doesn't have access levels for anything other than classes, so the effect is _very_ different. Another HUGE difference is that C++ generally splits API from implementation. When you import .h files, you don't also import private symbols which may be defined or used in the .cpp file. D absolutely needs a way to say "this is ONLY for implementation, it's not part of the API." private fits this bill EXACTLY. Please do it. -Steve
how to build dlang.org docs
This question is for people who have experience building the website and/or documentation. It's not about the D language per se. Here's a link to my work in progress: https://github.com/zachthemystic/dlang.org/compare/starting The advice here: https://github.com/D-Programming-Language/dlang.org/blob/master/CONTRIBUTING.md ...says to use `make -f posix.mak apidocs-prerelease` to build them. This worked to begin with, but after changing my files, I'm hoping to see my new pages pop up in `$R/dlang.org/web/library-prerelease` when I make them again. Does anyone know what command or edit can rebuild with my new page? Thanks.
How to make a Currency class from std.BigInt?
module axfinance.api.currencies;
import std.array, std.stdio, std.system, std.bigint, std.conv;
class Currencies
{
public:
this(ulong pf)
{
exponent(pf);
}
bool integer(BigInt pb)
{
zInt = pb;
return true;
}
string value()
{
string res = to!string(zInt);
insertInPlace(res, res.length - zExp,".");
return res;
}
private:
bool exponent(ulong pe)
{
zExp = pe;
return true;
}
BigInt zInt;
ulong zExp;
}
unittest
{
double d1 = 45.67;
immutable LIM_FIAT = 2, LIM_EXCH = 6, LIM_CRYP = 8;
auto c = [ "BTC":["N-01":new Currencies(LIM_CRYP), "N-02":new
Currencies(LIM_CRYP), "SUM1":new Currencies(LIM_CRYP)],
"CNY":["N-01":new Currencies(LIM_FIAT), "N-02":new
Currencies(LIM_EXCH), "N-03":new Currencies(LIM_CRYP), "SUM1":new
Currencies(LIM_CRYP), "SUM2":new Currencies(LIM_CRYP)]];
// EUR, LTC, RUB;
c["BTC"]["N-01"] = 1.0002;//Error: cannot implicitly convert
expression (1) of type double to
axfinance.api.currencies.Currencies
c["BTC"]["N-02"] = 15.0002+"13455565.45665435";
c["BTC"]["SUM1"] = c["BTC"]["N-01"] + c["BTC"]["N-02"];
assert(c["BTC"]["SUM1"] == "13455581.45665437");
c["CNY"]["N-01"] = 1.02;
c["CNY"]["N-02"] = "0.01";
c["CNY"]["N-03"] = "0.0001";
c["CNY"]["SUM1"] = c["CNY"]["N-01"] + c["CNY"]["N-02"];
assert(c["CNY"]["SUM1"] == "1.03");
assert(to!double(c["CNY"]["SUM1"]) == 1.03);
c["CNY"]["SUM2"] = c["CNY"]["N-01"] + c["CNY"]["N-03"];
assert(c["CNY"]["SUM2"] == "1.0201");
}
Re: Class inside a Struct?
On 01/30/2015 11:59 AM, chardetm wrote:
> struct Container {
>
> private RedBlackTree!int _rbtree = new RedBlackTree!int;
I think you are expecting the new expression to be be executed for every
object individually. It is not the case: That new expression determines
the initial value of the _rbtree for every single object of type
Container. As a result, they will all be sharing the same tree.
The best solution is
1) Remove the new expression:
private RedBlackTree!int _rbtree;
2) Use a static opCall:
private RedBlackTree!int _rbtree;
static Container opCall()
{
Container container;
container._rbtree = new RedBlackTree!int;
return container;
}
3) And then initialize the variables with the following syntax:
auto c1 = Container();
auto c2 = Container();
Importantly, do not use the following syntax:
Container c1;// Warning: c1._rbttree is null
So the safe solution is (used to be?) to disable the default constructor:
@disable this();
However, the compilation fails with the following error message:
Error: struct deneme.Container static opCall is hidden by constructors
and can never be called
That looks like a bug to me because I am explicitly disabling the
default constructor. Right?
In any case, an alternative solution is not to use opCall() but do what
the first part of the second part of the same error message recommends:
Please use a factory method instead, or replace all constructors with
static opCall.
Yes, you can have factory method that returns a Container object. The
whole program with that second method:
import std.stdio;
import std.container.rbtree;
struct Container {
private RedBlackTree!int _rbtree;
@disable this(); // <-- disabled
this(RedBlackTree!int rbtree) // <-- good practice
// ("parameterize from above")
{
_rbtree = rbtree;
}
void add (int elt) {
_rbtree.insert(elt);
}
void print () {
if (_rbtree.empty) {
writeln("empty");
} else {
foreach (l; _rbtree) {
write(l, " ");
}
writeln();
}
}
}
Container makeContainer() // <-- factory method
{
return Container(new RedBlackTree!int);
}
int main () {
auto c1 = makeContainer();
auto c2 = makeContainer();
c1.add(1);
c1.print();
c2.print();
return 0;
}
Ali
Re: How to make a Currency class from std.BigInt?
What do I need to learn?
Re: How to make a Currency class from std.BigInt?
On Friday, 30 January 2015 at 20:34:53 UTC, RuZzz wrote: What do I need to learn? c["BTC"]["N-01"] = 1.0002;//Error: cannot implicitly convert expression (1) of type double to axfinance.api.currencies.Currencies As I see it, there is no constructor in your class with a double argument. So you cannot assign a double (1.0002) to a Currencies struct (c["BTC"]["N-01"]).
Re: Class inside a Struct?
Thanks a lot Ali, now it works perfectly! It is quite hard to get used to D's logic, I have to stop thinking in terms of C++... Anyway, thanks again!
Re: std.algorithm sort() and reverse() confusion
On Friday, January 30, 2015 10:46:54 Ali Çehreli via Digitalmars-d-learn wrote: > On 01/30/2015 09:55 AM, Jonathan M Davis via Digitalmars-d-learn wrote: > > there is no such benefit with reverse, so there's no need to > > return anything. > > Still, returning the original range would help with chaining calls: > >arr.reverse.map!sqrt Yes, but arguably, chaining calls in this case is bad, because normally when you're chaining calls with range-based functions, you're not mutating the original range, whereas with reverse, you are. So, it could easily give the impression that it's doing what retro does rather than reversing the elements in place. - Jonathan M Davis
Re: Class inside a Struct?
On 1/30/15 5:28 PM, Ali Çehreli wrote:
On 01/30/2015 11:59 AM, chardetm wrote:
> struct Container {
>
> private RedBlackTree!int _rbtree = new RedBlackTree!int;
I think you are expecting the new expression to be be executed for every
object individually. It is not the case: That new expression determines
the initial value of the _rbtree for every single object of type
Container. As a result, they will all be sharing the same tree.
The best solution is
1) Remove the new expression:
2) Use a static opCall:
Why not use this() ?
Re: how to build dlang.org docs
On Friday, 30 January 2015 at 20:28:56 UTC, Zach the Mystic wrote: This question is for people who have experience building the website and/or documentation. It's not about the D language per se. Here's a link to my work in progress: https://github.com/zachthemystic/dlang.org/compare/starting The advice here: https://github.com/D-Programming-Language/dlang.org/blob/master/CONTRIBUTING.md ...says to use `make -f posix.mak apidocs-prerelease` to build them. This worked to begin with, but after changing my files, I'm hoping to see my new pages pop up in `$R/dlang.org/web/library-prerelease` when I make them again. Does anyone know what command or edit can rebuild with my new page? Thanks. I figured it out... just took some time.
Time from timestamp?
I'm attempting to print a human-readable version of a timestamp.
The timestamp is coming from an external service, via JSON. An
example is:
1421865781342
Which I know to be:
2015-01-21T18:43:01.342Z
The only method I see which takes an epoch-style timestamp, so
that I can convert it to something printable, is the SysTime
constructor:
pure nothrow @safe this(long stdTime, immutable TimeZone tz =
null);
According to the reference, this seems to take the value in
hnsecs. My expectation would be that this means multiplying my
initial value by 1_000_000. But if I do that, I get a random date
2500 years in the future.
I created this sample code:
void main() {
long time = 1421865781342L;
writefln("%s", SysTime(time));
writefln("%s", SysTime(time * 10L));
writefln("%s", SysTime(time * 100L));
writefln("%s", SysTime(time * 1_000L));
writefln("%s", SysTime(time * 10_000L));
writefln("%s", SysTime(time * 100_000L));
writefln("%s", SysTime(time * 1_000_000L));
writefln("%s", Clock.currTime.stdTime);
}
Outputs:
0001-Jan-02 07:36:48.5781342
0001-Jan-17 03:04:47.781342
0001-Jun-14 05:44:39.81342
0005-Jul-04 08:23:20.1342
0046-Jan-21 10:50:03.342
0451-Jul-28 11:17:15.42
4506-Sep-18 16:42:14.2
635582516
My expectation would be that the final line would be something
beginning with "14" at least. Playing around with possible
multipliers, there doesn't even seem to be any integer value that
would allow conversion between the timestamp I received and
whatever SysTime expects.
I'm using:
DMD64 D Compiler v2.066.1
Ubuntu from .deb package
Is this a bug, or am I doing something wrong?
Re: Time from timestamp?
On 31/01/2015 11:18 a.m., Chris Williams wrote:
I'm attempting to print a human-readable version of a timestamp. The
timestamp is coming from an external service, via JSON. An example is:
1421865781342
Which I know to be:
2015-01-21T18:43:01.342Z
The only method I see which takes an epoch-style timestamp, so that I
can convert it to something printable, is the SysTime constructor:
pure nothrow @safe this(long stdTime, immutable TimeZone tz = null);
According to the reference, this seems to take the value in hnsecs. My
expectation would be that this means multiplying my initial value by
1_000_000. But if I do that, I get a random date 2500 years in the future.
I created this sample code:
void main() {
long time = 1421865781342L;
writefln("%s", SysTime(time));
writefln("%s", SysTime(time * 10L));
writefln("%s", SysTime(time * 100L));
writefln("%s", SysTime(time * 1_000L));
writefln("%s", SysTime(time * 10_000L));
writefln("%s", SysTime(time * 100_000L));
writefln("%s", SysTime(time * 1_000_000L));
writefln("%s", Clock.currTime.stdTime);
}
Outputs:
0001-Jan-02 07:36:48.5781342
0001-Jan-17 03:04:47.781342
0001-Jun-14 05:44:39.81342
0005-Jul-04 08:23:20.1342
0046-Jan-21 10:50:03.342
0451-Jul-28 11:17:15.42
4506-Sep-18 16:42:14.2
635582516
My expectation would be that the final line would be something beginning
with "14" at least. Playing around with possible multipliers, there
doesn't even seem to be any integer value that would allow conversion
between the timestamp I received and whatever SysTime expects.
I'm using:
DMD64 D Compiler v2.066.1
Ubuntu from .deb package
Is this a bug, or am I doing something wrong?
On a slightly related note, I have code for UTC+0 to unix time stamp.
https://github.com/Devisualization/util/blob/b9ab5758e755c4e33832ac4aed0a5d7f2c728faf/source/core/devisualization/util/core/time.d
Re: Class inside a Struct?
On 01/30/2015 01:28 PM, Ary Borenszweig wrote:
> On 1/30/15 5:28 PM, Ali Çehreli wrote:
>> On 01/30/2015 11:59 AM, chardetm wrote:
>>
>> > struct Container {
>> >
>> > private RedBlackTree!int _rbtree = new RedBlackTree!int;
>>
>> I think you are expecting the new expression to be be executed for every
>> object individually. It is not the case: That new expression determines
>> the initial value of the _rbtree for every single object of type
>> Container. As a result, they will all be sharing the same tree.
>>
>> The best solution is
>>
>> 1) Remove the new expression:
>> 2) Use a static opCall:
>
> Why not use this() ?
In fact, I think a better solution is to use a constructor that takes
the tree:
this(RedBlackTree!int rbtree) // <-- good practice
// ("parameterize from above")
{
_rbtree = rbtree;
}
However, I thought that OP did not want the users know about that
member. So, as you say, the next option that comes to mind is to use the
default constructor:
this()
{
_rbtree = new RedBlackTree!int;
}
Unfortunately, D does not allow defining the default constructor for
structs:
Error: constructor deneme.Container.this default constructor for structs
only allowed with @disable and no body
The reason is, the default constructor happens to be the .init value of
that type and it must be known at compile time.
Ali
Re: Time from timestamp?
On Friday, 30 January 2015 at 22:22:27 UTC, Rikki Cattermole wrote: On a slightly related note, I have code for UTC+0 to unix time stamp. https://github.com/Devisualization/util/blob/b9ab5758e755c4e33832ac4aed0a5d7f2c728faf/source/core/devisualization/util/core/time.d Unix timestamps can be negative, so you should probably be using longs instead of ulongs.
Should '@disable this()' disable 'static opCall()'?
I am thinking about opening a bug with the following code:
struct S
{
@disable this();
static void opCall()
{}
}
void main()
{}
Error: struct deneme.S static opCall is hidden by constructors and can
never be called
Which seems to be due to the following change:
https://github.com/D-Programming-Language/dmd/commit/79ae211e71cf0937523010e39f7f0981e9550904
What do you think?
Ali
Re: Time from timestamp?
On Fri, 30 Jan 2015 22:38:20 +, Chris Williams wrote: > Unix timestamps can be negative WUT?! O_O signature.asc Description: PGP signature
Re: Thread.sleep( dur!("msecs")( 50 ) ); // sleep for 50 milliseconds
On Fri, 30 Jan 2015 15:26:11 -0500, Steven Schveighoffer wrote: > D absolutely needs a way to say "this is ONLY for implementation, it's > not part of the API." private fits this bill EXACTLY. yep. every sane person recognizing D private symbols as "hidden". and then... BOOM! The Hidden Gems Of D. signature.asc Description: PGP signature
Re: Time from timestamp?
On 31/01/2015 12:06 p.m., ketmar wrote: On Fri, 30 Jan 2015 22:38:20 +, Chris Williams wrote: Unix timestamps can be negative WUT?! O_O Looks like we are both thinking the usual case. The standard Unix time_t (data type representing a point in time) is a signed integer data type, traditionally of 32 bits (but see below), directly encoding the Unix time number as described in the preceding section. Being 32 bits means that it covers a range of about 136 years in total. The minimum representable time is 1901-12-13, and the maximum representable time is 2038-01-19. The second after 03:14:07 UTC 2038-01-19 this representation overflows. This milestone is anticipated with a mixture of amusement and dread; see year 2038 problem. From wikipedia. https://github.com/D-Programming-Language/druntime/blob/master/src/core/stdc/time.d#L68 Looks like I got to modify it.
BitArray crash
Hi,
I'm trying to use BitArray instead of rolling my own. But how
does one use it?
I tried:
import std.bitmanip : BitArray;
int main() {
BitArray b;
b[2] = true;
return 0;
}
$ gdc l.d
$ gdb a.out
(gdb) r
Program received signal SIGSEGV, Segmentation fault.
0x00438f88 in std.bitmanip.BitArray.opIndexAssign()
(this=..., b=true,
i=2) at ../../../../src/libphobos/src/std/bitmanip.d:604
Huh?
(gdc-4.8 (Ubuntu 4.8.2-19ubuntu1) 4.8.2)
I think I have to set "length" first. At least an example at the
docs of bitsSet() halfway down the page does it...
Re: Should '@disable this()' disable 'static opCall()'?
On Friday, 30 January 2015 at 22:41:35 UTC, Ali Çehreli wrote:
I am thinking about opening a bug with the following code:
struct S
{
@disable this();
static void opCall()
{}
}
void main()
{}
Error: struct deneme.S static opCall is hidden by constructors
and can never be called
Which seems to be due to the following change:
https://github.com/D-Programming-Language/dmd/commit/79ae211e71cf0937523010e39f7f0981e9550904
What do you think?
Ali
It should only be an error when static opCall() cant be
distinguishable from this.
---
struct S
{
@disable this();
static string opCall(){return "yo mister White";}
}
void main()
{}
---
is distinguishable (by return type) but cant be compiled.
You're right there's a problem.
Re: Time from timestamp?
On Friday, 30 January 2015 at 22:38:21 UTC, Chris Williams wrote: On Friday, 30 January 2015 at 22:22:27 UTC, Rikki Cattermole wrote: On a slightly related note, I have code for UTC+0 to unix time stamp. https://github.com/Devisualization/util/blob/b9ab5758e755c4e33832ac4aed0a5d7f2c728faf/source/core/devisualization/util/core/time.d Unix timestamps can be negative, so you should probably be using longs instead of ulongs. Yup, there was a world before January 1st, 1970.
Re: Time from timestamp?
On Sat, 31 Jan 2015 12:12:08 +1300, Rikki Cattermole wrote: > On 31/01/2015 12:06 p.m., ketmar wrote: >> On Fri, 30 Jan 2015 22:38:20 +, Chris Williams wrote: >> >>> Unix timestamps can be negative >> WUT?! O_O > > Looks like we are both thinking the usual case. > > The standard Unix time_t (data type representing a point in time) is a > signed integer data type, traditionally of 32 bits (but see below), > directly encoding the Unix time number as described in the preceding > section. Being 32 bits means that it covers a range of about 136 years > in total. The minimum representable time is 1901-12-13, and the maximum > representable time is 2038-01-19. The second after 03:14:07 UTC > 2038-01-19 this representation overflows. This milestone is anticipated > with a mixture of amusement and dread; see year 2038 problem. > > From wikipedia. > > https://github.com/D-Programming-Language/druntime/blob/master/src/core/ stdc/time.d#L68 > > Looks like I got to modify it. nobody ever planned "negative timestamps". using signed time_t was just a design error (nobody cares at the time). unix timestamps are timestamps for things created in unix. i can't imagine how you can create something BEFORE the unix itself (hence 1970 as a starting point -- with some gap to allow older files). there is no such thing as "negative timestamp", any negative timestamp is a bug. signature.asc Description: PGP signature
Re: Time from timestamp?
On Fri, 30 Jan 2015 23:42:04 +, Chris Williams wrote: > On Friday, 30 January 2015 at 22:38:21 UTC, Chris Williams wrote: >> On Friday, 30 January 2015 at 22:22:27 UTC, Rikki Cattermole wrote: >>> On a slightly related note, I have code for UTC+0 to unix time stamp. >>> https://github.com/Devisualization/util/blob/ b9ab5758e755c4e33832ac4aed0a5d7f2c728faf/source/core/devisualization/util/ core/time.d >> >> Unix timestamps can be negative, so you should probably be using longs >> instead of ulongs. > > Yup, there was a world before January 1st, 1970. not for unix timestamps. please, stop that, unix timestamp was not designed to present any dates before 1970. "negative timestamp" is a bug in code. signature.asc Description: PGP signature
Re: Should '@disable this()' disable 'static opCall()'?
On 01/30/2015 03:19 PM, BBaz wrote:
> It should only be an error when static opCall() cant be distinguishable
> from this.
>
> ---
> struct S
> {
> @disable this();
> static string opCall(){return "yo mister White";}
> }
> void main()
> {}
> ---
>
> is distinguishable (by return type) but cant be compiled.
I agree that this is a problem but return types are not parts of
function signatures; so return types do not help "distinguish"
functions. Besides, constructors don't have return types; so it is a
little bit of a stretch to compare them to functions. :)
> You're right there's a problem.
Thank you. Filed:
https://issues.dlang.org/show_bug.cgi?id=14087
Ali
Re: Time from timestamp?
On Friday, 30 January 2015 at 23:50:53 UTC, ketmar wrote: On Fri, 30 Jan 2015 23:42:04 +, Chris Williams wrote: On Friday, 30 January 2015 at 22:38:21 UTC, Chris Williams wrote: On Friday, 30 January 2015 at 22:22:27 UTC, Rikki Cattermole wrote: On a slightly related note, I have code for UTC+0 to unix time stamp. https://github.com/Devisualization/util/blob/ b9ab5758e755c4e33832ac4aed0a5d7f2c728faf/source/core/devisualization/util/ core/time.d Unix timestamps can be negative, so you should probably be using longs instead of ulongs. Yup, there was a world before January 1st, 1970. not for unix timestamps. please, stop that, unix timestamp was not designed to present any dates before 1970. "negative timestamp" is a bug in code. Unless you know something I don't, everything I've ever read says that a negative unix timestamp is meant to refer to a time before 1970. It may not have been intentional, but since most database software probably stores birthdates (many of which are pre-1970) in this format, having a library be unable to support them just makes the library useless for many situations.
Re: Time from timestamp?
On 1/30/15 5:18 PM, Chris Williams wrote:
I'm attempting to print a human-readable version of a timestamp. The
timestamp is coming from an external service, via JSON. An example is:
1421865781342
Which I know to be:
2015-01-21T18:43:01.342Z
http://dlang.org/phobos/std_datetime.html#.unixTimeToStdTime
It's kind of convoluted because there is no epoch, but you can make one:
import std.datetime;
import std.stdio;
void main(string[] args)
{
// can't make this enum because of time zone...
auto epoch = SysTime(unixTimeToStdTime(0), UTC());
writeln(epoch + 1_421_865_781_342.msecs);
}
output:
2015-Jan-21 18:43:01.342Z
Note the reason your code didn't work is because SysTime uses 1/1/1 as
the epoch.
-Steve
Re: Time from timestamp?
On Saturday, 31 January 2015 at 00:20:07 UTC, ketmar wrote: On Sat, 31 Jan 2015 00:03:43 +, Chris Williams wrote: since most database software probably stores birthdates (many of which are pre-1970) in this format O_O a perfectly broken software. And stdc: http://h50146.www5.hp.com/products/software/oe/tru64unix/manual/v51a_ref/HTML/MAN/MAN3/3955.HTM And UNIX: http://www.lehman.cuny.edu/cgi-bin/man-cgi?mktime+3
Re: Time from timestamp?
On Sat, 31 Jan 2015 00:03:43 +, Chris Williams wrote: > since most database software probably > stores birthdates (many of which are pre-1970) in this format O_O a perfectly broken software. signature.asc Description: PGP signature
Re: Should '@disable this()' disable 'static opCall()'?
"distinguish" Yes, I know this a strange word. But it seems to be a valid one: http://www.collinsdictionary.com/dictionary/english/distinguish?showCookiePolicy=true "distinguishable" is ok as well.
Re: Should '@disable this()' disable 'static opCall()'?
On 01/30/2015 04:30 PM, BBaz wrote: "distinguish" Yes, I know this a strange word. But it seems to be a valid one: http://www.collinsdictionary.com/dictionary/english/distinguish?showCookiePolicy=true "distinguishable" is ok as well. Sorry, I did not mean to emphasize "distinguish" over "distinguishable". I was quoting you as although I understood what you said, I am not used to hearing that word used in function matching. However, "match" does appear in the spec: :) http://dlang.org/function.html#function-overloading Ali
Re: Class inside a Struct?
On 1/30/15 7:29 PM, Ali Çehreli wrote:
On 01/30/2015 01:28 PM, Ary Borenszweig wrote:
> On 1/30/15 5:28 PM, Ali Çehreli wrote:
>> On 01/30/2015 11:59 AM, chardetm wrote:
>>
>> > struct Container {
>> >
>> > private RedBlackTree!int _rbtree = new RedBlackTree!int;
>>
>> I think you are expecting the new expression to be be executed for
every
>> object individually. It is not the case: That new expression determines
>> the initial value of the _rbtree for every single object of type
>> Container. As a result, they will all be sharing the same tree.
>>
>> The best solution is
>>
>> 1) Remove the new expression:
>> 2) Use a static opCall:
>
> Why not use this() ?
In fact, I think a better solution is to use a constructor that takes
the tree:
this(RedBlackTree!int rbtree) // <-- good practice
// ("parameterize from above")
{
_rbtree = rbtree;
}
However, I thought that OP did not want the users know about that
member. So, as you say, the next option that comes to mind is to use the
default constructor:
this()
{
_rbtree = new RedBlackTree!int;
}
Unfortunately, D does not allow defining the default constructor for
structs:
Error: constructor deneme.Container.this default constructor for structs
only allowed with @disable and no body
The reason is, the default constructor happens to be the .init value of
that type and it must be known at compile time.
Ali
Thanks for explanation. I was sure there was some reason why you didn't
suggest it. It's an unfortunate inconsistency, I think. I don't know why
`.init` is so important or why the default value of a type has any
importance at all.
Re: BitArray crash
I think I have to set "length" first.
Yes.
Declaring
BitArray b;
is like declaring
int[] a; // ={.length = 0, . ptr = null}
you get the segfault for invalid dereference.
Re: Time from timestamp?
On Saturday, 31 January 2015 at 00:14:37 UTC, Steven
Schveighoffer wrote:
On 1/30/15 5:18 PM, Chris Williams wrote:
I'm attempting to print a human-readable version of a
timestamp. The
timestamp is coming from an external service, via JSON. An
example is:
1421865781342
Which I know to be:
2015-01-21T18:43:01.342Z
http://dlang.org/phobos/std_datetime.html#.unixTimeToStdTime
It's kind of convoluted because there is no epoch, but you can
make one:
import std.datetime;
import std.stdio;
void main(string[] args)
{
// can't make this enum because of time zone...
auto epoch = SysTime(unixTimeToStdTime(0), UTC());
writeln(epoch + 1_421_865_781_342.msecs);
}
output:
2015-Jan-21 18:43:01.342Z
Note the reason your code didn't work is because SysTime uses
1/1/1 as the epoch.
-Steve
D'oh, I missed that in the description:
"and convert it to hnsecs in UTC since midnight, January 1st, 1
A.D. UTC"
That does explain it. I also didn't spot the declaration of
unixTimeToStdTime(), which assuredly helps.
Thank you!
Re: Time from timestamp?
On Friday, January 30, 2015 19:14:37 Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 1/30/15 5:18 PM, Chris Williams wrote:
> > I'm attempting to print a human-readable version of a timestamp. The
> > timestamp is coming from an external service, via JSON. An example is:
> >
> > 1421865781342
> >
> > Which I know to be:
> >
> > 2015-01-21T18:43:01.342Z
> >
>
> http://dlang.org/phobos/std_datetime.html#.unixTimeToStdTime
>
> It's kind of convoluted because there is no epoch, but you can make one:
>
> import std.datetime;
> import std.stdio;
>
> void main(string[] args)
> {
> // can't make this enum because of time zone...
> auto epoch = SysTime(unixTimeToStdTime(0), UTC());
> writeln(epoch + 1_421_865_781_342.msecs);
> }
>
> output:
> 2015-Jan-21 18:43:01.342Z
>
> Note the reason your code didn't work is because SysTime uses 1/1/1 as
> the epoch.
Yeah. I really should add a unixTimeToSysTime function, but when I
originally wrote std.datetime, I wasn't thinking about getting times from C
stuff and converting them to D, just the other way around (a stupid
oversight in retrospect). The functionality is there, but it's more
convoluted than it should be. And the term "std time" was stupid on my part
too, since there's nothing standard about it except that it uses midnight of
1/1/1 as the epoch like the ISO standard says (but that has nothing to do
with hnsecs). Oh well, too late now, and I still don't know what a good name
for it would have been.
I'll have to put adding unixTimeToSysTime on the list of things to do after
finish splitting std.datetime (which I started again the other day but is
going more slowly than I'd like, since I've been rather busy). I also need
to update the "Introduction to std.datetime" article so that it talks more
about stuff like that than the now defunct std.date. When Walter was dealing
with some of that recently, he thought that it should focus more on
interacting with C than std.date, which makes sense at this point (though,
since he was porting something old from std.date, it's current state was
presumably useful to him).
Too much to do, too little time...
- Jonathan M Davis
Re: Time from timestamp?
On Friday, January 30, 2015 22:03:02 Jonathan M Davis via Digitalmars-d-learn wrote: > Yeah. I really should add a unixTimeToSysTime function, Actually, maybe it should be a static function on SysTime called fromUnixTime to go with toUnixTime. I don't know. Regardless, it's a nicety that should be there, and I botched things by not having it. - Jonathan M Davis
