Re: best memory profiler (to debug accumulated allocation of each line) for D?
On Friday, 14 October 2022 at 19:06:12 UTC, rassoc wrote: On 10/14/22 20:45, mw via Digitalmars-d-learn wrote: Any suggestions? There's `dmd -profile=gc` or `dub build --build=profile-gc`. Thanks. I eventually use valgrind --tool=massif, and found the problem was in a underlying C library doing lots of small allocations.
Re: Generate a pointer to a method of a struct
On Saturday, 15 October 2022 at 00:31:47 UTC, Iain Buclaw wrote:
```
auto funcptr (alias method) ()
{
return &method;
}
:
fun = funcptr!bar;
:
```
Which works but neither dmd nor gdc were able to optimize the
additional function call away.
pragma(inline, true)
auto funcptr (alias method) ()
Thanks. Just found that
```
template funcptr (alias method) {
enum funcptr = &method;
}
```
works on both dmd and gdc. This gives rise to questions:
Is this code expected to compile and pass its unittest?
```
struct S {
void bar () { }
}
enum ei = &S.bar;
immutable i = &S.bar; // line 6
const c = &S.bar; // line 7
unittest {
import std.stdio;
writeln (ei);
writeln (i);
writeln (c);
}
```
gdc passes while dmd says:
```
$ dmd -unittest -main -run ini
ini.d(6): Error: non-constant expression `& bar`
ini.d(7): Error: non-constant expression `& bar`
```
Is this consistent?
Re: Can someone tell me what the compiler thought I was trying to do?
On Friday, 14 October 2022 at 22:17:52 UTC, H. S. Teoh wrote: Given that this particular trap crops up regularly, perhaps some sort of warning ought to be added. Once the @nodiscard DIP is accepted & implemented this should be easy to do. Seems like you're behind the times! The DIP was accepted and implemented with some changes: https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1038.md#final-review The summary in full: --- The language maintainers accepted this DIP with a request for changes: * rename `@noDiscard`, as they want to avoid adding additional negative attributes to the language. * address issues that arise from the feature's interaction with inheritance when applied to classes. * develop rules for handling covariance and contravariance when applied to functions. The DIP author addressed these requests by renaming the attribute to @mustuse and allowing it only on structs and unions. His rationale for the latter is described in the section, Design Goals and Possible Alternatives. The maintainers approved the author's changes and accepted the revised version of the DIP. ---
Re: Can someone tell me what the compiler thought I was trying to do?
On Friday, 14 October 2022 at 21:51:54 UTC, WhatMeWorry wrote: I lost about a half an hour troubleshooting some code of mine which as it turned out to be resolved with just one line. // paths.remove(i); // compiles fine but does nothing paths = paths.remove(i); // works - what I erroneously thought the previous line was doing Is the first line nonsensical and should the compiler have at least issued a warning? At the moment, no. You should have read the documentation of the function :-) Note that remove does not change the length of the original range directly; instead, it returns the shortened range. If its return value is not assigned to the original range, the original range will retain its original length, though its contents will have changed: You ignored the return value of a function you shouldn't have ignored. It's not practical for the compiler to warn every time you do that, as it currently can't know that you're *supposed* to use it. `@mustuse` was added to the language in 2.100.0 as an attribute for `struct` or `union`, but not yet for functions, as explained in the DIP: https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1038.md#mustuse-as-a-function-attribute If that ever gets expanded for use as a function attribute, then it can be used in situations like this so that you must use the return result. Until then, read the documentation!
Re: Generate a pointer to a method of a struct
On Friday, 14 October 2022 at 18:34:58 UTC, kdevel wrote:
dmd and gdc optimize the lambda invocations away. Nonetheless
the expression looks somewhat too big. To overcome this I tried
to generate the function pointer outside of the struct:
```
auto funcptr (alias method) ()
{
return &method;
}
:
fun = funcptr!bar;
:
```
Which works but neither dmd nor gdc were able to optimize the
additional function call away.
pragma(inline, true)
auto funcptr (alias method) ()
Re: Can someone tell me what the compiler thought I was trying to do?
On Fri, Oct 14, 2022 at 09:51:54PM +, WhatMeWorry via Digitalmars-d-learn wrote: > > I lost about a half an hour troubleshooting some code of mine which as it > turned out to be resolved with just one line. > > > // paths.remove(i); // compiles fine but does nothing > > paths = paths.remove(i); // works - what I erroneously thought the previous > line was doing > > Is the first line nonsensical and should the compiler have at least > issued a warning? Depending on what your range type was, it may not necessarily do *nothing* (it may mutate the range). But as Andrei put it, "range mutation functions change content, not topology". It *returns* the new "topology", i.e., the new range after the removal; so you need to assign it to the original range in order to keep it up-to-date. Given that this particular trap crops up regularly, perhaps some sort of warning ought to be added. Once the @nodiscard DIP is accepted & implemented this should be easy to do. T -- "I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you already said that." -- User-Friendly
Can someone tell me what the compiler thought I was trying to do?
I lost about a half an hour troubleshooting some code of mine which as it turned out to be resolved with just one line. // paths.remove(i); // compiles fine but does nothing paths = paths.remove(i); // works - what I erroneously thought the previous line was doing Is the first line nonsensical and should the compiler have at least issued a warning?
Re: library to solve the system of linear equations
On Friday, 14 October 2022 at 18:37:00 UTC, Sergey wrote: On Friday, 14 October 2022 at 17:41:42 UTC, Yura wrote: Dear All, I am very new to D, and it has been a while since I coded in anything than Python. I am using just notepad along with the gdc compiler. At the moment I need to solve the system of liner equations: A00*q0 + A01*q1 + A02*q2 ... = -V0 A10*q0 + A11*q1 + A12*q2 ... = -V1 ... Could someone please provide a quick d solution for this, including details on how to install the library & link it to the code? I do not need anything advanced, just the easiest option. I am sorry for too basic question, just want to check my idea quickly. Thank you! Firstly I will suggest to install dub - the D package manager. It will be easier to isntall other libraries using it. Install openblas in your Ubuntu system. After that you can create a new folder and type in terminal ``` dub init ``` The main part will be about "dependencies". Type "lubeck". After that you could check the example of the simple program here: https://github.com/kaleidicassociates/lubeck/blob/master/example/source/app.d It is exactly solving simple system of linear equations. Link to the package where you can find additional details and documentation: https://code.dlang.org/packages/lubeck Thank you! First, I installed dub on Linux. Then I installed both libopenblas-dev and libopenblas-base. After that I tried to initiate a new project via dub init. I tried to use the following dependency: "mir-algorithm". After I got dub.sdl file that contains at the end line: dependency "mir-algorithm" version="~>3.16.12" in the top of my el.d file I have: /+dub.sdl: dependency "mir-algorithm" version="~>3.16.12" +/ import std.stdio; import std.string; import std.conv; import std.exception : assertThrown; import std.math; import mir.ndslice; however, when I try to compile it (gdc el.d) it gives me the following error message: el.d:11:8: error: module ndslice is in file 'mir/ndslice.d' which cannot be read import mir.ndslice; ^ import path[0] = /usr/lib/gcc/x86_64-linux-gnu/8/include/d What am I doing wrong? Should I specify the library upon compilation? I am sorry, I am feeling I am asking too basic question. Thank you!
Re: best memory profiler (to debug accumulated allocation of each line) for D?
On 10/14/22 20:45, mw via Digitalmars-d-learn wrote: Any suggestions? There's `dmd -profile=gc` or `dub build --build=profile-gc`.
best memory profiler (to debug accumulated allocation of each line) for D?
Hi, With CPU profiler, we can see the accumulated run time of each function & line, I'm wondering if there is such a profiler for memory allocation? The reason I'm asking is because I suspect there are some small but repetitive memory allocation going on in the libraries (in C and D) I'm using which I do not have control (and no source available), but I want to find out where. I want to run on some test data, and get the memory allocation stats for each function (better for each line of code), so I can find out where the problem is. Any suggestions? Thanks.
Re: library to solve the system of linear equations
On Friday, 14 October 2022 at 17:41:42 UTC, Yura wrote: Dear All, I am very new to D, and it has been a while since I coded in anything than Python. I am using just notepad along with the gdc compiler. At the moment I need to solve the system of liner equations: A00*q0 + A01*q1 + A02*q2 ... = -V0 A10*q0 + A11*q1 + A12*q2 ... = -V1 ... Could someone please provide a quick d solution for this, including details on how to install the library & link it to the code? I do not need anything advanced, just the easiest option. I am sorry for too basic question, just want to check my idea quickly. Thank you! Firstly I will suggest to install dub - the D package manager. It will be easier to isntall other libraries using it. Install openblas in your Ubuntu system. After that you can create a new folder and type in terminal ``` dub init ``` The main part will be about "dependencies". Type "lubeck". After that you could check the example of the simple program here: https://github.com/kaleidicassociates/lubeck/blob/master/example/source/app.d It is exactly solving simple system of linear equations. Link to the package where you can find additional details and documentation: https://code.dlang.org/packages/lubeck
Generate a pointer to a method of a struct
Given a struct `S` with method `foo`: Any of these expressions
```
&foo
&S.foo
&.S.foo
```
when they occur inside the struct they represent a delegate and
not a function pointer. Is it okay to "extract" and use the
function pointer from the delegate in this way:
```
struct S {
void function () fp;
void foo ()
{
fp = (&bar).funcptr;
}
void bar ()
{
fp = (&foo).funcptr;
}
auto fun () // invocation helper
{
if (! fp)
fp = (&foo).funcptr;
void delegate () dg;
dg.ptr = &this;
dg.funcptr = fp;
return dg ();
}
}
unittest {
S s;
s.fun;
s.fun;
}
```
In [1] Walter suggested to use a "lambda function" which reads
(adopted to structs):
```
struct S {
:
void function (ref S) fp;
:
void foo () {
:
fun = function (ref S self) { return self.bar (); };
:
}
:
}
```
dmd and gdc optimize the lambda invocations away. Nonetheless the
expression looks somewhat too big. To overcome this I tried to
generate the function pointer outside of the struct:
```
auto funcptr (alias method) ()
{
return &method;
}
:
fun = funcptr!bar;
:
```
Which works but neither dmd nor gdc were able to optimize the
additional function call away. So I replaced the function call
with a value:
```
template funcptr (alias method) {
immutable funcptr = &method; // (*)
}
```
That code compiles under gdc 12.1 but I could not find any dmd
version which compiles the code. All say
```
ptrtomethod.d(15): Error: non-constant expression `& bar`
```
Line 15 is the line I marked with `(*)`. Any comments?
[1] https://www.digitalmars.com/articles/b68.html
Member Function Pointers in D
Re: library to solve the system of linear equations
On Friday, 14 October 2022 at 17:41:42 UTC, Yura wrote: Dear All, I am very new to D, and it has been a while since I coded in anything than Python. I am using just notepad along with the gdc compiler. [...] Did not try it, but the example for the function luSolve at the lubeck documentation website should be helpful: https://lubeck.dpldocs.info/v1.5.1/kaleidic.lubeck.luSolve.html
Re: library to solve the system of linear equations
On Friday, 14 October 2022 at 17:41:42 UTC, Yura wrote: ... Check out MIR https://github.com/libmir
library to solve the system of linear equations
Dear All, I am very new to D, and it has been a while since I coded in anything than Python. I am using just notepad along with the gdc compiler. At the moment I need to solve the system of liner equations: A00*q0 + A01*q1 + A02*q2 ... = -V0 A10*q0 + A11*q1 + A12*q2 ... = -V1 ... I have all my Aij coefficients in the double [][] A array, and V numbers in the array double [] b. Is there any quick D solution for it? Something like in python one can do: numpy.linalg.solve(a,b) ? Quick web search revealed a few scientific libraries for D like Mir or lubek. I am working under Ubuntu 18.04 and compiling my code like " gdc solv.d" Could someone please provide a quick d solution for this, including details on how to install the library & link it to the code? I do not need anything advanced, just the easiest option. I am sorry for too basic question, just want to check my idea quickly. Thank you!
Re: Float rounding (in JSON)
On Friday, 14 October 2022 at 09:00:11 UTC, Patrick Schluter wrote: On Thursday, 13 October 2022 at 19:27:22 UTC, Steven Schveighoffer wrote: On 10/13/22 3:00 PM, Sergey wrote: [...] It doesn't look really that far off. You can't expect floating point parsing to be exact, as floating point does not perfectly represent decimal numbers, especially when you get down to the least significant bits. [...] To me it looks like there is a conversion to `real` (80 bit floats) somewhere in the D code and that the other languages stay in `double` mode everywhere. Maybe forcing `double` by disabling x87 on the D side would yield the same results as the other languages? Looking through the source code then for floating points we call `parse!double` when parsing the json as a floating point. I don't see real being used anywhere when parsing. So if anything then it would have to be internally in parse or dmd. I haven't checked either yet.
Re: Float rounding (in JSON)
On Thursday, 13 October 2022 at 19:27:22 UTC, Steven Schveighoffer wrote: On 10/13/22 3:00 PM, Sergey wrote: [...] It doesn't look really that far off. You can't expect floating point parsing to be exact, as floating point does not perfectly represent decimal numbers, especially when you get down to the least significant bits. [...] To me it looks like there is a conversion to `real` (80 bit floats) somewhere in the D code and that the other languages stay in `double` mode everywhere. Maybe forcing `double` by disabling x87 on the D side would yield the same results as the other languages?
