Re: std.typecons rebindable + tuple with const class gives warning
On Thursday, 4 February 2021 at 20:40:43 UTC, tsbockman wrote: TLDR; Either make `c` mutable, or override/overload the `C` associative array support methods `toHash` and `opEquals` to support `const(C)` objects. This solved my issue. I finally understood why this was happening after digging in to the tuple code and hence understood your proposed solutions. Thank you so much! :) Saurabh
std.typecons rebindable + tuple with const class gives warning
This code:
void main()
{
import std.typecons : rebindable, tuple;
const c = new C();
auto t = tuple(c.rebindable);
}
class C
{
}
When compiled with DMD 2.095.0 gives a warning:
Warning: struct Rebindable has method toHash, however it cannot
be called with const(Rebindable!(const(C))) this.
What is causing this? How can this warning be resolved?
Re: dmd -O causes incorrect output
On Monday, 25 January 2021 at 19:18:47 UTC, H. S. Teoh wrote: On Mon, Jan 25, 2021 at 06:45:43PM +, Saurabh Das via Digitalmars-d-learn wrote: On Monday, 25 January 2021 at 18:19:24 UTC, H. S. Teoh wrote: [...] > It's probably a bug. File a bug on bugzilla: > https://issues.dlang.org [...] > DMD's backend is known to have obscure bugs that crop up > every so often. If this issue is being a showstopper, > consider switching to LDC or GDC instead. (You might want > to try the same code with LDC/GDC anyway, just to see > whether they have the same problem. My guess is they don't.) [...] LDMD2 seems to not suffer from this issue. No surprise there. I recommend using LDC (ldmd2) instead. Still file the bug, though, so that somebody will fix it eventually. T Thanks for the inputs. I'll fill a bug report about it.
Re: dmd -O causes incorrect output
On Monday, 25 January 2021 at 18:19:24 UTC, H. S. Teoh wrote: On Mon, Jan 25, 2021 at 06:07:46PM +, Saurabh Das via Digitalmars-d-learn wrote: [...] [...] [...] It's probably a bug. File a bug on bugzilla: https://issues.dlang.org [...] [...] DMD's backend is known to have obscure bugs that crop up every so often. If this issue is being a showstopper, consider switching to LDC or GDC instead. (You might want to try the same code with LDC/GDC anyway, just to see whether they have the same problem. My guess is they don't.) T LDMD2 seems to not suffer from this issue.
dmd -O causes incorrect output
I'm seeing what appears to be a bug with the -O flag in dmd. Here
is a reduced test case:
struct SomeStruct
{
long value;
}
bool isNumberOne(int i)
{
SomeStruct l;
if(i == 1)
l = SomeStruct(10);
return (l == SomeStruct(10));
}
void main()
{
if (!isNumberOne(1))
assert(false);
}
See: https://run.dlang.io/is/zlrDvy
rdmd test.d# Runs fine
rdmd -O test.d # Assert trips
The assert trips when run with "rdmd -O test.d" and it does not
trip when run with "rdmd test.d".
This bug is observed in all compiler versions from dmd-2.060
through to dmd-2.095! Please shed some light on the issue – any
help would be greatly appreciated.
Thanks,
Saurabh
Re: Surprising behaviour of std.experimental.allocator
On Saturday, 26 December 2020 at 19:36:24 UTC, ag0aep6g wrote:
On 26.12.20 13:59, ag0aep6g wrote:
Looks like a pretty nasty bug somewhere in
std.experimental.allocator or (less likely) the GC. Further
reduced code:
[...]
Apparently, something calls deallocateAll on a Mallocator
instance after the memory of that instance has been recycled
by the GC. Maybe allocatorObject or AllocatorList keep a
reference to GC memory out of sight of the GC.
I've looked into it some more, and as far as I can tell this is
what happens:
1) allocatorObject puts the AllocatorList instance into
malloced memory.
2) The AllocatorList puts the Mallocator instance into GC
memory, because its default BookkeepingAllocator is GCAllocator.
3) The GC recycles the memory of the Mallocator instance,
because it's only reachable via the malloced AllocatorList
instance and malloced memory isn't scanned by default.
4) Hell breaks loose because that recycled memory was not
actually garbage.
I'm not so sure anymore if this qualifies as a bug in
std.experimental.allocator. Maybe AllocatorList should be
registering its GC allocations as roots?
As a solution/workaround, you can use NullAllocator for
AllocatorList's BookkeepingAllocator:
import
std.experimental.allocator.building_blocks.null_allocator :
NullAllocator;
alias Alloc1 = FallbackAllocator!(
AllocatorList!(n => Region!Mallocator(1024*1024),
NullAllocator),
Mallocator);
Okay excellent. So there is a workaround atleast.
It also works with using Mallocator as the BookkeepingAllocator
for AllocatorList.
I encountered a slightly differt seg fault too. I'm wondering
whether it is related to this one:
import std.experimental.allocator: allocatorObject, expandArray;
import std.experimental.allocator.building_blocks.allocator_list:
AllocatorList;
import std.experimental.allocator.building_blocks.region: Region;
import
std.experimental.allocator.building_blocks.fallback_allocator:
FallbackAllocator;
import std.experimental.allocator.mallocator: Mallocator;
import core.memory: GC;
import std.stdio;
void main()
{
enum MB = 1024 * 1024;
{
alias Alloc1 = Region!Mallocator;
auto a1 = Alloc1(MB);
auto p1 = a1.allocate(10);
auto a2 = a1;
auto p2 = a2.allocate(10);
writeln(a1.owns(p1)); // Prints Ternary.Yes - incorrect?
writeln(a1.owns(p2)); // Prints Ternary.Yes - incorrect?
writeln(a2.owns(p1)); // Prints Ternary.Yes
writeln(a2.owns(p2)); // Prints Ternary.Yes
writeln(4); // This is printed
}
writeln(5); // this never gets printed; segfault happens upon
exiting the above scope
}
Re: Surprising behaviour of std.experimental.allocator
On Thursday, 24 December 2020 at 23:58:45 UTC, Elronnd wrote:
On Thursday, 24 December 2020 at 23:46:58 UTC, Elronnd wrote:
reduced version:
Further reduction: Alloc1 can just be ‘AllocatorList!(n =>
Region!Mallocator(MB))’.
Thank you for the reduced test case.
A small change to the test case seems to work in all the cases
I've tested so far, maybe it can help diagnose the issue. If we
use a pointer to construct the allocator, it seems to work fine:
void main() {
import std.experimental.allocator: allocatorObject,
expandArray;
import
std.experimental.allocator.building_blocks.allocator_list:
AllocatorList;
import std.experimental.allocator.building_blocks.region:
Region;
import
std.experimental.allocator.building_blocks.fallback_allocator:
FallbackAllocator;
import std.experimental.allocator.mallocator: Mallocator;
import core.memory: GC;
import std.stdio;
enum MB = 1024 * 1024;
{
alias Alloc1 = AllocatorList!(n =>
Region!Mallocator(MB));
auto a1 = Alloc1();
auto alloc1 = allocatorObject(&a1);
GC.collect;
alloc1.allocate(MB);
}
writeln(5); // this never gets printed; segfault happens
upon exiting the above scope
}
Surprising behaviour of std.experimental.allocator
This causes a segfault when run with rdmd -gx:
void main()
{
import std.experimental.allocator : allocatorObject,
expandArray;
import
std.experimental.allocator.building_blocks.allocator_list :
AllocatorList;
import std.experimental.allocator.building_blocks.region :
Region;
import
std.experimental.allocator.building_blocks.fallback_allocator :
FallbackAllocator;
import std.experimental.allocator.mallocator : Mallocator;
{
alias Alloc1 = FallbackAllocator!(
AllocatorList!(n => Region!Mallocator(1024*1024)),
Mallocator);
auto alloc1 = allocatorObject(Alloc1());
for (int ttt=0; ttt<10; ++ttt)
{
import std.stdio : writeln;
writeln(ttt);
import core.memory : GC;
auto p = alloc1.allocate(60*1024);
assert(p.length == 60*1024);
auto p2 = alloc1.allocate(3*1024*1024);
assert(p2.length == 3*1024*1024);
GC.collect();
alloc1.expandArray(p, 120*1024); // Segfault here
}
}
}
(Tested on DMD 2.094.2 and on https://run.dlang.io/is/p0FsOQ)
If the "GC.collect()" line is commented out, it works somehow.
Please help me understand why this is happening. This is a very
reduced example of an issue I am facing.
Thank You,
Saurabh
Re: core.atomic.atomicStore and structs
On Tuesday, 3 March 2020 at 11:35:35 UTC, MoonlightSentinel wrote: On Tuesday, 3 March 2020 at 11:04:53 UTC, Saurabh Das wrote: PS: Any chance this will make it into DMD 2.091.0? Yes, this fix will be in the upcoming release. Excellent. Thank you so much! :) Saurabh
Re: core.atomic.atomicStore and structs
On Tuesday, 3 March 2020 at 10:57:36 UTC, MoonlightSentinel wrote: On Tuesday, 3 March 2020 at 09:12:40 UTC, Saurabh Das wrote: Is this supposed to not work anymore? Or is this a bug? That is a bug, see https://issues.dlang.org/show_bug.cgi?id=20629 Oh wow you fixed it already! Amazing! Thanks MoonlightSentinel. Saurabh PS: Any chance this will make it into DMD 2.091.0?
core.atomic.atomicStore and structs
Hi,
Consider this code:
```
import core.atomic;
struct MyStruct
{
uint a, b;
}
static assert(MyStruct.sizeof == ulong.sizeof);
void main()
{
shared MyStruct ms1;
MyStruct ms2 = atomicLoad(ms1); // This is fine
MyStruct ms3;
cas(&ms1, ms2, ms3);// This is also fine
atomicStore(ms1, ms2); // This gives a compile
error
}
```
This used to work in DMD 2.088.1. It does not work in the latest
DMD 2.091.0-beta.2. It gives a compile error like this:
```
/home/ec2-user/dlang/dmd-2.091.0-beta.2/linux/bin64/../../src/druntime/import/core/internal/atomic.d(233):
Error: template core.internal.atomic.atomicExchange cannot deduce function
from argument types !(cast(MemoryOrder)5, false)(MyStruct*, MyStruct),
candidates are:
/home/ec2-user/dlang/dmd-2.091.0-beta.2/linux/bin64/../../src/druntime/import/core/internal/atomic.d(291):
atomicExchange(MemoryOrder order = MemoryOrder.seq, bool result = true,
T)(T* dest, T value)
with order = order,
result = false,
T = MyStruct
whose parameters have the following constraints:
> is(T : ulong)
or:
> is(T == class)
or:
> is(T == interface)
or:
> is(T U : U*)
Tip: not satisfied constraints are marked with >
/home/ec2-user/dlang/dmd-2.091.0-beta.2/linux/bin64/../../src/druntime/import/core/atomic.d(127):
Error: template instance core.internal.atomic.atomicStore!(cast(MemoryOrder)5,
MyStruct) error instantiating
/home/ec2-user/dlang/dmd-2.091.0-beta.2/linux/bin64/../../src/druntime/import/core/atomic.d(142):
instantiated from here: atomicStore!(cast(MemoryOrder)5, MyStruct,
MyStruct)
atomic_test.d(18):instantiated from here:
atomicStore!(cast(MemoryOrder)5, MyStruct, MyStruct)
```
Is this supposed to not work anymore? Or is this a bug?
Thanks,
Saurabh
Re: Is it possible to use DMD as a library to compile strings at runtime?
On Sunday, 2 February 2020 at 06:03:01 UTC, H. S. Teoh wrote: On Sun, Feb 02, 2020 at 03:16:46AM +, Saurabh Das via Digitalmars-d-learn wrote: [...] [...] > [...] [...] [...] [...] It's very simple. Let's say you have your code in some string called 'code'. Since dmd nowadays can take stdin as input (specify "-" as input filename), all you have to do is to assemble your dmd command and use std.process's awesome API to run it: [...] Thanks. Will try this out. Saurabh
Re: Is it possible to use DMD as a library to compile strings at runtime?
On Saturday, 1 February 2020 at 20:37:03 UTC, H. S. Teoh wrote: On Sat, Feb 01, 2020 at 08:01:34PM +, Andre Pany via Digitalmars-d-learn wrote: [...] Another approach: - include the dmd compiler package with your application - within your app call the compiler executable and compile the source code to a dll / so - call the dll / so function [...] I've actually done this before in an equation grapher program: the user inputs an equation, the program generates D code to compute the equation, then runs dmd to compile it into a shared library, and opens the shared library and looks up the symbol to execute the compiled code. Dmd is fast enough that this actually works fairly well. When the input to dmd is small, it's so fast you don't even notice it. T This approach seems more tractable at present. Would you have any example code lying around for this? Saurabh
Re: Unexpected issue with std.format
On Saturday, 1 February 2020 at 15:16:41 UTC, Steven
Schveighoffer wrote:
On 2/1/20 8:39 AM, Saurabh Das wrote:
I faced this issue while working with custom formatting for a
struct. I have reduced the error down to this test program:
import std.format, std.stdio, std.array;
struct Test1
{
void toString(W, C)(ref W w, scope const ref FormatSpec!C
fmt)
{
pragma(msg, "Test1 function compiled with W=" ~
W.stringof);
// formatValue(w, this, fmt);
}
}
struct Test2
{
void toString(W, C)(ref W w, scope const ref FormatSpec!C
fmt)
{
pragma(msg, "Test2 function compiled with W=" ~
W.stringof);
formatValue(w, this, fmt);
}
}
void main()
{
Test1 t1;
Test2 t2;
Appender!string writer;
auto ff = singleSpec("%s");
formatValue(writer, t1, ff);
formatValue(writer, t2, ff);
}
When compiled, the output is:
Test1 function compiled with W=S
Test1 function compiled with W=Appender!string
Test2 function compiled with W=S
1. Why was Test2 never compiled with W=Appender!string?
2. What is "S"?
Essentially, my custom struct was not being formatted using
the toString method that I had written. Reducing the issue, it
seems like a call to formatValue with the same type caused the
issue. If someone can explain what I am doing wrong here, it
would really help a lot.
Thanks,
Saurabh
Something very weird is happening.
I switched to fullyQualifiedName!W, and I get *no output*.
The "S" comes from hasToString
here:https://github.com/dlang/phobos/blob/9fe5cd354f0166b11d32a5c1214932757d8e7eba/std/format.d#L3876-L3899
I tried copying the implementation to a local file, and as
expected, I get customPutWriterFormatSpec for both types.
But it's only calling one of them in the implementation.
I think the only true way to diagnose this is to instrument
std.format and see what it's doing with more pragma(msg) calls.
Don't have the time right now.
-Steve
Thanks for the lead. To exemplify Steve's observation:
import std.format, std.stdio, std.array, std.range;
struct Test3
{
void toString(W, C)(ref W w, scope const ref FormatSpec!C
fmt)
{
import std.traits;
pragma(msg, "A: Test2 function compiled with W=" ~
fullyQualifiedName!W.stringof);
pragma(msg, "B: Test2 function compiled with W=" ~
W.stringof);
}
}
void main()
{
Test3 t3;
Appender!string writer;
auto ff = singleSpec("%s");
formatValue(writer, t3, ff);
}
Gives an output during compilation:
B: Test2 function compiled with W=S
Saurabh
Re: Unexpected issue with std.format
On Saturday, 1 February 2020 at 13:39:34 UTC, Saurabh Das wrote: I faced this issue while working with custom formatting for a struct. I have reduced the error down to this test program: [...] PS: Currently using DMD64 D Compiler v2.090.0
Unexpected issue with std.format
I faced this issue while working with custom formatting for a
struct. I have reduced the error down to this test program:
import std.format, std.stdio, std.array;
struct Test1
{
void toString(W, C)(ref W w, scope const ref FormatSpec!C fmt)
{
pragma(msg, "Test1 function compiled with W=" ~
W.stringof);
// formatValue(w, this, fmt);
}
}
struct Test2
{
void toString(W, C)(ref W w, scope const ref FormatSpec!C fmt)
{
pragma(msg, "Test2 function compiled with W=" ~
W.stringof);
formatValue(w, this, fmt);
}
}
void main()
{
Test1 t1;
Test2 t2;
Appender!string writer;
auto ff = singleSpec("%s");
formatValue(writer, t1, ff);
formatValue(writer, t2, ff);
}
When compiled, the output is:
Test1 function compiled with W=S
Test1 function compiled with W=Appender!string
Test2 function compiled with W=S
1. Why was Test2 never compiled with W=Appender!string?
2. What is "S"?
Essentially, my custom struct was not being formatted using the
toString method that I had written. Reducing the issue, it seems
like a call to formatValue with the same type caused the issue.
If someone can explain what I am doing wrong here, it would
really help a lot.
Thanks,
Saurabh
Re: Is it possible to use DMD as a library to compile strings at runtime?
On Friday, 31 January 2020 at 14:25:30 UTC, Basile B. wrote: On Friday, 31 January 2020 at 11:19:37 UTC, Saurabh Das wrote: [...] Fundamentally DMD as a library is a front-end. Jitting is to the backend side. You'll be able to lex and parse the source to get an AST, to perform the semantic passes on this AST and that's all. Then to run this code you would need to make an AST visitor that will generate the binary code to execute. Even using a specialized library with jitting abilities, such as LLVM-d [1] or libfirm-d [2], this would be *quite* a journey. [1] https://github.com/MoritzMaxeiner/llvm-d [2] https://gitlab.com/basile.b/libfirm-d Thank you. That's enough to get me started tinkering! Saurabh
Is it possible to use DMD as a library to compile strings at runtime?
I see that DUB has DMD as a library package, but I was not able to understand how to use it. Is it possible to use DMD as a library within a D program to compile a string to machine code and run the compiled code at runtime? Thanks, Saurabh
Is there any implementation of a 128bit integer?
The cent and ucent types are reserved for the future. Is there any knowledge/timeline on when they might be implemented? Currently, is there a useable 128bit integer type in DMD/LDC/GDC? Or perhaps a library that implements 128bit integers? I've come across gfm:integers (https://github.com/d-gamedev-team/gfm/blob/master/integers/gfm/integers/wideint.d). Are there any other libraries? Thanks, Saurabh
Re: Bug with writeln?
Thank you for explaining all this. It is frustrating because the behaviour is very counterintuitive. I will use a workaround for now. Saurabh
Bug with writeln?
Is this a bug with writeln?
void main()
{
import std.stdio, std.range, std.algorithm;
auto a1 = sort([1,3,5,4,2]);
auto a2 = sort([9,8,9]);
auto a3 = sort([5,4,5,4]);
pragma(msg, typeof(a1));
pragma(msg, typeof(a2));
pragma(msg, typeof(a3));
auto b = [a1, a2, a3];
pragma(msg, typeof(b));
writeln("b:");
writeln(b);
writeln(b); // <-- this one prints incorrectly
writeln("a:");
writeln(a1);
writeln(a2);
writeln(a3);
}
Output
==
SortedRange!(int[], "a < b")
SortedRange!(int[], "a < b")
SortedRange!(int[], "a < b")
SortedRange!(int[], "a < b")[]
b:
[[1, 2, 3, 4, 5], [8, 9, 9], [4, 4, 5, 5]]
[[], [], []]
a:
[1, 2, 3, 4, 5]
[8, 9, 9]
[4, 4, 5, 5]
The issue goes away if I cast 'b' to const before writeln. I
think it is a bug, but maybe I am missing something?
Scalars in ndslice?
I've been using ndslice for some timeseries work and it's incredibly good. One question which I couldn't find an answer to: Can ndslice behave as a scalar (ie: 0-dimensional slice)? It would be convenient if that is possible since then I won't have to write different functions for scalars and ndslices. How can I accomplish this? Thanks, Saurabh
Re: Huge increase in UT compile time
On Saturday, 14 October 2017 at 09:03:05 UTC, Joakim wrote: On Saturday, 14 October 2017 at 04:36:25 UTC, Saurabh Das wrote: [...] I can reproduce on linux/x64, looks like a memory leak, as dmd balloons out to eat up all available memory until it's killed. I see it with this minimal command passed to dmd 2.075.1, but not the 2.074.1 frontend, as reported: ./dmd2/linux/bin64/dmd -c -o- foo.d -unittest -deps=foo.deps The closest issue I was able to find in bugzilla is this one, but that says it goes away with -o-, not the case here: https://issues.dlang.org/show_bug.cgi?id=17601 I suggest one of you file a bug with the minimal command, noting that it goes away if -unittest or -deps is not passed. Make sure you mark it as a regression, just like the above bug, as Walter pays special attention to those. Filed a bug report: https://issues.dlang.org/show_bug.cgi?id=17898 Hope I didn't miss anything.
Re: Huge increase in UT compile time
On Wednesday, 11 October 2017 at 08:11:37 UTC, Jonathan M Davis wrote: On Wednesday, October 11, 2017 06:25:19 Dhananjay via Digitalmars-d-learn wrote: Hello, I am upgrading to DMD 2.076.1 from DMD 2.069.2 (similar results on 2.075.1), and seeing a huge increase in unittest compilation time when the -deps parameter is also passed to dmd. This is on both OSX and linux. What can be the cause of this? Well, that's a pretty big version jump. So, a lot could have changed. One thing that comes to mind would be that imports were overhauled pretty thoroughly to try and fix various import bugs. This blog article talks about some of that: http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/ Or the change could be the result of something else entirely. Figuring it out would likely require doing a fair bit of debugging to narrow down when the change happened (and that's assuming that it's caused by a single commit or small set of commits rather than simply getting worse over time due to a variety of factors). - Jonathan M Davis The following observations (for the above test program) were recorded on Mac OS X 10.11.6: DMD64 D Compiler v2.073.1 real0m0.091s user0m0.067s sys 0m0.020s DMD64 D Compiler v2.074.0 real0m0.105s user0m0.072s sys 0m0.022s DMD64 D Compiler v2.075.1 real0m44.932s user0m35.732s sys 0m7.098s DMD64 D Compiler v2.076.1 real0m46.833s user0m37.827s sys 0m7.254s Furthermore, 2.075.1 gave a bunch of deprecation warnings in std/string.d. The -de switch had to be removed before running. Hope this helps, Saurabh
Re: Funny issue with casting double to ulong
On Monday, 3 July 2017 at 03:57:25 UTC, Basile B wrote: On Monday, 3 July 2017 at 03:50:14 UTC, Saurabh Das wrote: [...] 6.251 has no perfect double representation. It's real value is: 6.215099962483343551867E0 Hence when you cast to ulong after the product by 10_000, this is the equivalent of trunc(62150.99962483343551867E0) which gives 62150 CQFD ;-] That explains it! Thank you.
Funny issue with casting double to ulong
Consider this snippet:
void main()
{
import std.stdio;
auto a = 6.2151;
auto b = a * 1;
auto c = cast(ulong)b;
writeln("a: ", typeof(a).stringof, " ", a);
writeln("b: ", typeof(b).stringof, " ", b);
writeln("c: ", typeof(c).stringof, " ", c);
auto x = 62151.0;
auto y = cast(ulong)x;
writeln("x: ", typeof(x).stringof, " ", x);
writeln("y: ", typeof(y).stringof, " ", y);
}
The output is:
a: double 6.2151
b: double 62151
c: ulong 62150
x: double 62151
y: ulong 62151
Why does c round off from 62151 to 62150 when casting to ulong?
Thanks,
Saurabh
Re: Need some help understanding PyD
PS: Noticed something off. My python installation is 3.4.3:
Python 3.4.3 (default, Sep 14 2016, 12:36:27)
[GCC 4.8.4] on linux
However when I run:
context.py_stmts("import sys");
context.py_stmts("print(sys.version)");
I get:
3.4.0 (default, Apr 11 2014, 13:08:40)
[GCC 4.8.2]
Also, when I import numpy from python3, it works, but if I do:
context.py_stmts("import numpy");
I get this error:
pyd.exception.PythonException@source/app.d(20):
ImportError:
/usr/lib/python3.4/lib-dynload/_ctypes.cpython-34m-x86_64-linux-gnu.so: undefined symbol: _PyTraceback_Add
Need some help understanding PyD
I've been giving PyD a try. It's really nice and mostly
everything works out of the box.
I'm trying to use TensorFlow in D via Pytho, so I need to call
Python functions in D.
When I try to do:
auto context = new InterpContext();
context.py_stmts("import tensorflow");
I get this error:
pyd.exception.PythonException@source/app.d(19):
ImportError:
/usr/lib/python3.4/lib-dynload/_ctypes.cpython-34m-x86_64-linux-gnu.so: undefined symbol: _PyTraceback_Add
../../.dub/packages/pyd-0.9.8/pyd/infrastructure/pyd/exception.d:46 void
pyd.exception.handle_exception(immutable(char)[], ulong) [0x5917f6]
../../.dub/packages/pyd-0.9.8/pyd/infrastructure/pyd/embedded.d:147 void
pyd.embedded.InterpContext.py_stmts(immutable(char)[], immutable(char)[],
ulong) [0x59149a]
source/app.d:13 _Dmain [0x573cb2]
??:?
_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv
[0x5abfae]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate()) [0x5abf04]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll() [0x5abf6a]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate()) [0x5abf04]
??:? _d_run_main [0x5abe61]
??:? main [0x575e6f]
??:? __libc_start_main [0x3fffbec4]
Program exited with code 1
How can I debug what the problem is?
Thanks,
Saurabh
Re: Vibe.D - log requests and responses
On Thursday, 24 November 2016 at 07:57:47 UTC, Jacob Carlborg wrote: On 2016-11-24 07:29, Saurabh Das wrote: [...] Yes. You can configure the logging on the HTTPServerSettings [1] instance. If you look at the documentation, the first four fields are related to logging. Use "accessLogFile" to set the filename of the log file. Use "accessLogFormat" to configure the log format. It uses the same syntax as Apache. Unfortunately the syntax is not documented in vibe.d and it doesn't implement all of the features that Apache has. I looked at the source code to figure out the format [2]. %D will give you the time taken to serve the request in milliseconds and %T in seconds. %t will give you the time stamp the request was received. I don't see anything related to waiting time. [...] Thanks Jacob. That is precisely what I needed. :)
Vibe.D - log requests and responses
Hi, Is there an easy way to log all incoming requests and outgoing responses (and perhaps processing time, wait time, etc) in Vibe.D? Thanks, Saurabh
Re: Concatenate 2 ranges
On Friday, 11 November 2016 at 13:30:17 UTC, RazvanN wrote: I am trying to concatenate 2 ranges of the same type (SortedRange in my case). I have tried merge, join and chain, but the problem is that the result is not an object of the type of the initial ranges. For example: 1. If I use chain(r1, r2), the result will be an object of type Result which I cannot cast to my specific type (SortedRange). 2. If I use merge(r1, r2), the result will be an object of type Merge!(typeof(r1), typeof(r)). I know that I can use the .array property, but I think that this iterates through all of my elements. Using assumeSorted(chain(r1, r2).array) will return a SortedRange, but I am not sure what the complexity for this operation is. Is there a way to concatenate 2 ranges (SortedRange in my case) in O(1) time? I think chain of 2 sorted ranges will not necessarily be sorted. For example, chain([1, 2, 10], [4, 5, 11]) -> [1, 2, 10, 4, 5, 11] which is not sorted. You will need some kind of a merge to get a sorted range from 2 already sorted ranges. Thanks, SD
Re: Neural Networks / ML Libraries for D
On Tuesday, 25 October 2016 at 14:31:39 UTC, bachmeier wrote: On Tuesday, 25 October 2016 at 13:58:33 UTC, Saurabh Das wrote: [...] Installation amounts to installing a couple of R packages that I have on Bitbucket, as described on the project page. I have basic usage examples there as well. You can find the project here: https://bitbucket.org/bachmeil/embedr [...] This is excellent. I will try it out :) Thanks so much.
Re: Neural Networks / ML Libraries for D
On Tuesday, 25 October 2016 at 13:26:49 UTC, bachmeier wrote: On Tuesday, 25 October 2016 at 11:17:29 UTC, Saurabh Das wrote: Hello, Are there any good ML libraries for D? In particular, looking for a neural network library currently. Any leads would be appreciated. Thanks, Saurabh I have written a project to embed R inside D and vice versa for my research (currently Linux only). Any neural network library for R is trivially available inside D. Ideally these libraries would be written in D but I'm a strong believer in reusing working code. If this is something that is of interest, let me know. Oh that sounds pretty cool. While I probably won't use it right now, embedding R inside D would be a good learning opportunity. Is it available on code.dlang.org or on GitHub? Thanks Saurabh
Re: Neural Networks / ML Libraries for D
On Tuesday, 25 October 2016 at 11:55:27 UTC, maarten van damme wrote: There is mir https://github.com/libmir/mir which is geared towards machine learning, I don't know if it has anything about neural networks, I've yet to use it. If you're only interested in neural networks, I've used FANN (a C library) together with D and it worked very well. 2016-10-25 13:17 GMT+02:00 Saurabh Das via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com>: Hello, Are there any good ML libraries for D? In particular, looking for a neural network library currently. Any leads would be appreciated. Thanks, Saurabh I saw mir but it didn't seem to have anything for NNs. I'll give FANN a try.
Neural Networks / ML Libraries for D
Hello, Are there any good ML libraries for D? In particular, looking for a neural network library currently. Any leads would be appreciated. Thanks, Saurabh
Re: Repeat and chunks
On Monday, 24 October 2016 at 15:59:05 UTC, Meta wrote: On Monday, 24 October 2016 at 15:28:50 UTC, Saurabh Das wrote: [...] Yes, that's correct. This is the overload of `repeat` in question: https://dlang.org/phobos/std_range.html#.repeat.2 Take!(Repeat!T) repeat(T)(T value, size_t n); Repeats value exactly n times. Equivalent to take(repeat(value), n). Examples: import std.algorithm : equal; assert(equal(5.repeat(4), 5.repeat().take(4))); The variant of repeat that takes a second argument returns a range with a length; it is not an infinite range, unlike the first overload of repeat. So for the OP's code: repeat(8, 10).chunks(3).writeln(); This will throw an AssertError because 10 is not evenly divisible by 3. Sure, but: // This fails: repeat(8, 9).chunks(3).writeln(); // This works: repeat(8, 6).chunks(3).writeln(); Both are divisible by 3. Maybe it's a bug?
Re: Repeat and chunks
On Monday, 24 October 2016 at 15:28:50 UTC, Saurabh Das wrote:
On Monday, 24 October 2016 at 14:25:46 UTC, Dorian Haglund
wrote:
Hey,
The following code crashes with DMD64 D Compiler v2.071.2:
import std.algorithm;
import std.stdio;
import std.range;
int main()
{
repeat(8, 10).chunks(3).writeln();
return 0;
}
Error message:
pure nothrow @nogc @safe
std.range.Take!(std.range.Repeat!(int).Repeat).Take
std.range.Repeat!(int).Repeat.opSlice(ulong, ulong)
If I replace repeat with iota, or a literal range (like [1, 2
,3, 4]), I don't get the crash.
I don't see why I should not be able to use chunks with repeat.
If some property of repeat's range is missing to use chunks,
shouldn't I get an error message ?
Am I missing something ?
PS: the behavior has been reproduced on someone else computer.
Cheers :)
This works:
repeat(8, 12).chunks(3).writeln;
The documentation of
https://dlang.org/phobos/std_range.html#.chunks mentions
something about evenly divisible by chunkSize – perhaps that is
the cause of the assert fail. Not 100% sure why that's there
though.
Thanks,
Saurabh
Some more cases, perhaps someone more knowledgeable can help:
import std.algorithm;
import std.stdio;
import std.range;
int main()
{
[8, 8, 8, 8, 8, 8].chunks(3).writeln; // prints [[8, 8, 8],
[8, 8, 8]]
repeat(8, 6).writeln; // prints [8, 8, 8, 8,
8, 8]
repeat(8, 6).chunks(3).writeln; // prints [[8, 8, 8]].
Why?
assert([8, 8, 8, 8, 8, 8] == repeat(8, 6).array); // Passes
assert([8, 8, 8, 8, 8, 8].chunks(3).array == repeat(8,
6).array.chunks(3).array); // Passes
assert([8, 8, 8, 8, 8, 8].chunks(3).array == repeat(8,
6).chunks(3).map!(a => a.array).array); // Fails
return 0;
}
Re: Repeat and chunks
On Monday, 24 October 2016 at 14:25:46 UTC, Dorian Haglund wrote:
Hey,
The following code crashes with DMD64 D Compiler v2.071.2:
import std.algorithm;
import std.stdio;
import std.range;
int main()
{
repeat(8, 10).chunks(3).writeln();
return 0;
}
Error message:
pure nothrow @nogc @safe
std.range.Take!(std.range.Repeat!(int).Repeat).Take
std.range.Repeat!(int).Repeat.opSlice(ulong, ulong)
If I replace repeat with iota, or a literal range (like [1, 2
,3, 4]), I don't get the crash.
I don't see why I should not be able to use chunks with repeat.
If some property of repeat's range is missing to use chunks,
shouldn't I get an error message ?
Am I missing something ?
PS: the behavior has been reproduced on someone else computer.
Cheers :)
This works:
repeat(8, 12).chunks(3).writeln;
The documentation of
https://dlang.org/phobos/std_range.html#.chunks mentions
something about evenly divisible by chunkSize – perhaps that is
the cause of the assert fail. Not 100% sure why that's there
though.
Thanks,
Saurabh
Re: Vibe.d compilation error: backend/cgelem.c 5018 dmd failed with exit code 1.
On Thursday, 22 September 2016 at 10:44:29 UTC, llaine wrote: On Wednesday, 21 September 2016 at 21:32:02 UTC, Rene Zwanenburg wrote: On Wednesday, 21 September 2016 at 20:22:42 UTC, llaine wrote: Yes, but it may take some time. For large projects, running it on a server is advisable. 3K LOC should be doable on a desktop machine. Dub has built-in support for running Dustmite. I'm not very familiar with it, but it looks like you'll want to use 'dub dustmite' with the --compiler-regex switch with a regex matching the ICE assert message. Any idea how to run with dub ? Trying like this dub dustmite app/ --compiler-regex="Internal Error" 'dub build -b release' I think it is something like: dub dustmite ./dustmite_output/ --compiler-regex="Internal Error" -b release
Re: Vibe.d compilation error: backend/cgelem.c 5018 dmd failed with exit code 1.
On Wednesday, 21 September 2016 at 14:15:30 UTC, llaine wrote: Using dmd every day and since one day I'm getting this error when I'm compiling using the -b release flag (dub build -b release). I'm compiling a vibe.d application that has roughly 3k LoC. Removing the -b flag solves the problem. Dmd version : v2.071.0 Vibe.d version : 0.7.26 I'm sure some more experienced forum readers will weigh in soon, but my understanding is that: All ICEs are errors in the compiler. You should submit it as a bug at https://issues.dlang.org/ If you can use DustMite to narrow down the error, that would help track it down much faster. Thanks, Saurabh
Re: What blogs about D do you read?
On Monday, 19 September 2016 at 19:36:22 UTC, Karabuta wrote: On Monday, 19 September 2016 at 19:29:25 UTC, A D dev wrote: On Monday, 19 September 2016 at 17:42:51 UTC, A D dev wrote: Hi list, What blogs about D do you read? To be more clear: - what blogs that include posts on D, would you recommend to a D beginner? Thanks. I have one here on Vibe.d for beginners https://laberba.github.io/2016/hello-world-app-with-the-vibe.d-web-framework/ I will be writing more for-beginners blogs in the coming few weeks. You blog looks gorgeous. Absolutely beautiful!
Re: Log in an @nogc function
On Wednesday, 17 August 2016 at 10:47:54 UTC, Guillaume Piolat
wrote:
On Wednesday, 17 August 2016 at 10:45:01 UTC, Saurabh Das wrote:
Is there any way I can log to a terminal or a file from inside
an @nogc function?
Thanks,
Saurabh
import core.stdc.stdio;
printf("am logging C-style\n");
Damn I should have tried that. I feel stupid now :(
Thank you!! :)
SD
Log in an @nogc function
Is there any way I can log to a terminal or a file from inside an @nogc function? Thanks, Saurabh
Re: Replace (ie: substitute) a type in varadic args
On Tuesday, 2 August 2016 at 08:16:48 UTC, Sean Campbell wrote:
On Tuesday, 2 August 2016 at 07:24:28 UTC, Saurabh Das wrote:
[...]
Just of the top of my head, using ugly string mixins, this:
auto myConverterFunc(Args...)(Args args)
{
string genCode()
{
string code = "targetFunction(";
foreach (i, Arg; Args)
{
static if (is(Arg == bool))
code ~= format("cast(ubyte)args[%s]%s", i, i ==
Args.length ? "" : ",");
else
code ~= format("args[%s]%s", i, i == Args.length ?
"" : ",");
}
code ~= ");";
return code;
}
mixin(genCode());
}
void targetFunction(ubyte i, ubyte j, uint k, int l)
{
writefln("i : %s, j : %s, k : %s, l : %s",i,j,k,l);
}
void main()
{
myConverterFunc(true,false,10,20);
}
Thanks. Yes that is one approach. I figured out another approach
that seems decent:
auto targetFunctionProxy(Args...)(Args args)
{
import std.meta;
return targetFunction!(ReplaceAll!(bool, ubyte, Args))(args);
}
Re: Replace (ie: substitute) a type in varadic args
On Tuesday, 2 August 2016 at 08:20:22 UTC, Saurabh Das wrote:
On Tuesday, 2 August 2016 at 08:16:48 UTC, Sean Campbell wrote:
[...]
Thanks. Yes that is one approach. I figured out another
approach that seems decent:
auto targetFunctionProxy(Args...)(Args args)
{
import std.meta;
return targetFunction!(ReplaceAll!(bool, ubyte,
Args))(args);
}
PS: I'm unsure if this results in additional copying of arguments
in the case where there are no bools in the arguments.
Replace (ie: substitute) a type in varadic args
How can I substitute the type of an argument received via a
varadic template?
For example say I want to generalise this scenario:
auto myConverterFunction1(bool arg1, bool arg2, ubyte arg3, int
arg4)
{
return targetFunction(cast(ubyte)arg1, cast(ubyte)arg2, arg3,
arg4);
}
So I'll have something like:
auto myConverterFunction2(Args...)(Args args)
{
// Don't know how to do this part...
}
Basically I need to substitute bool for ubyte to interface with
the Java JNI.
Thanks,
Saurabh
Re: Default implementations in inherited interfaces
On Sunday, 24 July 2016 at 07:54:11 UTC, Jonathan Marler wrote: On Thursday, 21 July 2016 at 13:37:30 UTC, Saurabh Das wrote: On Thursday, 21 July 2016 at 12:42:14 UTC, Adam D. Ruppe wrote: On Thursday, 21 July 2016 at 09:41:27 UTC, Saurabh Das wrote: Java 8 has a 'default' keyword that allows interfaces to provide a default implementation and sub-classes can optionally override it if needed. The rationale behind it was extending interfaces without causing old code to faill. (called "virtual extension methods" or "defender methods"). The use case is similar to above. Is there a way to achieve an equivalent functionality in D? Thanks, Saurabh What an interesting technique. I've never seen this before. Maybe a DIP is in order? I think it would be low priority relative to the current work being done, but this technique seems like a good thing to support in the language. I am studying the use cases for defender methods. It would be good to support this in D. I don't think I have enough knowledge about the subject to write a DIP for it yet though.
Re: Default implementations in inherited interfaces
On Thursday, 21 July 2016 at 12:42:14 UTC, Adam D. Ruppe wrote: On Thursday, 21 July 2016 at 09:41:27 UTC, Saurabh Das wrote: I have an interface A which declares a certain function. A second interface B inherits from A and wishes to provide a default implementation for that function. You can't, interfaces cannot have implementations of virtual functions. Your code is trying to define two separate functions with the same name (the compiler should probably prohibit that, since it doesn't do want you want it to do). Your best bet is to make B an abstract class instead of an interface. Then it can override interface functions. Of course, it will also tie you down as you can only inherit from one class, but it will actually work. I see. Java 8 has a 'default' keyword that allows interfaces to provide a default implementation and sub-classes can optionally override it if needed. The rationale behind it was extending interfaces without causing old code to faill. (called "virtual extension methods" or "defender methods"). The use case is similar to above. Is there a way to achieve an equivalent functionality in D? Thanks, Saurabh
Default implementations in inherited interfaces
I have an interface A which declares a certain function. A second
interface B inherits from A and wishes to provide a default
implementation for that function. How can I achieve this? I'm
facing an error when I try this:
interface A
{
int func(int);
}
interface B : A
{
final int func(int)
{
return 0;
}
}
class C : B
{
}
rdmd it.d:
it.d(14): Error: class it.C interface function 'int func(int)' is
not implemented
Thanks,
Saurabh
Re: Mono-D for the new Xamarin Studio
On Friday, 10 June 2016 at 13:36:43 UTC, Alex Bothe wrote: On Friday, 10 June 2016 at 12:51:34 UTC, Saurabh Das wrote: I have foolishly updated my Xamarin Studio and now the D Language Binding no longer works. Is there an update to fix this? Or should I downgrade? Thanks, Saurabh Hi there, please uninstall XS and reinstall the older release http://www.monodevelop.com/download/ Thanks Alex. I shall do that. Will you release an update that works on the new XS soon? Saurabh
Mono-D for the new Xamarin Studio
I have foolishly updated my Xamarin Studio and now the D Language Binding no longer works. Is there an update to fix this? Or should I downgrade? Thanks, Saurabh
Re: Is there a 128-bit integer in D?
On Sunday, 22 May 2016 at 09:07:32 UTC, Guillaume Piolat wrote: On Sunday, 22 May 2016 at 07:40:08 UTC, Nicholas Wilson wrote: On Saturday, 21 May 2016 at 09:43:38 UTC, Saurabh Das wrote: I see that 'cent' and 'ucent' are reserved for future use but not yet implemented. Does anyone have a working implementation of these types? Alternatively, is there an any effort towards implementation of arbitrary-sized integers in Phobos? Thanks, Saurabh There is a recursive arbitrary sized integer implementation floating around somewhere. Perhaps try dub for some math libraries. https://github.com/d-gamedev-team/gfm/blob/master/integers/gfm/integers/wideint.d wideint was exactly what I was looking for! Thank you so much :) Saurabh
Re: Is there a 128-bit integer in D?
On Saturday, 21 May 2016 at 21:51:34 UTC, Jonathan M Davis wrote: On Saturday, May 21, 2016 09:43:38 Saurabh Das via Digitalmars-d-learn wrote: I see that 'cent' and 'ucent' are reserved for future use but not yet implemented. Does anyone have a working implementation of these types? The keywords are reserved for future use not in current use. So, no, there are no 128-bit integer types in D currently. It's just that we left the door open for ourselves to add them later without breaking programs due to having to create a new keyword. Alternatively, is there an any effort towards implementation of arbitrary-sized integers in Phobos? We've had that for years. It's BigInt in std.bigint. - Jonathan M Davis Thankyou. I'll have a look at that. Saurabh
Is there a 128-bit integer in D?
I see that 'cent' and 'ucent' are reserved for future use but not yet implemented. Does anyone have a working implementation of these types? Alternatively, is there an any effort towards implementation of arbitrary-sized integers in Phobos? Thanks, Saurabh
Re: Using shorthand *= leads to unexpected result?
On Sunday, 15 May 2016 at 13:25:42 UTC, Michael wrote:
Well I'm pretty sure the code was working just fine earlier in
the week at the office, but running the code at home with the
newest version of DMD started producing these odd results.
Typing this function into asm.dlang.org shows a minor difference
in the assembly generated:
auto f1(double d1)
{
d1 *= -1.0;
return d1;
}
With DMD 2.070.2:
pure nothrow @nogc @safe double example.f1(double):
push %rbp
mov%rsp,%rbp
sub$0x10,%rsp
movsd %xmm0,-0x8(%rbp)
xorb $0x80,-0x1(%rbp)
rex.W movsd -0x8(%rbp),%xmm0
leaveq
retq
nopl 0x0(%rax)
With DMD 2.071.0:
pure nothrow @nogc @safe double example.f1(double):
push %rbp
mov%rsp,%rbp
sub$0x10,%rsp
movsd %xmm0,-0x8(%rbp)
xorb $0x80,-0x8(%rbp)
rex.W movsd -0x8(%rbp),%xmm0
leaveq
retq
nopl 0x0(%rax)
The xorb line is different and I conjecture that it is causing
the bug. I have never used floating-point assembly instructions,
so I cannot understand what the logic is here. I'll read up and
try to interpret to confirm.
Hope this helps.
Re: Using shorthand *= leads to unexpected result?
On Sunday, 15 May 2016 at 13:01:45 UTC, Michael wrote: It may be that I'm doing something wrong here, but after updating DMD to the latest version, my simulations started producing some very odd results and I think I've pinpointed it to a sign inversion that I was making. Here is some code from dpaste to demonstrate the behaviour I get vs. the behaviour I expected: https://dpaste.dzfl.pl/9bd7aea75fb2 Any ideas? Am I getting something wrong or is this some sort of regression with the latest DMD? Strangely, if I substitute the variable type 'auto' for 'float' or 'real', it gives the expected output of -1. Variable type 'double' gives the incorrect value of 1. This is strange behaviour. Perhaps someone more knowledgeable can shed light. If it is a regression, it is a very serious regression :( ~ sd
Re: nanosecond time
On Saturday, 13 February 2016 at 19:24:44 UTC, ishwar wrote:
I am stumped on need finding interval between two events in a
program execution in nanoseconds. Any sample code will be
appreciated (along with imports needed to make it work):
- time in nanoseconds-now
- do-some processing
- time in nano-second-now
Thanks
As suggested above, use a StopWatch.
I use this (not-very-cross-platform) function for latency
measurement purposes. It is precise on Linux. For Mac OS and
Windows, it's returns an approximation:
version(linux) import core.sys.linux.time;
version(OSX)import core.time;
version(Windows) import core.sys.windows.windows;
static if(is(typeof(clockid_t)))
{
extern(C) nothrow int clock_gettime(clockid_t, timespec*);
}
public ulong getLocalTimestampNS() nothrow @nogc
{
static if(is(typeof(clock_gettime)))
{
timespec ts;
clock_gettime(CLOCK_MONOTONIC_RAW, &ts);
return ts.tv_sec * 10 + ts.tv_nsec;
}
static if(is(typeof(mach_absolute_time)))
{
// IMPORTANT NOTE: mach_absolute_time does not always
return nanoseconds.
// Sometimes it returns other values. We are using it
here as an approximation.
return mach_absolute_time();
}
version (Windows)
{
// Just an approximation
long cnt;
if (QueryPerformanceCounter(&cnt))
{
return cnt * 500;
}
return 0;
}
}
Re: Is this a bug in std.typecons.Tuple.slice?
On Wednesday, 10 February 2016 at 00:24:56 UTC, tsbockman wrote: [...] `Tuple.slice` is corrupting data *right now*. Some sort of short-term fix should be merged in the next release of D. +1
Re: Is this a bug in std.typecons.Tuple.slice?
On Sunday, 7 February 2016 at 02:51:49 UTC, tsbockman wrote: On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote: I understand that. We just have a different perspective on the problem. Your priorities: - don't break what's not broken - .slice! lends on opSlice and should return by ref My priorities: - type of .slice! should be as if constructing with same values from scratch - keep code additions in Phobos to a minimum Why do I insist on the return type? Because surprisingly simple code breaks if it doesn't match. Not everything can be covered by runtime conversions in D. I think the key question is, do users care about being able to modify the original `Tuple` instance indirectly through `slice`? If yes, then the only workable solutions I can see are: 1) My current proposal (insert a hidden padding member at the beginning of the slice `Tuple`) 2) Don't return a `Tuple` at all - return a dedicated `TupleSlice` type that is implicitly convertible to `Tuple`. This approach would work with the example you came up with, but implementing `TupleSlice` well could be very complex, I think. If not, then I have no fundamental objection to Saurabh Das' approach, although I think the PR needs work. The PR definitely needs work - it was proposed to outline the direction. I haven't worked at all on Phobos and I am not yet knowledgeable on writing library-quality code in D. I'm hoping to contribute back to Phobos this year - so pointing out as many flaws will help learn faster :) In particular - the inout problem in the PR - I'm not sure yet on how to fix that. Thanks, Saurabh We should start a new thread in "General" to ask whether people care about the `ref`-ness of `Tuple` slices is really the deciding factor.
Re: Is this a bug in std.typecons.Tuple.slice?
On Saturday, 6 February 2016 at 08:01:20 UTC, tsbockman wrote: On Saturday, 6 February 2016 at 06:34:05 UTC, Marco Leise wrote: [...] I should also point out that, since there is no way to actually find out whether anyone is using the `ref`-ness of the return type in the wild, the approach that you and Saurabh Das are taking really ought to include changing the symbol name and deprecating the old one. Otherwise you could introduce subtle bugs into previously valid code; not every significant effect of removing `ref` will cause an error message at compile time *or* run time - some will just silently change the behaviour of the program, which is awful. I think we should add a static assert to slice to ensure that the current implementation is not used in a case where the alignment doesn't match. This is better than failing without any warning. We could add new (differently named) functions for slicing non-aligned tuples. I agree that my approach of removing the ref may break existing code, so if introduced, it should be named differently. I am not comfortable with tuple(42, true, "abc").slice(1, 3) being different in type from tuple(true, " abc").
Re: Is this a bug in std.typecons.Tuple.slice?
On Friday, 5 February 2016 at 19:16:11 UTC, Marco Leise wrote: Am Fri, 05 Feb 2016 05:31:15 + schrieb Saurabh Das : [...] That is enlightening. I have updated the PR at https://github.com/D-Programming-Language/phobos/pull/3975 to incorporate these changes.
Re: Is this a bug in std.typecons.Tuple.slice?
On Friday, 5 February 2016 at 05:18:01 UTC, Saurabh Das wrote:
[...]
Apologies for spamming. This is an improved implementation:
@property
Tuple!(sliceSpecs!(from, to)) slice(size_t from, size_t
to)() @safe const
if (from <= to && to <= Types.length)
{
return typeof(return)(field[from .. to]);
}
///
unittest
{
Tuple!(int, string, float, double) a;
a[1] = "abc";
a[2] = 4.5;
auto s = a.slice!(1, 3);
static assert(is(typeof(s) == Tuple!(string, float)));
assert(s[0] == "abc" && s[1] == 4.5);
Tuple!(int, int, long) b;
b[1] = 42;
b[2] = 101;
auto t = b.slice!(1, 3);
static assert(is(typeof(t) == Tuple!(int, long)));
assert(t[0] == 42 && t[1] == 101);
}
These questions still remain:
1. Removing 'ref' from the return type
2. Adding 'const' to the function signature
3. Is the new implementation less efficient for correctly
aligned tuples?
4. @trusted -> @safe?
Re: Is this a bug in std.typecons.Tuple.slice?
On Friday, 5 February 2016 at 05:18:01 UTC, Saurabh Das wrote: [...] PS: Additionally, '@trusted' can now be substituted with '@safe'.
Re: Is this a bug in std.typecons.Tuple.slice?
On Thursday, 4 February 2016 at 17:52:16 UTC, Marco Leise wrote:
https://issues.dlang.org/show_bug.cgi?id=15645
Is this a possible fixed implementation? :
@property
Tuple!(sliceSpecs!(from, to)) slice(size_t from, size_t
to)() @trusted const
if (from <= to && to <= Types.length)
{
auto sliceMixinGenerator()
{
string rv;
for(auto i=from; irv ~= "returnValue[" ~ (i-from).to!string ~
"]=field[" ~ i.to!string ~"];";
}
return rv;
}
alias ReturnType = typeof(return);
ReturnType returnValue;
mixin(sliceMixinGenerator());
return returnValue;
}
///
unittest
{
Tuple!(int, string, float, double) a;
a[1] = "abc";
a[2] = 4.5;
auto s = a.slice!(1, 3);
static assert(is(typeof(s) == Tuple!(string, float)));
assert(s[0] == "abc" && s[1] == 4.5);
Tuple!(int, int, long) b;
b[1] = 42;
b[2] = 101;
auto t = b.slice!(1, 3);
static assert(is(typeof(t) == Tuple!(int, long)));
assert(t[0] == 42 && t[1] == 101);
}
I'm unsure about:
1. Removing 'ref' from the return type
2. Adding 'const' to the function signature
3. Is the new implementation less efficient for correctly aligned
tuples?
Re: Is this a bug in std.typecons.Tuple.slice?
On Thursday, 4 February 2016 at 17:52:16 UTC, Marco Leise wrote: https://issues.dlang.org/show_bug.cgi?id=15645 Thank you. I understood why this is happening from your explanation in the bug report.
Re: Is this a bug in std.typecons.Tuple.slice?
On Thursday, 4 February 2016 at 12:28:39 UTC, Saurabh Das wrote:
This code:
[...]
Update: Simplified, this also doesn't work:
void main()
{
import std.typecons;
auto tp = tuple(10, false, "hello");
auto u0 = tp.slice!(0, tp.length);
auto u1 = tp.slice!(1, tp.length);
auto u2 = tp.slice!(2, tp.length);
static assert(is(typeof(u0) == Tuple!(int, bool, string)));
static assert(is(typeof(u1) == Tuple!(bool, string)));
static assert(is(typeof(u2) == Tuple!(string)));
assert(u2[0] == "hello");
assert(u0[2] == "hello");
assert(u1[1] == "hello");// This fails
}
rdmd erasetype.d
core.exception.AssertError@erasetype.d(16): Assertion failure
Any ideas?
Is this a bug in std.typecons.Tuple.slice?
This code:
void main()
{
import std.typecons;
auto tp = tuple!("a", "b", "c")(10, false, "hello");
auto u0 = tp.slice!(0, tp.length);
auto u1 = tp.slice!(1, tp.length);
auto u2 = tp.slice!(2, tp.length);
static assert(is(typeof(u0) == Tuple!(int, "a", bool, "b",
string, "c")));
static assert(is(typeof(u1) == Tuple!(bool, "b", string,
"c")));
static assert(is(typeof(u2) == Tuple!(string, "c")));
assert(u2.c == "hello");
assert(u0.c == "hello");
assert(u1.c == "hello");// This assert fails. Why?
}
core.exception.AssertError@erasetype.d(16): Assertion failure
4 erasetype 0x000100ce8128
_d_assert + 104
5 erasetype 0x000100cd12fe void
erasetype.__assert(int) + 38
6 erasetype 0x000100cd12aa _Dmain
+ 250
7 erasetype 0x000100cf7297
D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv + 39
8 erasetype 0x000100cf71cf void
rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate()) + 55
9 erasetype 0x000100cf723c void
rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll() + 44
10 erasetype 0x000100cf71cf void
rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate()) + 55
11 erasetype 0x000100cf7121
_d_run_main + 497
12 erasetype 0x000100cd133f main +
15
13 libdyld.dylib 0x7fff8a1345c8 start
+ 0
14 ??? 0x 0x0 + 0
Why does 'u1' behave differently? I'm thinking it's a bug, but I
haven't worked much with tuples, so maybe I'm missing something?
Thanks,
Saurabh
Re: std.typecons.Proxy requires a nothrow destructor and toHash?
On Wednesday, 3 February 2016 at 12:10:01 UTC, Marc Schütz wrote: On Wednesday, 3 February 2016 at 10:16:56 UTC, Saurabh Das wrote: [...] It used to work in 2.066.1; bisecting points to this PR: https://github.com/D-Programming-Language/phobos/pull/3043 When bisecting between 2.066 and 2.067, there are other candidates: https://github.com/D-Programming-Language/phobos/pull/3042 https://github.com/D-Programming-Language/dmd/pull/4459 https://github.com/D-Programming-Language/druntime/pull/1188 Unlikely: https://github.com/D-Programming-Language/phobos/pull/3001 https://github.com/D-Programming-Language/phobos/pull/3043 https://github.com/D-Programming-Language/dmd/pull/4452 https://github.com/D-Programming-Language/dmd/pull/4463 Please file a bug report at: https://issues.dlang.org/enter_bug.cgi Oh, okay. Thanks! Bug report filed: https://issues.dlang.org/show_bug.cgi?id=15641
std.typecons.Proxy requires a nothrow destructor and toHash?
struct A
{
import std.stdio;
File f;
}
struct B
{
A a;
import std.typecons;
mixin Proxy!a;
}
rdmd proxytest.d:
/Library/D/dmd/src/phobos/std/typecons.d(5055): Error:
'proxytest.A.~this' is not nothrow
/Library/D/dmd/src/phobos/std/typecons.d(5050): Error: function
'proxytest.B.Proxy!(a).toHash' is nothrow yet may throw
Failed: ["dmd", "-v", "-o-", "proxytest.d", "-I."]
Why doesn't this work? Is it a requirement that a proxied struct
must have a nothrow destructor and toHash?
Re: How should I do object serialization?
On Thursday, 28 January 2016 at 04:27:31 UTC, Enjoys Math wrote: I'm not looking for anything advanced, just serialization of some of my own types (classes & structs). I've seen: http://wiki.dlang.org/Review/std.serialization However, I don't see std.serialization in my dmd source tree: v2.070.0-b2 So where is the /official/ home for D object serialization? Thanks. Give http://code.dlang.org/packages/cerealed a try.
Re: Speed of csvReader
On Thursday, 21 January 2016 at 17:10:39 UTC, data pulverizer
wrote:
On Thursday, 21 January 2016 at 16:01:33 UTC, wobbles wrote:
Interesting that reading a file is so slow.
Your timings from R, is that including reading the file also?
Yes, its just insane isn't it?
It is insane. Earlier in the thread we were tackling the wrong
problem clearly. Hence the adage, "measure first" :-/.
As suggested by Edwin van Leeuwen, can you give us a timing of:
auto records = File("Acquisition_2009Q2.txt", "r").byLine.map!(a
=> a.split("|").array).array;
Thanks,
Saurabh
Re: Speed of csvReader
On Thursday, 21 January 2016 at 14:32:52 UTC, Saurabh Das wrote:
On Thursday, 21 January 2016 at 13:42:11 UTC, Edwin van Leeuwen
wrote:
On Thursday, 21 January 2016 at 09:39:30 UTC, data pulverizer
wrote:
StopWatch sw;
sw.start();
auto buffer = std.file.readText("Acquisition_2009Q2.txt");
auto records = csvReader!row_type(buffer, '|').array;
sw.stop();
Is it csvReader or readText that is slow? i.e. could you move
sw.start(); one line down (after the readText command) and see
how long just the csvReader part takes?
Please try this:
auto records =
File("Acquisition_2009Q2.txt").byLine.joiner("\n").csvReader!row_type('|').array;
Can you put up some sample data and share the number of records
in the file as well.
Actually since you're aiming for speed, this might be better:
sw.start();
auto records =
File("Acquisition_2009Q2.txt").byChunk(1024*1024).joiner.map!(a
=> cast(dchar)a).csvReader!row_type('|').array
sw.stop();
Please do verify that the end result is the same - I'm not 100%
confident of the cast.
Thanks,
Saurabh
Re: Speed of csvReader
On Thursday, 21 January 2016 at 13:42:11 UTC, Edwin van Leeuwen
wrote:
On Thursday, 21 January 2016 at 09:39:30 UTC, data pulverizer
wrote:
StopWatch sw;
sw.start();
auto buffer = std.file.readText("Acquisition_2009Q2.txt");
auto records = csvReader!row_type(buffer, '|').array;
sw.stop();
Is it csvReader or readText that is slow? i.e. could you move
sw.start(); one line down (after the readText command) and see
how long just the csvReader part takes?
Please try this:
auto records =
File("Acquisition_2009Q2.txt").byLine.joiner("\n").csvReader!row_type('|').array;
Can you put up some sample data and share the number of records
in the file as well.
Re: Using std.conv.to with std.typecons.Typedef
On Monday, 11 January 2016 at 12:59:05 UTC, Tobi G. wrote: On Monday, 11 January 2016 at 12:15:55 UTC, Saurabh Das wrote: Any ideas? Yes. Because Typedef is introducing new Types, which csvReader doesn't know what they are, you'll need a little workaround and cast the values yourself. import std.csv, std.stdio, std.algorithm, std.range; enum csvTxt = "10, 20 30, 40 50, 50"; myStuff = csvTxt.csvReader!(Tuple!(long, long)) .map!(a => MyStuff(cast(QuestionId)a[0], cast(StudentId) a[1])) .array; The .map does nothing other as getting the information out of the Tuple 'a' and constructing a struct of the type MyStuff. togrue Yes that does make sense. I could read in a POD struct and convert it to a typed one. Though I was hoping for a more elegant solution... This'll have to do I guess. Thanks!
Re: Using std.conv.to with std.typecons.Typedef
On Monday, 11 January 2016 at 12:01:30 UTC, Tobi G. wrote:
On Monday, 11 January 2016 at 08:03:19 UTC, Saurabh Das wrote:
How can I get std.conv to understand std.typecons.Typedef?
You can do something like this:
QuestionId q = to!(TypedefType!QuestionId)("43");
In general, is there a better solution to orthogonal types
than Typedef?
Typedef is a reasonably solution, for this in my opinion.
togrue
Oh excellent. Yes that works for a standalone conversion. Do you
know how I can use this with std.csv?
import std.typecons;
alias QuestionId = Typedef!(long, long.init, "QuestionId");
alias StudentId = Typedef!(long, long.init, "StudentId");
struct MyStuff
{
QuestionId q;
StudentId s;
}
void main()
{
import std.csv, std.stdio, std.algorithm, std.range;
File("file.csv").byLine.joiner("\n").csvReader!(MyStuff)(null).array;
}
This doesn't work. But if MyStuff is defined as: struct MyStuff {
int q, s; }, then it works.
Any ideas?
Using std.conv.to with std.typecons.Typedef
I am trying to create 2 types which contain integral values but
should not be compatible with each other. std.typecons.Typedef
seems perfect for this:
alias QuestionId = Typedef!(long, long.init, "QuestionId");
alias StudentId = Typedef!(long, long.init, "StudentId");
However I'm failing to use using std.conv.to:
QuestionId q = to!QuestionId("34"); <-- gives compile errors
(This is a reduced example, the actual use case is to use std.csv
to read in a structure from file, which in turn calls to!xyz)
How can I get std.conv to understand std.typecons.Typedef? In
general, is there a better solution to orthogonal types than
Typedef?
Thanks,
Saurabh
Re: Segfault while compiling simple program
On Wednesday, 16 December 2015 at 10:07:38 UTC, Saurabh Das wrote:
On Wednesday, 16 December 2015 at 09:38:24 UTC, Ali Çehreli
wrote:
On 12/16/2015 01:26 AM, Saurabh Das wrote:
struct xlref
{
ushort rwFirst;
ushort rwLast;
ubyte colFirst;
ubyte colLast;
}
struct xlmref
{
ushort count;
xlref reflist;
}
Mac OS X (dmd 2.069.0)
===
dmd dprob.d
Segmentation fault: 11
Compiler bug. Please report at
https://issues.dlang.org/
Changing the order of the members of xlmref seems to be a
workaround:
struct xlmref
{
xlref reflist;
ushort count;
}
Ali
We are using it to communicate with Excel, so swapping it is
not an option.
I'll report it as a compiler bug. In the meantime, this is a
workaround worked for me:
struct xlref
{
ushort rwFirst;
ushort rwLast;
ubyte[2] cols;
}
Filed: https://issues.dlang.org/show_bug.cgi?id=15455
Under OS, I've selected Mac OS X since only 1 OS selection is
allowed. Is the convention to select 'Other' in cases where ICEs
are observed in multiple OSes?
Thanks,
Saurabh
Re: Segfault while compiling simple program
On Wednesday, 16 December 2015 at 09:38:24 UTC, Ali Çehreli wrote:
On 12/16/2015 01:26 AM, Saurabh Das wrote:
struct xlref
{
ushort rwFirst;
ushort rwLast;
ubyte colFirst;
ubyte colLast;
}
struct xlmref
{
ushort count;
xlref reflist;
}
Mac OS X (dmd 2.069.0)
===
dmd dprob.d
Segmentation fault: 11
Compiler bug. Please report at
https://issues.dlang.org/
Changing the order of the members of xlmref seems to be a
workaround:
struct xlmref
{
xlref reflist;
ushort count;
}
Ali
We are using it to communicate with Excel, so swapping it is not
an option.
I'll report it as a compiler bug. In the meantime, this is a
workaround worked for me:
struct xlref
{
ushort rwFirst;
ushort rwLast;
ubyte[2] cols;
}
Segfault while compiling simple program
struct xlref
{
ushort rwFirst;
ushort rwLast;
ubyte colFirst;
ubyte colLast;
}
struct xlmref
{
ushort count;
xlref reflist;
}
Mac OS X (dmd 2.069.0)
===
dmd dprob.d
Segmentation fault: 11
Windows (dmd 2.069.2)
==
dmd -v -m64 dprob.d
binary C:\D\dmd2\windows\bin\dmd.exe
version v2.069.2
config C:\D\dmd2\windows\bin\sc.ini
parse xlcall_wrap2
importall xlcall_wrap2
import object
(C:\D\dmd2\windows\bin\src\druntime\import\object.d)
semantic xlcall_wrap2
object.Error@(0): assert(0) or HLT instruction
0x0040496F
0x00404CF8
0x004CF2B6
0x004565A7
0x0044EAB0
0x004BF99E
0x74F757F9 in MultiByteToWideChar
0x76F2139E in RtlQueryProcessDebugInformation
0x76F21340 in RtlQueryProcessDebugInformation
0x76F21190 in RtlQueryProcessDebugInformation
What gives?
Saurabh
Re: Internal Compiler Error Help
On Thursday, 21 May 2015 at 14:12:25 UTC, Kagamin wrote: If you're looking for speed, how about ldc? Absolutely - we are working on getting it to compile on ldc and/or gdc.
Re: Internal Compiler Error Help
fair enough. I thought normally you'd want to have some sort of expression simplification in genetic programming, to avoid adding too many superfluous degrees of freedom? Aside from the obvious problems, those extra degrees of freedom can put you at risk of overfitting. Yes - our evaluation criteria gives bonus points for simpler expressions. We also strongly constrain the degrees of freedom. Both these aim to reduce overfitting. The expression seems rather complex because every division is protected by a equal to 0 check. Since our data sets are vast and number of features is kept low, overfitting is less of a concern. We do watch out for it though. In release builds, the compiler does the job of simplifying the expression, so we don't input a simplified expression a-priori. We are currently building this framework because earlier Java frameworks were deficient in speed. Already we have achieved a ~ 1000x speedup, so right now we are looking to consolidate and stabilise. In the next iteration, we could think of adding a simplify expression feature. Thanks, Saurabh
Re: Internal Compiler Error Help
PS: The original expression:
http://dpaste.dzfl.pl/raw/e7a66aa067ab
double someFunction(double AvgPriceChangeNormalized, double
DayFactor, double TicksTenMinutesNormalized)
{
return
AvgPriceChangeNormalized)*(0.0868))*((DayFactor)*(TicksTenMinutesNormalized)))*(((AvgPriceChangeNormalized)*(0.0868))*(TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)+(DayFactor)))==0)?(1):((TicksTenMinutesNormalized)/TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)+(DayFactor)==0)?(1):(((TicksTenMinutesNormalized)+(-0.865))/((TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)+(DayFactor)))==0)?(1):((TicksTenMinutesNormalized)/TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)+(DayFactor)))*(TicksTenMinutesNormalized;
}
Re: Internal Compiler Error Help
and please submit to https://issues.dlang.org Submitted: https://issues.dlang.org/show_bug.cgi?id=14613 That expression is, not to put too fine a point on it, mad. The operator precedence itself is giving me a headache, let alone the division of a double by a boolean... I'm pretty sure it doesn't do what you want it to, unless what you want is seriously weird. As a matter of fact, i'm pretty sure that expression evaluates to 1, irrelevant of the values of the two variables. s/irrelevant/irrespective/ The original expression was a candidate in a genetic programming population - a result of trial and error / "natural" selection over a few generations. The dustmite-reduced expression is really weird I agree - I don't know what to make of it. I've reported it as I found it. The otiginal expression is not so wierd, it just haphazardly long. It doesn't do any strange divides or compares. In either case, it shouldn't compile normally without the '-O' and fail to compile with it. We managed a 1000x speed up over Java on our genetic programming system by using D, but this compile failure is preventing us from using the release / optimised builds :(( Thanks, Saurabh
Re: Internal Compiler Error Help
Thanks!
Wow, dustmite is really useful. It reduces the expression down to:
double someFunction(double AvgPriceChangeNormalized, double
TicksTenMinutesNormalized)
{
return
(TicksTenMinutesNormalized?1:AvgPriceChangeNormalized)?1:TicksTenMinutesNormalized/(TicksTenMinutesNormalized==0)==0;
}
Which gives a compiler error: Internal error: backend/cod1.c 1562
Internal Compiler Error Help
Hello, We have been working on a genetic programming project, and occasionally the compiler fails and gives an internal error. I've captured and reduced one of these down to a single expression. See http://dpaste.dzfl.pl/e7a66aa067ab (reduced_expr.d) When I compile this file using: dmd -c -O reduced_expr.d It says: DMD 2.066.1] Internal error: backend/cod1.c 1562 DMD 2.067.1] Internal error: backend/cod1.c 1567 The compile succeeds without the '-O' flag. Am I correct in assuming that an internal error in the compiler should be filed as a bug report? As you can see, the expression is a massive ugly thing, as is often the case with genetic programming. I'd like to reduce this expression further before filing said bug report. I recall seeing a project on this forum which automatically figures out the simplest program which causes a compile failure. Can someone kindly point me to it? Thanks, Saurabh
