Re: Using C header libs with importC
On Monday, 8 January 2024 at 21:56:10 UTC, Renato wrote: [snip] Importing .h files from d files isn't supported yet because of a dispute with the lookup priority: https://issues.dlang.org/show_bug.cgi?id=23479 https://issues.dlang.org/show_bug.cgi?id=23547 Ah, too bad. Anyway, I was just playing around... disappointing that it doesn't work but I don't really need this for now. Disappointing I know, but there is the workaround of creating a C file and included the h file in it. Not elegant though.
Re: Symbolic computations in D
On Monday, 30 October 2023 at 13:24:56 UTC, Sergey wrote: On Monday, 30 October 2023 at 13:13:47 UTC, jmh530 wrote: On Sunday, 29 October 2023 at 10:44:03 UTC, ryuukk_ wrote: Julia is more an alternative to R, Matlab, Python than C++. Not really. Many especially popular and widely used (NumPy, PyTorch, data.table) libraries for R and Python implemented with C/C++. Without using them, it is just impossible to get good performance. So there is "2 language" problem. Someone should create C++ engine + Python/R interface. Julia propose to solve this issue - since you are able to implement fast engine and interface both in Julia. There are aspects of Julia that are certainly nice. I'm just saying that most users of Julia would be more likely to use that instead R/Matlab/Python, rather than instead of C++. There are probably many areas where with R or Python, you would normally implement it with C or C++, whereas with Julia you could probably do just as well with raw Julia. However, that's not to say that Julia doesn't also rely on that same approach when it is beneficial. For instance, it can use standard BLAS/LAPACK libraries [1] for linear algebra that are written in C. There's nothing really wrong with that. They shouldn't re-write the wheel if there is already a highly performant solution. [1] https://docs.julialang.org/en/v1/stdlib/LinearAlgebra/
Re: Symbolic computations in D
On Sunday, 29 October 2023 at 10:44:03 UTC, ryuukk_ wrote: [snip] This is sad that people recommend OOP for this Julia doesn't have OOP and it took over, and that's what i'd recommend your students to check, C++ is a dead end, Julia it is for mathematical computing If D had tagged union and pattern matching, it would be a great candidate to succeed in that field Julia is more an alternative to R, Matlab, Python than C++.
Re: Visual Studio 2022 no longer debugs D program, need an alternative debugger for Windows
On Saturday, 26 August 2023 at 16:57:42 UTC, solidstate1991 wrote: After a recent update, Visual Studio 2022 started to have serious troubles with D, namely having troubles with displaying debug variables, and growing constantly in memory until you either stop debugging or crashes Windows. Currently I'm resorting to use x64dbg, which is currently the best I can use, and I'll try to look up some info on using it not as a reverse engineer tool, but as an actual debugger. You should report this to bugzilla.
Re: Mir-algorithm tutorial?
On Friday, 18 August 2023 at 12:14:45 UTC, Ferhat Kurtulmuş wrote: On Friday, 18 August 2023 at 09:57:11 UTC, Ki Rill wrote: [...] Yes there isn't many guides around. Those are some of them. https://tastyminerals.github.io/tasty-blog/dlang/2020/03/22/multidimensional_arrays_in_d.html https://jackstouffer.com/blog/nd_slice.html Also this piece of code was converted from python-numpy to d-mir. https://github.com/libmir/dcv/blob/master/source/dcv/imgproc/threshold.d#L138 I converted many more from python for DCV. I think the main problem is the mir libraries won't get updates since Ilya recently said that he was not an open source developer anymore. He has said to me he will support them for some time, but won’t be adding new features, or something like that.
Re: Mir-algorithm tutorial?
On Friday, 18 August 2023 at 08:06:10 UTC, Ki Rill wrote: On Friday, 18 August 2023 at 07:57:05 UTC, Ki Rill wrote: On Friday, 18 August 2023 at 07:54:04 UTC, Ki Rill wrote: Is there an up-to-date tutorial? It's just painful that I cannot find anything helpful on this topic. The official mir-algorithm GitHub repo links to articles with old code that won't build if I copy-paste it. I'm left hunting down the changes and guessing how things should really work. [API documentation](http://docs.algorithm.dlang.io) link about mir-algorithm from [dlang tour](https://tour.dlang.org/tour/mir/dub/mir-algorithm) does not work. I opened the [issue](https://github.com/dlang-tour/core/issues/788). I think the issue with dlang tour is unrelated to mir-algorithm.
Re: std.sumtyp and option ?
On Thursday, 29 June 2023 at 14:18:05 UTC, kiriakov wrote:
How to create option type over std.sumtype ?
```
enum None;
struct Some(T) { T x; }
alias Option = SumType!(Some!T, None);
```
I get
Error: undefined identifier `T`
Try
```d
alias Option(T) = SumType!(Some!T, None);
```
Your version of `Option` isn't a template, so it doesn't know
what `T` is. This version uses the eponymous template syntax for
aliases.
Re: Best way to use C library
On Friday, 19 May 2023 at 18:31:45 UTC, Maximilian Naderer wrote: Hello guys, So what’s currently the best way to use a big C library? Let’s assume something like cglm assimp glfw ImportC doesn’t really work for such huge libraries, I’ll investigate further. Deimos is outdated or there are no bindings. I know that there is a dub package for glfw which works fine. But how would I do something for assimp or cglm. The dub assimp package is quite outdated. Am I stuck with manually creating interface files either by hand or automation? I’m hope somebody could give me some insights. Thank you ! Kind regards from Austria Max If there are issues using those libraries, you should report the bugs.
Re: Any working REPL program on windows? DREPL doesn't compile
On Thursday, 23 March 2023 at 11:46:48 UTC, matheus wrote: On Thursday, 23 March 2023 at 09:39:40 UTC, John Xu wrote: Anybody know any working REPL program? I failed to find a working one. https://github.com/dlang-community/drepl can't compile on my Windows 10, dub reports: ... According to their Readme: Supported OS Works on any OS with full shared library support by DMD (currently linux, OSX, and FreeBSD). Matheus. OP, would you be able to try using drepl with Windows Subsystem for Linux (WSL) and reporting back? There's a lot of value in getting drepl working on Windows (I believe DMD shared library support needs to be improved, not sure also whether drepl would work with other D compilers) and in good enough shape to be used with Jupyter. Unfortunately, it's beyond my skills set to contribute to this effort and the only way things like this get completed is if people are willing and able to work on them. That being said, I also get a lot of use out of run.dlang.io for trying out small ideas. It's not a Jupyter replacement, but the way it is working now significantly reduces my need for something like Jupyter. What it can't handle is if you have some project locally that you want to import. So long as you're just trying something out that uses a few well known set of D projects, it works well.
Re: Preventing the Compiler from Optimizing Away Benchmarks
On Monday, 13 March 2023 at 15:23:25 UTC, user1234 wrote:
[snip]
[1]
https://theunixzoo.co.uk/blog/2021-10-14-preventing-optimisations.html
that's illegal code. You mix GCC/LLVM syntax with D asm block
and the front-end wont recognize that.
LDC recognizes a syntax similar to what is described in your
link, see
https://wiki.dlang.org/LDC_inline_assembly_expressions. GDC has
it too (since that the syntax invented by GCC in first place)
but I cant find the documentation ATM.
Thanks, that helps. Below seems to be working...(with LDC and -O)
when I include the DoNotOptimize, it takes around 300-500us, but
when I comment it out, then it takes about 5us. It would still
take some work to figure out how to get it to work with DMD.
```d
void DoNotOptimize(T)(T* ptr)
{
import ldc.llvmasm;
import core.volatile: volatileLoad;
T value = volatileLoad(ptr);
__asm("", "*mr,~{memory}", , );
}
void main() {
import std.algorithm.iteration: sum;
import std.array: uninitializedArray;
import std.datetime.stopwatch;
import std.random: uniform;
import std.stdio: writeln;
auto testData = uninitializedArray!(long[])(600_000);
foreach(ref el; testData) el = uniform(0, 10);
ulong seed = 0;
ulong output = 0;
StopWatch sw;
sw.start();
DoNotOptimize();
output = testData.sum(seed);
DoNotOptimize();
sw.stop();
writeln("time: ", sw.peek);
}
```
Preventing the Compiler from Optimizing Away Benchmarks
I was looking at [1] for ways to prevent the compiler from
optimizing away code when trying to benchmark.
It has the following C++ code as a simpler version:
```
inline BENCHMARK_ALWAYS_INLINE void DoNotOptimize(Tp& value) {
asm volatile("" : "+r,m"(value) : : "memory");
}
```
I made an attempt to make a D version of it, but failed.
Apparently DMD doesn't like the `""` in the first part of the asm
instruction. I'm also not sure the `volatileLoad` command is
right, but I didn't know of any other way to have volatile work
in D (and I couldn't figure out how it actually worked from
looking at the code).
```
void DoNotOptimize(T)(T* ptr)
{
import core.volatile: volatileLoad;
T value = volatileLoad(ptr);
asm {"" : "+r,m"(value) : : "memory";}
}
```
[1]
https://theunixzoo.co.uk/blog/2021-10-14-preventing-optimisations.html
Re: dub.selections.json & optional dependencies: How's it work?
On Friday, 24 February 2023 at 19:37:41 UTC, Steven Schveighoffer wrote: On 2/24/23 2:01 PM, jmh530 wrote: I'm looking at the dub package format [1] about optional dependencies and it says: "With this set to true, the dependency will only be used if explicitly selected in dub.selections.json. If omitted, this attribute defaults to false." And it occurs to me that I don't know anything about how dub.selections.json works. Let's say you have dependency A, which has an *optional* dependency on B. In your project, if you depend on A, but don't explicitly depend on B, then A will be built without B as a dependency. If you have a dependency on A *and* B, then B's optional dependency will kick in, and participate in the selection of it's version. So for instance, you could depend on B version 1 or higher, and the optional dependency could be on v1.5 or higher, it will select the highest version of 1.5 dub.selections.json only applies to the primary project. So the decision on which versions of which dependencies to use is decided by the whole tree. -Steve Ok this makes sense. So it's all about dependencies downstream. For instance, if I list B as a dependency in my project but never use it in my own project, it will still compile in (so for instance if A's functionality differs depending on if B is included, then I will get that functionality even if I don't use B directly in my project).
dub.selections.json & optional dependencies: How's it work?
I'm looking at the dub package format [1] about optional dependencies and it says: "With this set to true, the dependency will only be used if explicitly selected in dub.selections.json. If omitted, this attribute defaults to false." And it occurs to me that I don't know anything about how dub.selections.json works. I would think dub optional dependencies work such that if there are no functions being called/compiled that import an optional dependency, then the dependency wouldn't be included. How is it different from `dmd -i`? The dub.selections.json in some of my projects look like a listing of the dependencies and their versions. Above should imply that the optional dependency would only get included there if the import is actually used somewhere in the project. Is that correct? [1] https://dub.pm/package-format-json.html
Combining Templates While Minimizing Bloat
The code below has two `foo` functions that take slices, one
accepts a const(T)* iterator and one accepts a generic Iterator
with the property that the slice isn't convertible to the first
one. The nice thing about this is that if you pass it with a
double* or const(double)*, then it doesn't increase template
bloat. The problem, however, is that I have to either have two
implementations or a separate `fooImpl` function to implement the
desired functionality. Is there any way to combine together the
`foo` functions in a way that maintains the template bloat
reducing behavior of the first function?
The example below uses mir, but it just as easily could be
adapted to other types.
```d
/+dub.sdl:
dependency "mir-algorithm" version="*"
+/
import std.stdio: writeln;
import mir.ndslice.slice;
void foo(T)(Slice!(const(T)*, 1) x)
{
writeln("here");
writeln("Iterator = ", typeid(IteratorOf!(typeof(x;
}
void foo(Iterator)(Slice!(Iterator, 1) x)
if (!is(Iterator : const(U)*, U))
{
writeln("there");
writeln("Iterator = ", typeid(IteratorOf!(typeof(x;
}
void main()
{
double[] x = [1.0, 2, 3];
auto y = x.sliced;
auto z = y.toConst;
foo(y); //prints "here" and "Iterator=const(double)*"
foo(z); //prints "here" and "Iterator=const(double)*"
auto a = y / 6;
foo(a); //prints "there" and "Iterator=(some long template
text)"
}
```
I tried something like
```d
void foo(Iterator)(Slice!(const Iterator, 1) x) {}
```
but this isn't a valid mir iterator since it becomes
const(double*) (a const pointer to a const double). What I need
is const(double)* (a mutable pointer to a const double).
Re: Assign to Array Column
On Wednesday, 1 February 2023 at 13:14:47 UTC, Siarhei Siamashka
wrote:
On Tuesday, 31 January 2023 at 01:04:41 UTC, Paul wrote:
Greetings,
for an array byte[3][3] myArr, I can code myArr[0] = 5 and
have:
5,5,5
0,0,0
0,0,0
Can I perform a similar assignment to the column? This,
myArr[][0] = 5, doesn't work.
This works fine for small arrays, but for large arrays such
access pattern is cache unfriendly. It's usually best to
redesign the code to avoid assignments to columns if possible
(for example, by working with a transposed array). The language
is not providing a convenient shortcut for something that is
usually undesirable and expensive. And I think that this is
actually reasonable.
If the code is slow, then profile and try to speed up parts that
need it. The slowness may be due to a problem like this, but not
always.
The OP could also try mir's slices.
```d
/+dub.sdl:
dependency "mir-algorithm" version="*"
+/
import mir.ndslice.fuse;
import std.stdio: writeln;
void main() {
auto x = [[0, 0, 0], [0, 0, 0]].fuse;
x[0, 0 .. $] = 5;
x[0 .. $, 1] = 5;
writeln(x);
}
```
Re: Solving optimization problems with D
On Sunday, 1 January 2023 at 22:00:29 UTC, max haughton wrote: On Sunday, 1 January 2023 at 21:11:06 UTC, Ogi wrote: I’ve read this [series if articles](https://www.gamedeveloper.com/design/decision-modeling-and-optimization-in-game-design-part-1-introduction) about using Excel Solver for all kinds of optimization problems. This is very neat, but of course, I would prefer to write models with code instead, preferably in D. I glanced at mir-optim but it requires knowledge of advanced math. Is there something more approachable for a layperson? What do you want to optimize? Optimization in general requires reasonably advanced mathematics, whereas a single problem can be simplified. There are a lot of C libraries too that you can call from D for optimization too, but like Max says knowing what you want to optimize helps a lot. Excel’s optimizer works for small problems but chokes if the dimension increases too much.It is probably some sort of nonlinear gradient free solver.
Re: Idiomatic D using GC as a library writer
On Sunday, 4 December 2022 at 23:25:34 UTC, Adam D Ruppe wrote: On Sunday, 4 December 2022 at 22:46:52 UTC, Ali Çehreli wrote: That's way beyond my pay grade. Explain please. :) The reason that the GC stops threads right now is to ensure that something doesn't change in the middle of its analysis. [snip] That's a great explanation. Thanks.
Re: Hipreme's #4 Tip of the day - Don't use package.d
On Friday, 4 November 2022 at 19:17:04 UTC, Adam D Ruppe wrote: On Friday, 4 November 2022 at 19:10:33 UTC, jmh530 wrote: If you don't plan to use private(package_name), then I don't know what the point of it is. This works fine without the package.d anyway. Oh really, then what's the point of package.d?
Re: Hipreme's #4 Tip of the day - Don't use package.d
On Friday, 4 November 2022 at 16:56:59 UTC, Hipreme wrote: [snip] You can use any name instead. The only difference between an ordinary source file and a package.d is the module name. For instance, if you're inside the filesystem directory, you can change the name to literally anything and import instead. To make my engine's names unique I have been using a convention for the package.d names as an abbreviation of the directory name plus `definitions` or something like that. If you don't plan to use private(package_name), then I don't know what the point of it is.
Re: Catching C errors
On Thursday, 20 October 2022 at 11:59:45 UTC, data pulverizer wrote: [snip] Mine is also private for now till it reaches an acceptable state when I'll think about whether it should be publicly released or jealously guarded. It's a project I'm building for my own use really. It can't hurt to publicly release (when ready) so that other users work through any kinks.
Re: library to solve the system of linear equations
On Monday, 17 October 2022 at 19:54:12 UTC, Yura wrote: Dear All, Thank you so much for your replies and hints! I got it working today. All the libraries are properly linked and the Equation solver runs smoothly. The compilers turned out to be problematic though. The "Mir" library does not work with the Ubuntu 18.04 gdc and ldc compilers. I have managed to install the latest version dmd, and it works. But I suspect that the dmd compiler is not optimal in terms of performance. The question becomes whether it is possible to install the most recent ldc and gdc compilers on Ubuntu 18.04? [snip] If you have a problem with support for mir, submit a bug report. I don't think gdc is supported, but ldc should be.
Re: csvReader: how to read only selected columns while the class Layout has extra field?
On Sunday, 2 October 2022 at 21:18:43 UTC, mw wrote: [snipping] A CSV library should consider all the use cases, and allow users to ignore certain fields. In R, you have to force `NULL` for `colClasses` for the other columns. In other words, the user has to know the number of columns of the csv file in order to be able to skip them. https://stackoverflow.com/questions/29332713/how-to-skip-column-when-reading-csv-file
Re: Best way to read CSV data file into Mir (2d array) ndslice?
On Wednesday, 21 September 2022 at 13:08:14 UTC, jmh530 wrote:
On Wednesday, 21 September 2022 at 05:31:48 UTC, mw wrote:
Hi,
I'm just wondering what is the best way to read CSV data file
into Mir (2d array) ndslice? Esp. if it can parse date into
int/float.
I searched a bit, but can't find any example.
Thanks.
It probably can't hurt to try the simplest approach first.
`std.csv` can return an input range that you can then use to
create a ndslice. Offhand, I don't know what D tools are an
alternative to `std.csv` for reading CSVs.
ndslice assumes homogenous data, but you can put the Dates (as
Date types) as part of the labels (as Data Frames). However,
there's a bit to be desired in terms of getting that
functionality integrated into the rest of the package [1].
[1] https://github.com/libmir/mir-algorithm/issues/426
I just tried doing it with `std.csv`, but my version was a bit
awkward since it doesn't seem quite so straightforward to just
take the result of csvReader and put it in a array. I had to read
it in there. I also wanted to allocate the array up front, but to
do that I needed to know how big it was and ended up doing two
passes on reading the data, which isn't ideal.
```d
import std.csv;
import std.stdio: writeln;
import mir.ndslice.allocation: slice;
void main() {
string text =
"date,x1,x2\n1/31/2010,65,2.5\n2/28/2010,123,7.5";
auto records_firstpass = text.csvReader!double(["x1","x2"]);
auto records_secondpass = text.csvReader!double(["x1","x2"]);
size_t len = 0;
foreach (record; records_firstpass) {
len++;
}
auto data = slice!double(len, 2);
size_t i = 0;
size_t j;
foreach (record; records_secondpass)
{
j = 0;
foreach (r; record) {
data[i, j] = r;
j++;
}
i++;
}
writeln(data);
}
```
Re: Best way to read CSV data file into Mir (2d array) ndslice?
On Wednesday, 21 September 2022 at 05:31:48 UTC, mw wrote: Hi, I'm just wondering what is the best way to read CSV data file into Mir (2d array) ndslice? Esp. if it can parse date into int/float. I searched a bit, but can't find any example. Thanks. It probably can't hurt to try the simplest approach first. `std.csv` can return an input range that you can then use to create a ndslice. Offhand, I don't know what D tools are an alternative to `std.csv` for reading CSVs. ndslice assumes homogenous data, but you can put the Dates (as Date types) as part of the labels (as Data Frames). However, there's a bit to be desired in terms of getting that functionality integrated into the rest of the package [1]. [1] https://github.com/libmir/mir-algorithm/issues/426
Re: plot api
On Wednesday, 14 September 2022 at 19:34:56 UTC, Alain De Vos wrote: Let's say i want to plot the function f(x)=sin(x)/x. Which API would you advice, in order for me to not re-invent the wheel. Have you tried ggplotd? https://code.dlang.org/packages/ggplotd
Re: C function taking two function pointers that share calculation
On Wednesday, 14 September 2022 at 18:02:07 UTC, JG wrote: [snip] Maybe others know better but I would have thought the only way is to use globals to do this. Often c libraries that I have used get round this by taking a function and a pointer and then the library calls your function on the pointer simulating a d delegate. The C function does make use of a pointer to some data (that I neglected to mention), but your comment gives me an idea. Thanks.
C function taking two function pointers that share calculation
There is a C library I sometimes use that has a function that
takes two function pointers. However, there are some calculations
that are shared between the two functions that would get pointed
to. I am hoping to only need to do these calculations once.
The code below sketches out the general idea of what I've tried
so far. The function `f` handles both of the calculations that
would be needed, returning a struct. Functions `gx` and `gy` can
return the field of the struct that is relevant. Both of them
could then get fed into the C function as function pointers.
My concern is that `f` would then get called twice, whereas that
wouldn't be the case in a simpler implementation (`gx_simple`,
`gy_simple`). ldc will optimize the issue away in this simple
example, but I worry that might not generally be the case.
How do I ensure that the commonCalculation is only done once?
```d
struct Foo
{
int x;
int y;
}
Foo f(int x, int a)
{
int commonCalculation = a * x;
return Foo(commonCalculation * x, 2 * commonCalculation);
}
int gx(int x, int a) { return f(x, a).x;}
int gy(int x, int a) { return f(x, a).y;}
//int gx_simple(int x, int a) { return a * x * x;}
//int gy_simple(int x, int a) { return 2 * a * x;}
void main() {
import core.stdc.stdio: printf;
printf("the value of x is %i\n", gx(3, 2));
printf("the value of y is %i\n", gy(3, 2));
}
```
Re: Function attribute best practices
On Monday, 12 September 2022 at 16:39:14 UTC, Paul Backus wrote: [snip] Yes. Except for `@trusted`, explicit attributes on template code are a smell. [snip] If I can be 100% sure that something will always be @safe/nothrow/pure/@nogc, then I might consider marking them as such. For instance, a function that takes any floating point type, does some calculation, and then returns it. I figure it is documented for the user and at least this will save the compiler the effort of figuring it. If I can't, then I don't.
Re: importC and cmake
On Wednesday, 7 September 2022 at 00:31:53 UTC, zjh wrote: On Tuesday, 6 September 2022 at 19:44:23 UTC, jmh530 wrote: . `xmake` is simpler. Ok...but I didn't write the library so I can't exactly tell them to use xmake when they already use cmake.
importC and cmake
I was thinking about trying out importC with a library I have used in the past (it's been a few years since I used it with D). The library uses cmake to generate static or dynamic libraries (I believe I did static with Windows and dynamic with Linux, but I can't really recall). My understanding of cmake is that it is used to generate the files needed to build something in a cross-platform kind of way (so make files for linux, project files for Visual studio, etc.). This doesn't seem consistent with how importC works (which would be using a D compiler to compile the project). I suppose I could just try it and see if it works, but since the project uses cmake I wonder if there aren't potentially things that cmake is doing that are important and could get missed in this naive sort of approach (for instance, it has a way to use algorithms written in C++ by default, though they can be disabled in the cmake file). Does anyone have any importC experience with libraries that are built with a tool like cmake that could help make this clearer?
Re: Implicit integer conversions Before Preconditions
On Tuesday, 24 May 2022 at 21:05:00 UTC, Steven Schveighoffer
wrote:
[snip]
```d
// e.g.
foo(int x)
in (x >= 0)
{
return foo(uint(x));
}
```
And remove those useless `in` conditions on the unsigned
versions, an unsigned variable is always >= 0.
-Steve
Thanks. That makes perfect sense. I just got thrown by the
preconditions not running first.
Implicit integer conversions Before Preconditions
In the code below, `x` and `y` are implicitly converted to `uint`
and `ushort` before the function preconditions are run.
Is there any way to change this behavior? It feels unintuitive
and I can't find in the spec where it says when the conversions
in this case occur, but it clearly happens before the
preconditions are run.
```d
import std.stdio: writeln;
void foo(uint x)
in (x >= 0)
{
writeln(x);
}
void foo(ushort x)
in (x >= 0)
{
writeln(x);
}
void main() {
int x = -1;
foo(x); //prints 4294967295
short y = -1;
foo(y); //prints 65535
}
```
Re: What are (were) the most difficult parts of D?
On Thursday, 12 May 2022 at 15:32:24 UTC, Adam D Ruppe wrote: On Thursday, 12 May 2022 at 15:18:34 UTC, jmh530 wrote: What's the difference between a Type and Type Identifier? The is expression roughly follows variable declaration style. You write int a; to declare a new symbol named `a` of type `int`. Similarly, static if(is(T a)) declares a new symbol of type `a` if `T` is a valid type. (Of course, in this case, a and T are aliases of each other, so it isn't super useful, but in the more complex matches using the == and : operators, it might be different.) The Identifier is optional. Ah, yeah I know about that.
Re: What are (were) the most difficult parts of D?
On Thursday, 12 May 2022 at 12:13:32 UTC, Basile B. wrote: [snip] ``` is ( Type : TypeSpecialization , TemplateParameterList ) is ( Type == TypeSpecialization , TemplateParameterList ) is ( Type Identifier : TypeSpecialization , TemplateParameterList ) is ( Type Identifier == TypeSpecialization , TemplateParameterList ) ``` I never remember those variants, because basically you never need them... They were required for std.traits and that's it. What's the difference between a Type and Type Identifier?
Re: What are (were) the most difficult parts of D?
On Wednesday, 11 May 2022 at 09:06:52 UTC, bauss wrote: On Wednesday, 11 May 2022 at 05:41:35 UTC, Ali Çehreli wrote: What are you stuck at? What was the most difficult features to understand? etc. To make it more meaningful, what is your experience with other languages? Ali dip1000 Ha, I just mentioned this on another thread... https://dlang.org/spec/function.html#ref-return-scope-parameters
Re: Including C sources in a DUB project
On Tuesday, 10 May 2022 at 20:50:12 UTC, Alexander Zhirov wrote: On Tuesday, 10 May 2022 at 19:13:21 UTC, Dennis wrote: It has an example directory: https://github.com/dlang/dub/tree/master/examples And if there are two compilers in the system - `dmd` and `ldc`, which compiler chooses `dub.json`? And how do I specify the specific compiler I want? Following the command line documentation [1], you can use the --compiler option to select which to use. You can make the dub.json do different things depending on the target and/or compiler, but the default works fine regardless if you're doing something simple. https://dub.pm/commandline.html
Re: Including C sources in a DUB project
On Tuesday, 10 May 2022 at 19:13:21 UTC, Dennis wrote: [snip] It has an example directory: https://github.com/dlang/dub/tree/master/examples If your configuration is missing, you could make a Pull Request to add it. So it does. Thanks. We might also link to that on the dub.pm website.
Re: Including C sources in a DUB project
On Monday, 9 May 2022 at 09:17:06 UTC, Alexander Zhirov wrote: [snip] It would be nice if dub included a directory of example configurations for common issues like this.
Re: Compile delegate with enum into proper function?
On Sunday, 8 May 2022 at 03:58:06 UTC, Tejas wrote: [snip] If there is only one possible value for the overload, is there an issue with using default arguments? [snip] Default arguments are intended to be resolved at runtime. That is, if you compile a function with two parameters and one of them has a default, then the compiler will compile one function that has two parameters as inputs. However, since `foo` above is a relatively simple function, if you compile with -O, then it gets inlined. It doesn't matter so much that whether `a` is an enum or a literal since the compiler knows what it is at compile time and will inline it to remove the call to `foo` anyway. I am interested in more complex cases where the compiler isn't able to inline the function and where the behavior of the second parameter might be more significant. The default parameter would then be doing the calculation at runtime when ideally may be known at compile-time and the compiler could generate a separate function that is simpler taking only one parameter.
Re: Compile delegate with enum into proper function?
On Saturday, 7 May 2022 at 23:30:37 UTC, Paul Backus wrote:
[snip]
Worth noting that you *can* write
```d
alias foo = partial!(foo, a);
```
...which will add the partially-applied version to `foo`'s
overload set.
You sure about that? Below fails to compile on godbolt with ldc
1.27.1 [1]. For some reason run.dlang.org is just hanging...
```d
import core.stdc.stdio: printf;
import std: partial;
int foo(int x, int a) {
return x + a;
}
enum int a = 2;
alias foo = partial!(foo, a);
void main() {
int x = 2;
int y = foo(x, a);
printf("the value of y is %i", y);
auto z = foo(x);
printf("the value of z is %i", z);
}
```
[1] https://d.godbolt.org/z/dx8aWfjYW
Re: Compile delegate with enum into proper function?
On Saturday, 7 May 2022 at 18:46:03 UTC, Paul Backus wrote:
On Saturday, 7 May 2022 at 18:36:40 UTC, jmh530 wrote:
In the code below, there is a two parameter function `foo` and
an override of it with only one parameter. In the override
case, I force the second one to be 1, but ideally there should
be a way to specify it at compile-time.
Have you tried [`std.functional.partial`][1]? Using it, your
example could be written like this:
```d
import std.functional: partial;
enum int a = 1;
alias foo2 = partial!(foo, a);
```
[snip]
Thanks. This is basically equivalent to
```d
int foo(int a)(int x) { return x + a; }
alias foo2 = foo!a;
```
The downside is that you wouldn't be able to `alias foo = foo!a`.
Another approach would be to do something like
```d
int foo(int b = a)(int x) { return x + b; }
```
so that the default case could be handled.
Compile delegate with enum into proper function?
In the code below, there is a two parameter function `foo` and an
override of it with only one parameter. In the override case, I
force the second one to be 1, but ideally there should be a way
to specify it at compile-time.
It would be kind of nice to be able to do it with an enum and a
delegate or something, perhaps like `foo2`. However, that is
still generating a delegate. Something like `foo3` also works,
but I can't create that within a main function like I can for the
delegate.
I suppose the question is why can't I tell the compiler to
compile a delegate into a proper function? I suppose this also
holds for a function pointer. The difference I suppose is that
the delegate with enums isn't really taking advantage of the
features of a delegate, at least as far as I can tell.
```d
int foo(int x, int a) {
return x + a;
}
int foo(int x) {
return x + 1;
}
enum int a = 1;
auto foo2 = (int x) => {foo(x, a)};
int foo3(int x) {
return x + a;
}
```
Re: DMD failed with exit code -1073741819
On Tuesday, 3 May 2022 at 19:03:56 UTC, Dennis wrote:
On Tuesday, 3 May 2022 at 18:22:49 UTC, jmh530 wrote:
Does anyone have any idea what causes these types of errors?
Sounds like a stack overflow, maybe your code has a
complex/recursive part that makes DMD's call stack very deep.
Thanks. I think this was it. I figured it out, but it took a bit
of time to identify where the problem was coming from...
Basically, I started out with a template like
```d
template foo(T, U u = val, V, W) {}
```
and refactored it to
```d
template foo(T, U u = val, V, W, U y = u) {}
```
which is when I started getting the problem, but I had changed a
bunch of other stuff to introduce `y`, so it wasn't entirely
clear why that would cause the problems.
Anyway, changing it to
```d
template foo(T, U u = val, V, W, U y = val) {}
```
made the problem went away.
DMD failed with exit code -1073741819
I made some changes to some code I'm working on and now there are some lines that are giving me funky DMD error codes (I can tell it is some lines because I comment them out and the errors go away). So for instance, one line I have a static assert that gives an error code -1073741819, but if I split it up into two pieces (so that part of it is assigned to a value and then I use typeof that value in the static assert), then DMD does not complain. Does anyone have any idea what causes these types of errors? I was leaning towards it being something related to running out of memory or something, but I'm using dub and I've tried turning on and off "lowmem". I also have used -v both in dflags and at the command line and haven't noticed any obvious errors.
Re: Is there a way to not escape slashes when parsing JSON?
On Tuesday, 22 February 2022 at 00:36:38 UTC, bachmeier wrote: [snip] Yes. std.random is another. I gave up out on the current one. Luckily I already had external libraries for that before I started using D. Have you tried mir.random?
Re: Strange behavior of iota
On Wednesday, 16 February 2022 at 19:35:00 UTC, jmh530 wrote: [snip] Step 1: In the integral overloads, use allSatisfy!(isSigned, B, E) || allSatisfy!(isUnsigned, T, U) for the current behavior Step 2: When !(allSatisfy!(isSigned, B, E) || allSatisfy!(isUnsigned, T, U)), then convert to narrowest common type as I mentioned (long in your case). This would preserve the current size when the types are both either signed or unsigned and then would expand it only when there are different signed-ness. This also makes the behavior change at compile-time instead of throwing at runtime. T/U should be B/E
Re: Strange behavior of iota
On Wednesday, 16 February 2022 at 15:55:55 UTC, bachmeier wrote: On Wednesday, 16 February 2022 at 15:21:11 UTC, jmh530 wrote: On Tuesday, 15 February 2022 at 22:24:53 UTC, bachmeier wrote: [snip] After looking at the documentation and seeing CommonType!(int, uint) is uint, I have to say that iota's behavior doesn't make much sense. What do you propose as an alternative? What about the narrowest type that fits both int and uint? That would be a long. My preference (in order) 1. Change everything to long. That way it works as anyone other than the author of std.range.iota would expect. 2. Throw an error when casting from signed to unsigned. That would at least prevent wrong output. The current behavior delivers incorrect output 100% of the time, excluding the trivial case where the correct output has zero elements. 3. Require the step to be positive. 4. Remove iota from Phobos because it silently changes correct code to incorrect code that compiles and runs. I've got an idea for combining 1 and 2. Step 1: In the integral overloads, use allSatisfy!(isSigned, B, E) || allSatisfy!(isUnsigned, T, U) for the current behavior Step 2: When !(allSatisfy!(isSigned, B, E) || allSatisfy!(isUnsigned, T, U)), then convert to narrowest common type as I mentioned (long in your case). This would preserve the current size when the types are both either signed or unsigned and then would expand it only when there are different signed-ness. This also makes the behavior change at compile-time instead of throwing at runtime.
Re: Strange behavior of iota
On Tuesday, 15 February 2022 at 22:24:53 UTC, bachmeier wrote: [snip] After looking at the documentation and seeing CommonType!(int, uint) is uint, I have to say that iota's behavior doesn't make much sense. What do you propose as an alternative? What about the narrowest type that fits both int and uint? That would be a long.
Re: Jupyter notebook with Dlang
On Tuesday, 16 November 2021 at 14:40:01 UTC, Imperatorn wrote: https://forum.dlang.org/post/pvwbeqzvktovnhoag...@forum.dlang.org On Wednesday, 29 April 2020 at 15:49:05 UTC, Jan Hönig wrote: [snip] I would also like to know this! I would also be interested.
Re: alias this - am I using it wrong?
On Wednesday, 25 August 2021 at 12:23:06 UTC, Adam D Ruppe wrote: [snip] That's a lot about alias this that I didn't know. Thanks.
Re: How to get element type of a slice?
On Tuesday, 17 August 2021 at 14:40:20 UTC, Ferhat Kurtulmuş
wrote:
[snip]
Very informative, thanks. My code is lying here[1]. I want my
struct to accept 2d static arrays, random access ranges, and
"std.container.Array". I could achieve it with its present
form, and I will probably slightly modify it based on your
comments.
[1]:
https://github.com/aferust/earcut-d/blob/master/source/earcutd.d#L34
If it would only accept dynamic arrays, you could use something
like below
```d
import std.traits: isDynamicArray;
template DynamicArrayOf(T : U[], U)
if (isDynamicArray!T)
{
alias DynamicArrayOf = U;
}
struct Point {}
void main()
{
static assert(is(DynamicArrayOf!(int[]) == int));
static assert(is(DynamicArrayOf!(Point[]) == Point));
}
```
Re: equivalent of std.functional.partial for templates?
On Wednesday, 11 August 2021 at 14:08:59 UTC, Paul Backus wrote: [snip] Should have read further--this does not work with template functions due to [issue 1807.][1] My mistake. [1]: https://issues.dlang.org/show_bug.cgi?id=1807 Looks like that strengthens the case for moving forward with DIP1023 (or something more general).
Re: Integer programming in D?
On Monday, 19 July 2021 at 12:39:41 UTC, Arredondo wrote: Is there an integer linear programming/discrete optimization library for D? an equivalent to the JuMP library for Julia for instance. Doesn't have to be too big, I really only need to solve a few smallish binary linear systems, but taking a quick look at code.dlang I did not immediately find anything. Cheers! Arredondo. glpk can handle mixed integer programming problems. Since it is a C library, it would be pretty easy to call from D but I don't see a binding or anything available. I would try to call it with dpp and if that doesn't work then something else like dstep. There is probably scope for building a wrapper on top of it that makes for a more D-like interface.
Re: assert(false) and GC
On Thursday, 8 July 2021 at 18:11:50 UTC, DLearner wrote:
Hi
Please confirm that:
`
assert(false, __FUNCTION__ ~ "This is an error message");
`
Will _not_ trigger GC issues, as the text is entirely known at
compile time.
Best regards
Consider below. Only z will generate an error. This is called
string literal concatenation, which comes from C [1].
```d
@nogc void main() {
string x = __FUNCTION__ ~ "This is an error message";
string y = "This is an error message";
string z = __FUNCTION__ ~ y;
}
```
[1]
https://en.wikipedia.org/wiki/String_literal#String_literal_concatenation
Re: float price; if (price == float.nan) { // initialized } else { // uninitialized } ... valid ?
On Wednesday, 30 June 2021 at 04:17:19 UTC, someone wrote: On Wednesday, 30 June 2021 at 03:55:05 UTC, Vladimir Panteleev wrote: If you want to give any type a "null" value, you could use [`std.typecons.Nullable`](https://dlang.org/library/std/typecons/nullable.html). At LEAST for some things with currency types like prices which cannot be zero because 0 makes no sense for a price: [snip] You've never given something away for free?
Re: Financial Library
On Sunday, 13 June 2021 at 22:32:16 UTC, Bastiaan Veelo wrote: On Sunday, 13 June 2021 at 12:46:29 UTC, Financial Wiz wrote: What are some of the best Financial Libraries for D? I would like to be able to aggregate as much accurate information as possible. Thanks. I am not into financials, but these libs show up in a search: https://code.dlang.org/search?q=Decimal. Perhaps you know some other relevant terms to search for. [snip] Assignment contracts also make it more difficult for people who work for financial firms to work on open-source projects that are directly related to finance.
Re: dual-context deprecation
On Monday, 17 May 2021 at 14:35:51 UTC, Steven Schveighoffer wrote: [snip] The feature is deprecated in its current form. The issue as I understand it (i.e. very little) is that compilers other than DMD could not use this same way to implement dual contexts, and so they could not have the feature. This means that valid code in DMD would not compile on GDC or LDC. The way forward was to deprecate the mechanism used to implement it for DMD, and at some point tackle it in a backend-agnostic way. Personally, I don't know why we can't fix it so that it's portable, but I understand so little about compilers that I've pretty much stayed out of it. The feature is very much needed. -Steve That's a good summary. Thanks.
Re: dual-context deprecation
On Monday, 17 May 2021 at 13:51:32 UTC, Paul Backus wrote: [snip] See this issue for context: https://issues.dlang.org/show_bug.cgi?id=5710 Thanks. Lots of details there that I don't follow all of. I mentioned in the deprecation PR [1] that it was not listed in the list of deprecated features. [1] https://github.com/dlang/dmd/pull/9702
dual-context deprecation
The code below (simplified from my actual problem) generates a
warning that member function b "requires a dual-context, which is
deprecated".
However when I look at the list of deprecated features [1], I'm
not seeing which one this is referring to. Is it a valid
deprecation?
I could only find this [2] reference to dual-contexts, which
suggests that the problem relates to passing aliases into member
functions. Moving it to a member function fixes the problem.
Alternately, I could make the alias part of Foo's type. My use
case it is just a little easier structured like this, but I get
that there are workarounds.
My bigger question is about why it isn't listed more than
anything. I.e., should I file something in bugzilla.
```d
struct Foo
{
double a;
this(double x)
{
this.a = x;
}
double b(alias inverse)()
{
return inverse(a);
}
}
void main()
{
auto foo = Foo(2.0);
auto x = foo.b!(a => (10.0 ^^ a))();
}
```
[1] https://dlang.org/deprecate.html
[2]
https://forum.dlang.org/thread/mkeumwltwiimkrelg...@forum.dlang.org
Re: Since dmd 2.096.0: import `x.t` is used as a type
On Sunday, 2 May 2021 at 18:36:25 UTC, Basile B. wrote: [snip] BTW during the PR review the problem you encounter [was anticipated](https://github.com/dlang/dmd/pull/12178#issuecomment-773886263) si I guess you're stuck with [the author answer](https://github.com/dlang/dmd/pull/12178#issuecomment-773902749), i.e "this worked because of a special case". [snip] "this worked because of a special case" or "I'm sure they won't mind a bit of change" are not exactly the most fulfilling arguments to me. Don't we have transition switches for a reason? The other solution is to keep the special case and then add additional logic to handle when the thing being looked up is not public (or whatever).
Re: mir - Help on how to transform multidimentional arrays.
On Thursday, 29 April 2021 at 15:56:48 UTC, jmh530 wrote: What you're basically asking for the first one is to convert for row major to column major. There doesn't seem to be a specific function for that, but you can piece it together. The second one is just applying allReversed to the result of that. So we have: [snip] Got an extra `universal` import there.
Re: mir - Help on how to transform multidimentional arrays.
On Thursday, 29 April 2021 at 15:26:15 UTC, Newbie wrote:
[snip]
Forgot to add the the first array was created using the
following code.
auto base = iota(2, 5, 3);
What you're basically asking for the first one is to convert for
row major to column major. There doesn't seem to be a specific
function for that, but you can piece it together. The second one
is just applying allReversed to the result of that. So we have:
```d
/+dub.sdl:
dependency "mir-algorithm" version="~>3.10.25"
+/
import std.stdio: writeln;
import mir.ndslice.topology: iota, flattened, reshape, universal;
import mir.ndslice.dynamic: transposed, allReversed;
void main() {
auto x = iota(2, 5, 3);
int err;
auto y = x.flattened.reshape([3, 5, 2], err).transposed!(1,
2);
auto z = y.allReversed;
writeln(x);
writeln(y);
writeln(z);
}
```
Re: DIP1000 and immutable
On Tuesday, 27 April 2021 at 14:44:48 UTC, Adam D. Ruppe wrote: On Tuesday, 27 April 2021 at 14:28:12 UTC, jmh530 wrote: However, should it ever matter if you escape an immutable? Your example is a pretty clear case of use-after-free if gloin actually did escape the reference and kept it after main returned. I tried basically the same thing in Rust and it doesn't generate errors (their borrow checker should be assuming scope by default). That means it treats gloin as if it is scope, so it isn't the same as your D code since the gloin there is NOT borrowing. Hmmm, good points. Thanks.
DIP1000 and immutable
What is the motivation for DIP1000 also applying to immutable?
For instance, in the code (compiled with -dip1000), adapted from
the spec [1], you get the same errors with immutable function
parameters as you would with mutable ones. However, should it
ever matter if you escape an immutable?
```d
@safe:
void thorin(scope immutable(int)*) {}
void gloin(immutable(int)*) {}
immutable(int)* balin(scope immutable(int)* q)
{
thorin(q);
gloin(q); // error, gloin() escapes q
return q; // error, cannot return 'scope' q
}
void main() {
immutable(int) x = 2;
immutable(int)* ptrx =
immutable(int)* ptrz = balin(ptrx);
}
```
I tried basically the same thing in Rust and it doesn't generate
errors (their borrow checker should be assuming scope by default).
```rust
#![allow(unused_variables)]
fn gloin(x: ) {
}
fn ballin(x: ) -> {
gloin(x);
return x;
}
fn main() {
let x = 2;
let ptrx =
let ptrz = ballin(ptrx);
}
```
[1] https://dlang.org/spec/function.html#scope-parameters
Re: How to delete dynamic array ?
On Wednesday, 17 March 2021 at 16:32:28 UTC, Ali Çehreli wrote: On 3/17/21 3:54 AM, jmh530 wrote: On Tuesday, 16 March 2021 at 23:49:00 UTC, H. S. Teoh wrote: double[] data; data = cast(double[]) malloc(n * double.sizeof)[0 .. n]; This is one of those things that is not explained well enough. I have something here: http://ddili.org/ders/d.en/pointers.html#ix_pointers.slice%20from%20pointer Ali That's a little advanced, I think. And you also have http://ddili.org/ders/d.en/slices.html saying that slices are just another name for dynamic arrays.
Re: How to delete dynamic array ?
On Wednesday, 17 March 2021 at 16:20:06 UTC, Steven Schveighoffer wrote: [snip] I've had online battles about this terminology, and people asked me to change my array article to disavow this distinction, but I'm not going to change it. It's so much easier to understand. -Steve I'll be on your side on that one.
Re: How to delete dynamic array ?
On Wednesday, 17 March 2021 at 14:30:26 UTC, Guillaume Piolat
wrote:
On Wednesday, 17 March 2021 at 10:54:10 UTC, jmh530 wrote:
This is one of those things that is not explained well enough.
Yes.
I made this article to clear up that point:
https://p0nce.github.io/d-idioms/#Slices-.capacity,-the-mysterious-property
"That a slice own or not its memory is purely derived from the
pointed area."
could perhaps better be said
"A slice is managed by the GC when the memory it points to is
in GC memory"?
I probably skimmed over the link when I originally read it
without really understanding it. I'm able to understand it now.
I think the underlying issue that needs to get explained better
is that when you do
int[] x = [1, 2, 3];
the result is always a GC-allocated dynamic array. However, z
below
int[3] y = [1, 2, 3];
int[] z = y[];
does not touch the GC at all. For a long time, I operated under
the assumption that dynamic arrays and slices are the same thing
and that dynamic arrays are always GC-allocated. z is obviously a
slice of y, but it is also a dynamic array in the sense that you
can append to it and get an array with one more member than y
(except in @nogc code). However, when appending to z, it seems
that what's really happening is that the GC is allocating a new
part of memory, copying over the original value of y and then
copying in the new value. So it really becomes a new kind of
thing (even if the type is unchanged).
One takeaway is there is no issue with a function like below
@nogc void foo(T)(T[] x) {}
so long as you don't actually need the GC within the function. A
static array can be passed in just using a slice.
Re: How to delete dynamic array ?
On Tuesday, 16 March 2021 at 23:49:00 UTC, H. S. Teoh wrote: [snip] Note that T[] is just a slice, not the dynamic array itself. The dynamic array is allocated and managed by the GC when you append stuff to it, or when you create a new array with `new` or an array literal. None of the latter, however, precludes you from using T[] for memory that you manage yourself. For example, you could do this: double[] data; data = cast(double[]) malloc(n * double.sizeof)[0 .. n]; Now you have a slice to memory you allocated yourself, and you have to manage its lifetime manually. When you're done with it: free(data.ptr); data = []; // null out dangling pointer, just in case The GC does not get involved unless you actually allocate from it. As long as .ptr does not point to GC-managed memory, the GC will not care about it. (Be aware, though, that the ~ and ~= operators may allocate from the GC, so you will have to refrain from using them. @nogc may help in this regard.) T This is one of those things that is not explained well enough.
Re: Why am I getting a dividing by zero error message
On Thursday, 28 January 2021 at 18:37:37 UTC, Ruby The Roobster wrote: Here is the output/input of the program: Type in data for an egg: Width: 3 Hight: 2 [...] It might help to separate break this out into smaller functions. May make it easier to follow what is happening.
Re: Why many programmers don't like GC?
On Friday, 15 January 2021 at 16:22:59 UTC, IGotD- wrote: [snip] Are we talking about the same things here? You mentioned DMD but I was talking about programs compiled with DMD (or GDC, LDC), not the nature of the DMD compiler in particular. Bump the pointer and never return any memory might acceptable for short lived programs but totally unacceptable for long running programs, like a browser you are using right now. Just to clarify, in a program that is made in D with the default options, will there be absolutely no memory reclamation? You are talking about different things. DMD, as a program, uses the bump the pointer allocation strategy. If you compile a D program with DMD that uses new or appends to a dynamic array (or whenver else), then it is using the GC to do that. You can also use malloc or your own custom strategy. The GC will reclaim memory, but there is no guarantee that malloc or a custom allocation strategy will.
Re: Why many programmers don't like GC?
On Friday, 15 January 2021 at 15:36:37 UTC, Ola Fosheim Grøstad wrote: On Friday, 15 January 2021 at 15:20:05 UTC, jmh530 wrote: Hypothetically, would it be possible for users to supply their own garbage collector that uses write barriers? Yes. You could translate Google Chrome's Oilpan to D. It uses library smart pointers for dirty-marking. But it requires you to write a virtual function that points out what should be traced (actually does the tracing for the outgoing pointers from that object): The library smart pointers would make it difficult to interact with existing D GC code though.
Re: Why many programmers don't like GC?
On Friday, 15 January 2021 at 14:50:00 UTC, welkam wrote: On Thursday, 14 January 2021 at 18:51:16 UTC, Ola Fosheim Grøstad wrote: One can follow the same kind of reasoning for D. It makes no sense for people who want to stay high level and do batch programming. Which is why this disconnect exists in the community... I think. The reasoning of why we do not implement write barriers is that it will hurt low level programming. But I feel like if we drew a ven diagram of people who rely on GC and those who do a lot of writes trough a pointer we would get almost no overlap. In other words if D compiler had a switch that turned on write barriers and better GC I think many people would use it and find the trade offs acceptable. Hypothetically, would it be possible for users to supply their own garbage collector that uses write barriers?
Re: C++ or D?
On Wednesday, 30 December 2020 at 19:51:07 UTC, Ola Fosheim
Grøstad wrote:
[snip]
Sort of, in C++ it would be something like this
template class OuterName>
void myfunction(OuterName x){ stuff(); }
[snip]
You mean like this
struct Foo(T)
{
T x;
}
void foo(T : Foo!V, V)(T x) {
import std.stdio: writeln;
writeln("here");
}
void main() {
Foo!int x;
foo(x);
}
Re: Running unit tests from DUB single file packages
On Tuesday, 22 December 2020 at 15:06:09 UTC, drug wrote: [snip] But what do you mean exactly by "work with dependency"? As I understand, `dub test` does not run unit tests in dependencies and single file packages work with dependencies in general. Do you mean something else? I'm finishing the new PR to fix #2051 finally and I'd like to know if there is something else I should include in it. https://github.com/dlang/dub/pull/2064 Thanks. It looks like your UT with taggedalgebraic does exactly what I was looking for. My problem is that run.dlang.org will skip unittests when you have dependencies. I had made some progress on fixing this a few months ago [1], but put it on the back burner when I ran into similar issues that the OP was dealing with. The problem ultimately came down to dub test not working with --single, which it looks like this latest PR will fix for good. [1] https://github.com/dlang-tour/core-exec/pull/56
Re: Running unit tests from DUB single file packages
On Monday, 21 December 2020 at 11:31:49 UTC, drug wrote: [snip] Unfortunately I'm very busy. But I check it again and it turns out that the fix does not resolve the problem completely. This PR just remove the single file from testing so currently dub does not run unit tests in the single file package at all. The first variant (https://github.com/dlang/dub/pull/2050) fixes the issue indeed. I need to reevaluate these PRs and close the issue. I'll do it later. Thanks for taking a look.
Re: Running unit tests from DUB single file packages
On Wednesday, 2 December 2020 at 12:51:11 UTC, drug wrote: [snip] Thanks! Let's see if it gets merged or if a slightly more involved solution is needed. Remake it - https://github.com/dlang/dub/pull/2052 This has more chances to be merged Looks like this got merged and will be part of the newest version, which is great news. Have you checked that it works with dependencies?
Re: Running unit tests from DUB single file packages
On Tuesday, 1 December 2020 at 14:15:22 UTC, Johannes Loher wrote: [snip] The point of using DUB (and the single file package format) is easy access to libraries from the DUB registry. If I didn't want to use a dependency, I would not be using DUB at all. That said, leaving out the dependency does not solve the issue, it also occurs with the following source file: Thanks. The reason I was asking was because if you've ever tried run.dlang.org with dependencies and unit tests, then you'll notice that the unittests are skipped, which is basically the same issue you are having. If you remove the dependencies, then it works. So I was thinking that whatever they used to get run.dlang.org working without dependencies might help you. I had hoped to try to get run.dlang.org working with dependencies and unittests, but haven't found the time to get a solution. Maybe this PR might improve matters...
Re: Running unit tests from DUB single file packages
On Tuesday, 1 December 2020 at 11:40:38 UTC, Johannes Loher wrote: [snip] Any hints on how to execute unit tests from single file DUB packages? Is it even possible at the moment? Thanks in advance for any help! [1] https://adventofcode.com/ Have you tried it without the imports?
Re: Running unit tests from DUB single file packages
On Tuesday, 1 December 2020 at 13:52:35 UTC, jmh530 wrote: On Tuesday, 1 December 2020 at 11:40:38 UTC, Johannes Loher wrote: [snip] Any hints on how to execute unit tests from single file DUB packages? Is it even possible at the moment? Thanks in advance for any help! [1] https://adventofcode.com/ Have you tried it without the imports? Or rather, without the dependency.
Re: lambdas with types
On Friday, 20 November 2020 at 14:57:42 UTC, H. S. Teoh wrote:
On Fri, Nov 20, 2020 at 02:47:52PM +, Paul Backus via
Digitalmars-d-learn wrote: [...]
In this specific case, you could also make `foo` a type-safe
variadic function [1], which would eliminate the need for
`allSatisfy`:
void foo(double[] args...)
{
// ...
}
[...]
Yes, and this will also eliminate the template bloat associated
with .foo, which would have been instantiated once per call
with a different number of arguments. But of course, this only
works if all arguments are of the same type, and if the
function body does not depend on accessing the number of
arguments at compile-time.
T
Thanks all.
The template conditions I'm working on are complicated enough
that this approach might work for some but not all. However, if I
split out the function I'm working on into a separate one, then I
might be able to take advantage of that.
lambdas with types
Doing something like below fails because I don't seem to be able
to make a templated lambda that just takes types. Is the only way
to do something similar to create a separate function to handle
the condition, or is there some other way to do something with
similar flexibility?
import std.stdio: writeln;
import std.meta: allSatisfy;
void foo(Args...)(Args args)
if (allSatisfy!(x => is(x == double), Args))
{
writeln("works");
}
void main() {
foo(1.0, 2.0);
}
Re: enum and const or immutable ‘variable’ whose value is known at compile time
On Thursday, 17 September 2020 at 10:53:48 UTC, Mike Parker wrote: [snip] I can attest that in the 17 years I've been hanging around here, the fact that enum is used to indicate a manifest constant has not been a serious source of WTF posts. So I think "pretty much everyone coming to D" have decided it's either perfectly fine or perfectly tolerable. It's the sort of thing that may not be obvious, but once you figure you absorb it and get down to coding. I know some people would prefer it were something else and some don't care. I'm squarely in the camp that thinks it makes perfect sense and it would be silly to create a new keyword for it. A talk at dconf 2019 provided an alternative approach to using enum for manifest constants: http://dconf.org/2019/talks/marques.html
Re: How to use libmir --> mir-algorithm, numir, mir-random?
On Wednesday, 9 September 2020 at 15:30:33 UTC, Shaleen Chhabra
wrote:
[snip]
Hi, I updated my dmd version to dmd-2.093.1
Now it throws a conflict error between
1. function mir.ndslice.topology.iota!(long, 1LU).iota at
mir/ndslice/topology.d(630) conflicts with function
std.range.iota!int.iota at
/home/shaleen/.dvm/compilers/dmd-2.093.1/linux/bin/../../src/phobos/std/range/package.d
2. template mir.ndslice.topology.map(fun...) if (fun.length) at
mir/ndslice/topology.d(2565) conflicts with template
std.algorithm.iteration.map(fun...) if (fun.length >= 1) at
/home/shaleen/.dvm/compilers/dmd-2.093.1/linux/bin/../../src/phobos/std/algorithm/iteration.d(482)
Below would generate the same error for iota. There are iota
functions in std.range and mir.ndslice.topology and the compiler
does not know which one to use. You can use one or the other or
use static imports.
In the future, it will be a little easier to identify the issues
if you post the code as well. You can also start with simpler
examples and work your way to larger ones.
```
/+dub.sdl:
dependency "mir-algorithm" version="*"
+/
import std.range;
import mir.ndslice.topology;
void main()
{
auto x = iota(5);
}
```
Re: How does D's templated functions implementation differ from generics in C#/Java?
On Friday, 7 August 2020 at 21:39:44 UTC, H. S. Teoh wrote: [snip] "Furthermore, it can dispatch to a type-erased implementation ala Java -- at your choice;" This is interesting. Would you just cast to Object?
Re: Template constraint on alias template parameter.
On Thursday, 6 August 2020 at 18:09:50 UTC, ag0aep6g wrote: [snip] `is(...)` only works on types. You're looking for `__traits(isSame, T, Foo)`. For `is(T!U == Foo!U, U)` to work, the compiler would have to guess U. If the first guess doesn't work, it would have to guess again, and again, and again, until it finds a U that does work. Could take forever. Thanks for the explanation!
Re: Template constraint on alias template parameter.
On Thursday, 6 August 2020 at 16:01:35 UTC, jmh530 wrote:
[snip]
It seems as if the T is properly Foo(T) and can only be
instantiated with actual types. Something like below works and
might work for me.
template test(alias T)
if (__traits(isTemplate, T))
{
void test(U)(U x)
if (is(T!U : Foo!U))
{
import std.stdio: writeln;
writeln("there");
}
}
Template constraint on alias template parameter.
The code below compiles, but I want to put an additional
constraint on the `test` function is only called with a Foo
struct.
I tried things like is(T == Foo) and is(T : Foo), but those don't
work. However, something like is(T!int : Foo!int) works, but
is(T!U == Foo!U, U) doesn't. Any idea why is(T!U == Foo!U, U)
doesn't work?
struct Foo(T)
{
T x;
}
void test(alias T)()
if (__traits(isTemplate, T))
{
import std.stdio: writeln;
writeln("there");
}
void main()
{
test!Foo();
}
Re: 2-D array initialization
On Sunday, 2 August 2020 at 19:19:51 UTC, Andy Balba wrote: I'm not a gitHub fan, but I like the mir functions; and it looks like I have to download mir before using it. mir has quite a few .d files..Is there a quick way to download it ? dub [1] is now packaged with dmd, which is the easiest way to use it, by far. You can also play around with it at run.dlang.org (though it has some limitations). I encourage you to get familiar with git and github, but if you want to avoid downloading files one-by-one from the website, there should be a big green button on the front page that says "Code". If you click on that, there is button for downloading a zip file. [1] https://dub.pm/getting_started
Re: 2-D array initialization
On Friday, 31 July 2020 at 23:42:45 UTC, Andy Balba wrote:
ubyte[3][4] c ;
How does one initialize c in D ? none of the statements below
works
c = cast(ubyte) [ [5, 5, 5], [15, 15,15], [25, 25,25], [35,
35,35] ];
c[0] = ubyte[3] [5, 5, 5] ; c[1] = ubyte[3] [15, 15,15] ;
c[2] = ubyte[3] [25, 25,25] ; c[3] = ubyte[3] [35, 35,35] ;
for (int i= 0; i<3; i++) for (int j= 0; i<4; j++) c[i][j]=
cast(ubyte)(10*i +j) ;
Below is for a dynamic array. You can also try mir
(https://github.com/libmir/mir-algorithm).
import std.stdio: writeln;
void main()
{
auto c = cast(ubyte[][]) [ [5, 5, 5], [15, 15,15], [25,
25,25], [35, 35,35] ];
writeln(c);
}
Re: D Mir: standard deviation speed
On Wednesday, 15 July 2020 at 11:41:35 UTC, 9il wrote: [snip] Ah, no, my bad! You write @fmamath, I have read it as @fastmath. @fmamath is OK here. I've mixed up @fastmath and @fmamath as well. No worries.
Re: D Mir: standard deviation speed
On Wednesday, 15 July 2020 at 11:26:19 UTC, 9il wrote: [snip] @fmamath private double sd(T)(Slice!(T*, 1) flatMatrix) @fastmath violates all summation algorithms except `"fast"`. The same bug is in the original author's post. I hadn't realized that @fmamath was the problem, rather than @fastmath overall. @fmamathis used on many mir.math.stat functions, though admittedly not in the accumulators.
Re: D Mir: standard deviation speed
On Wednesday, 15 July 2020 at 05:57:56 UTC, tastyminerals wrote:
[snip]
Here is a (WIP) project as of now.
Line 160 in
https://github.com/tastyminerals/mir_benchmarks_2/blob/master/source/basic_ops.d
std of [60, 60] matrix 0.0389492 (> 0.001727)
std of [300, 300] matrix 1.03592 (> 0.043452)
std of [600, 600] matrix 4.2875 (> 0.182177)
std of [800, 800] matrix 7.9415 (> 0.345367)
I changed the dflags-ldc to "-mcpu-native -O" and compiled with
`dub run --compiler=ldc2`. I got similar results as yours for
both in the initial run.
I changed sd to
@fmamath private double sd(T)(Slice!(T*, 1) flatMatrix)
{
pragma(inline, false);
if (flatMatrix.empty)
return 0.0;
double n = cast(double) flatMatrix.length;
double mu = flatMatrix.mean;
return (flatMatrix.map!(a => (a - mu) ^^ 2)
.sum!"precise" / n).sqrt;
}
and got
std of [10, 10] matrix 0.0016321
std of [20, 20] matrix 0.0069788
std of [300, 300] matrix 2.42063
std of [60, 60] matrix 0.0828711
std of [600, 600] matrix 9.72251
std of [800, 800] matrix 18.1356
And the biggest change by far was the sum!"precise" instead of
sum!"fast".
When I ran your benchStd function with
ans = matrix.flattened.standardDeviation!(double, "online",
"fast");
I got
std of [10, 10] matrix 1e-07
std of [20, 20] matrix 0
std of [300, 300] matrix 0
std of [60, 60] matrix 1e-07
std of [600, 600] matrix 0
std of [800, 800] matrix 0
I got the same result with Summator.naive. That almost seems too
low.
The default is Summator.appropriate, which is resolved to
Summator.pairwise in this case. It is faster than
Summator.precise, but still slower than Summator.naive or
Summator.fast. Your welfordSD should line up with Summator.naive.
When I change that to
ans = matrix.flattened.standardDeviation!(double, "online",
"precise");
I get
Running .\mir_benchmarks_2.exe
std of [10, 10] matrix 0.0031737
std of [20, 20] matrix 0.0153603
std of [300, 300] matrix 4.15738
std of [60, 60] matrix 0.171211
std of [600, 600] matrix 17.7443
std of [800, 800] matrix 34.2592
I also tried changing your welfordSD function based on the stuff
I mentioned above, but it did not make a large difference.
Re: D Mir: standard deviation speed
On Tuesday, 14 July 2020 at 19:04:45 UTC, tastyminerals wrote:
I am trying to implement standard deviation calculation in Mir
for benchmark purposes.
I have two implementations. One is the straightforward std =
sqrt(mean(abs(x - x.mean())**2)) and the other follows
Welford's algorithm for computing variance (as described here:
https://www.johndcook.com/blog/standard_deviation/).
However, although the first implementation should be less
efficient / slower, the benchmarking results show a startling
difference in its favour. I'd like to understand if I am doing
something wrong and would appreciate some explanation.
# Naive std
import std.math : abs;
import mir.ndslice;
import mir.math.common : pow, sqrt, fastmath;
import mir.math.sum : sum;
import mir.math.stat : mean;
@fastmath private double sd0(T)(Slice!(T*, 1) flatMatrix)
{
pragma(inline, false);
if (flatMatrix.empty)
return 0.0;
double n = cast(double) flatMatrix.length;
double mu = flatMatrix.mean;
return (flatMatrix.map!(a => (a - mu).abs ^^ 2).sum!"fast"
/ n).sqrt;
}
# std with Welford's variance
@fastmath double sdWelford(T)(Slice!(T*, 1) flatMatrix)
{
pragma(inline, false);
if (flatMatrix.empty)
return 0.0;
double m0 = 0.0;
double m1 = 0.0;
double s0 = 0.0;
double s1 = 0.0;
double n = 0.0;
foreach (x; flatMatrix.field)
{
++n;
m1 = m0 + (x - m0) / n;
s1 = s0 + (x - m0) * (x - m1);
m0 = m1;
s0 = s1;
}
// switch to n - 1 for sample variance
return (s1 / n).sqrt;
}
Benchmarking:
Naive std (1k loops):
std of [60, 60] matrix 0.001727
std of [300, 300] matrix 0.043452
std of [600, 600] matrix 0.182177
std of [800, 800] matrix 0.345367
std with Welford's variance (1k loops):
std of [60, 60] matrix 0.0225476
std of [300, 300] matrix 0.534528
std of [600, 600] matrix 2.0714
std of [800, 800] matrix 3.60142
It would be helpful to provide a link.
You should only need one accumulator for mean and centered sum of
squares. See the python example under the Welford example
https://en.wikipedia.org/wiki/Algorithms_for_calculating_variance
This may have broken optimization somehow.
variance and standardDeviation were recently added to
mir.math.stat. They have the option to switch between Welford's
algorithm and the others. What you call as the naive algorithm,
is VarianceAlgo.twoPass and the Welford algorithm can be toggled
with VarianceAlgo.online, which is the default option. It also
would be interesting if you re-did the analysis with the built-in
mir functions.
There are some other small differences between your
implementation and the one in mir, beyond the issue discussed
above. You take the absolute value before the square root and
force the use of sum!"fast". Another difference is
VarianceAlgo.online in mir is using a precise calculation of the
mean rather than the fast update that Welford uses. This may have
a modest impact on performance, but should provide more accurate
results.
Re: Upcoming refraction module in bolts [was: DUB project type support for Emacs Projectile]
On Monday, 15 June 2020 at 17:32:26 UTC, Jean-Louis Leroy wrote: [snip] Thanks, cool.
Re: DUB project type support for Emacs Projectile
On Monday, 15 June 2020 at 13:17:11 UTC, Jean-Louis Leroy wrote: [snip] Nah, I saw it. Well. My take on it has been ready for months but I had to wait for my employer's permission to publish it. They are very open-source friendly, and as a consequence there is a glut of requests for open-sourcing personal projects. I guess I am going to cancel my request... Ah. I suppose that depends implementation/performance/feature differences... On the bright side, I just got authorized to contribute my work on function refraction (currently part of openmethods) to bolts. You can see it here: https://github.com/aliak00/bolts/pull/10 I saw when you mentioned it earlier. Though it hasn't been something I've needed as yet, it's good to know that it's there. This allows the function mixins to work when they are in different modules, right? I don't see a test for that, but it might be useful to include such an example (I'm pretty sure Atila's tardy makes use of a similar functionality when they are in different modules). It's interesting that many of the examples for refract are like refract!(F, "F") or refract!(answer, "answer"). Would something like Function refract(alias fun, string localSymbol = __traits(identifier, fun))() work for you?
Re: DUB project type support for Emacs Projectile
On Sunday, 14 June 2020 at 17:19:05 UTC, Jean-Louis Leroy wrote: [snip] In case you missed it, I thought you would find this interesting https://forum.dlang.org/thread/dytpsnkqnmgzniiwk...@forum.dlang.org
Re: Why is there no range iteration with index by the language?
On Wednesday, 10 June 2020 at 00:53:30 UTC, Seb wrote: [snip] Anyhow, I would be highly in favor of DMD doing this. It's one of those many things that I have on my list for D3 or a D fork. Chapel supports zippered iteration [1]. From the discussion here, it sounds very much like the implementation is similar to what D does with tuples. It probably would be pretty trivial with first class tuples. [1] https://chapel-lang.org/docs/language/spec/statements.html#zipper-iteration
Re: Mixin and imports
On Monday, 8 June 2020 at 14:27:26 UTC, data pulverizer wrote: [snip] Out of curiosity what does the "." in front of `foo` mean? I've seen that in some D code on the compiler in GitHub and have no idea what it does. I tried Googling it to no avail. It doesn't have anything to do with UFCS does it? Thanks ag0aep6g provided the link to it, but it's one of those things that has been difficult for me to understand as well. I believe the original code had `foo` in a template. So in that case it was necessary. I'm not sure if it still is in my simplified version.
Re: Mixin and imports
On Monday, 8 June 2020 at 12:20:46 UTC, Adam D. Ruppe wrote: [snip] Why do you even want foo!"fabs"? Usually when I see people having this problem it is actually a misunderstanding of what is possible with the foo!fabs style - which is better in basically every way and can be used in most the same places. So what's your bigger goal? There were some other functions in the module that allow the use of function!"thinginquotes". However, most of those functions are using the "thinginquotes" to avoid writing function!(SomeEnum.thinginquotes). That really isn't the thing to fix in this case. So I think it makes sense for me to give up what I was trying to do.
Re: Mixin and imports
On Monday, 8 June 2020 at 10:28:39 UTC, Paul Backus wrote: [snip] Thanks for that suggestion. That works for me. Unfortunately, it's probably not worth the extra effort though, versus doing foo!fabs in my case.
