Re: Why is opIndexAssign replaced by opSlice here?

2021-10-17 Thread Imperatorn via Digitalmars-d-learn

On Monday, 18 October 2021 at 04:11:18 UTC, Paul Backus wrote:

On Monday, 18 October 2021 at 03:42:35 UTC, Paul Backus wrote:
My guess is that you got into this situation by trying to 
follow the example in the spec's section on ["Slice Assignment 
Operator Overloading"][2]. Unfortunately, that example is 
incorrect.


[2]: 
https://dlang.org/spec/operatoroverloading.html#slice_assignment_operator


https://issues.dlang.org/show_bug.cgi?id=22417
https://github.com/dlang/dlang.org/pull/3113


Gold star for fixing broken examples 


Re: Why is opIndexAssign replaced by opSlice here?

2021-10-17 Thread Paul Backus via Digitalmars-d-learn

On Monday, 18 October 2021 at 03:42:35 UTC, Paul Backus wrote:
My guess is that you got into this situation by trying to 
follow the example in the spec's section on ["Slice Assignment 
Operator Overloading"][2]. Unfortunately, that example is 
incorrect.


[2]: 
https://dlang.org/spec/operatoroverloading.html#slice_assignment_operator


https://issues.dlang.org/show_bug.cgi?id=22417
https://github.com/dlang/dlang.org/pull/3113


Re: Why is opIndexAssign replaced by opSlice here?

2021-10-17 Thread Paul Backus via Digitalmars-d-learn

On Sunday, 17 October 2021 at 22:52:27 UTC, Elmar wrote:

Hello Dear community.

I'd like to overload `opIndexAssign` for a struct which wraps 
around a generic array (so that it can't support `opIndex` due 
to unknown return type).


Broken down as much as possible this is the code:

```
import std.stdio : writeln;
import std.range : ElementType;

struct S {
void opIndexAssign(X, RANGE)(X x, RANGE range)
if (is(ElementType!RANGE : size_t))
{
writeln(__FUNCTION__);
}

auto opSlice(size_t start, size_t end) {
import std.range : iota;
return iota(start, end);
}
}

void main()
{
auto arr = new int[7];

S s;
s.opIndexAssign(arr, s.opSlice(1,4));  // works
	s[0..3] = arr[1..4];  // does not work, compiles to 
`s.opSlice(0,3) = arr[1..4]`

}
```

I'm clueless about why it wouldn't compile the last statement 
to `s.opIndexAssign(arr[1..4], s.opSlice(0,3))`.


Help appreciated :-)


What happens here is, the compiler first tries the D2-style 
rewrite:


```d
s.opIndexAssign(arr[1..4], s.opSlice!0(0, 3))
```

However, that rewrite fails to compile, because your `opSlice` 
does not take a template argument specifying the dimension along 
which to slice, as specified in the language spec's section on 
["Slice Operator Overloading".][1]


Since the above rewrite fails to compile, it falls back to 
rewriting the expression using D1-style operator overloads:


For backward compatibility, `a[]` and `a[i..j]` can also be 
overloaded by implementing `opSlice()` with no arguments and 
`opSlice(i, j)` with two arguments, respectively. This only 
applies for one-dimensional slicing, and dates from when D did 
not have full support for multidimensional arrays. This usage 
of opSlice is discouraged.


...which results in the following rewritten statement:

```d
s.opSlice(0, 3) = arr[1..4];
```

My guess is that you got into this situation by trying to follow 
the example in the spec's section on ["Slice Assignment Operator 
Overloading"][2]. Unfortunately, that example is incorrect.


Here is a fixed version of your example on run.dlang.io: 
https://run.dlang.io/is/dtfT5y


[1]: https://dlang.org/spec/operatoroverloading.html#slice
[2]: 
https://dlang.org/spec/operatoroverloading.html#slice_assignment_operator


Re: How to do a function pointer to "malloc" and "free"?

2021-10-17 Thread Adam Ruppe via Digitalmars-d-learn

On Sunday, 17 October 2021 at 23:07:15 UTC, Elmar wrote:
Do you have a link for more information how to initialize the D 
runtime?


Export a function that calls this:
http://druntime.dpldocs.info/core.runtime.Runtime.initialize.html

And also export a function that calls this:
http://druntime.dpldocs.info/core.runtime.Runtime.terminate.html

And tell the user to call those when they load/unload the 
library. (It is pretty common for C libraries to require explicit 
init/term calls so they should be used to it.)


They refcount internally so it is ok to call multiple times, just 
make sure the init and term are always paired.




(btw the druntime actually exports them as extern(C) 
rt_init/rt_term but I'd still recommend you do your own anyway. 
if you do have extra work to do you can just do it there, and it 
can use whatever your lib naming conventions are. and besides im 
not sure if the extern(C) things are specified stable (even 
though they have been for as long as i can remember), whereas 
doing your own thing that `import core.runtime; return 
Runtime.initalize;` is. )


Re: How to do a function pointer to "malloc" and "free"?

2021-10-17 Thread Elmar via Digitalmars-d-learn

On Sunday, 10 October 2021 at 17:14:30 UTC, Adam Ruppe wrote:

On Sunday, 10 October 2021 at 13:52:57 UTC, Elmar wrote:
The language subset "BetterC" is required for calling D 
functions from C though.


This is false.

You can use any D features when calling it from C, you just 
need to provide an init and term function that is called from C 
that runtime initialize and terminate for the full experience.



BetterC helper librarys like Tanya or Tango do exist.


I don't know tanya, but Tango has absolutely nothing to do with 
betterC. It is a set of classes that use the full runtime.


That's nice!

Do you have a link for more information how to initialize the D 
runtime? I just wondered about that because I thought it actually 
shouldn't be much more difficult than just linking the runtime 
into the foreign-language compiled program. I didn't find 
information on that. Maybe I didn't search long enough.


Re: Why is opIndexAssign replaced by opSlice here?

2021-10-17 Thread Elmar via Digitalmars-d-learn

Btw, I should have written:

`s.opIndexAssign(arr[1..4], s.opSlice(0,3));`

But it compiles the same way.


Why is opIndexAssign replaced by opSlice here?

2021-10-17 Thread Elmar via Digitalmars-d-learn

Hello Dear community.

I'd like to overload `opIndexAssign` for a struct which wraps 
around a generic array (so that it can't support `opIndex` due to 
unknown return type).


Broken down as much as possible this is the code:

```
import std.stdio : writeln;
import std.range : ElementType;

struct S {
void opIndexAssign(X, RANGE)(X x, RANGE range)
if (is(ElementType!RANGE : size_t))
{
writeln(__FUNCTION__);
}

auto opSlice(size_t start, size_t end) {
import std.range : iota;
return iota(start, end);
}
}

void main()
{
auto arr = new int[7];

S s;
s.opIndexAssign(arr, s.opSlice(1,4));  // works
	s[0..3] = arr[1..4];  // does not work, compiles to 
`s.opSlice(0,3) = arr[1..4]`

}
```

I'm clueless about why it wouldn't compile the last statement to 
`s.opIndexAssign(arr[1..4], s.opSlice(0,3))`.


Help appreciated :-)


How can we allow using phobos with asserts/contracts?

2021-10-17 Thread Steven Schveighoffer via Digitalmars-d-learn

On 10/16/21 6:47 PM, solidstate1991 wrote:

When I make this call
```
format(" %3.3f"w, avgFPS);
```
my program immediately crashes with an access violation error. The 
debugger out is different between x86 and x86-64.


I've made all sanity checks, so I need some other suggestions.


FYI, solidstate figured this out. It was because of an out-of-bounds 
index on `BitArray`.


But that irks me. Why wouldn't `BitArray` do a bounds check? And then I 
remembered -- Phobos is built in release mode even when your app is not.


I literally *cannot* request from the compiler that `BitArray` enforce 
its contracts without rebuilding the library completely. I never want to 
build code that doesn't have bounds checks.


How can we fix this?

-Steve


Re: std.format doesn't want to work

2021-10-17 Thread solidstate1991 via Digitalmars-d-learn

On Sunday, 17 October 2021 at 13:03:46 UTC, jfondren wrote:
then it's likely that some memory corruption prior to format() 
has broken the GC, and format's allocation of a string is 
what's failing. Try sprinkling `@safe` and and see what it 
complains about; try valgrind; try reducing your problem. I 
don't think we can help you more without a way to replicate the 
fault.


I ran Valgrind, and I've noticed some possible leakage in a 
library I've written, but I'll check for it further once I'll 
have a bit more time.


Re: std.format doesn't want to work

2021-10-17 Thread jfondren via Digitalmars-d-learn

On Sunday, 17 October 2021 at 12:53:07 UTC, solidstate1991 wrote:

On Sunday, 17 October 2021 at 05:22:17 UTC, russhy wrote:
On Saturday, 16 October 2021 at 22:47:09 UTC, solidstate1991 
wrote:

When I make this call
```
format(" %3.3f"w, avgFPS);
```
my program immediately crashes with an access violation 
error. The debugger out is different between x86 and x86-64.


I've made all sanity checks, so I need some other suggestions.


what is the type of avgFPS?


I's a double, but I've tried to pass it as real and float too, 
with the same exact error being generated.


then it's likely that some memory corruption prior to format() 
has broken the GC, and format's allocation of a string is what's 
failing. Try sprinkling `@safe` and and see what it complains 
about; try valgrind; try reducing your problem. I don't think we 
can help you more without a way to replicate the fault.


Re: std.format doesn't want to work

2021-10-17 Thread solidstate1991 via Digitalmars-d-learn

On Sunday, 17 October 2021 at 05:22:17 UTC, russhy wrote:
On Saturday, 16 October 2021 at 22:47:09 UTC, solidstate1991 
wrote:

When I make this call
```
format(" %3.3f"w, avgFPS);
```
my program immediately crashes with an access violation error. 
The debugger out is different between x86 and x86-64.


I've made all sanity checks, so I need some other suggestions.


what is the type of avgFPS?


I's a double, but I've tried to pass it as real and float too, 
with the same exact error being generated.


Re: Can we use "ImportC" used yet?

2021-10-17 Thread Imperatorn via Digitalmars-d-learn

On Sunday, 17 October 2021 at 10:46:30 UTC, data pulverizer wrote:
Okay wow, this is amazing, I can now call R's standalone math 
library `Rmath.h` by converting:


[...]


Yeah it's pretty nice hey ☀️

But will become even more convenient later


Re: Can we use "ImportC" used yet?

2021-10-17 Thread data pulverizer via Digitalmars-d-learn

On Sunday, 17 October 2021 at 10:46:30 UTC, data pulverizer wrote:
Okay wow, this is amazing, I can now call R's standalone math 
library `Rmath.h` by converting ...


Sorry you don't need `-lRmath` so the initial call should be:

```
gcc -E -P -I"/usr/share/R/include" r2d_con.c > r2d.c
```



Re: Can we use "ImportC" used yet?

2021-10-17 Thread data pulverizer via Digitalmars-d-learn
Okay wow, this is amazing, I can now call R's standalone math 
library `Rmath.h` by converting:


```
//r2d_con.c
#define __restrict restrict
#define __asm__ asm
#define __extension__
#define __inline
#define __builtin_bswap16
#define __builtin_bswap32
#define __builtin_bswap64

#define MATHLIB_STANDALONE 1
typedef struct _Float128 {unsigned long long x[2];} _Float128;
#include "Rmath.h"
#include "R_ext/Random.h"
```

```
//callr
import r2d;
import std.random: unpredictableSeed;
import std.stdio: writeln;

void main()
{
  set_seed(unpredictableSeed(), unpredictableSeed());
  writeln("rgamma (2, 3): ", rgamma(2, 3));
}

```

Using:

```
gcc -E -P -I"/usr/share/R/include" -lRmath r2d_con.c > r2d.c
dmd callr.d -L-lRmath -L-lm && ./callr
```

Okay it's only the standalone library which is a small part of R, 
but this rocks. The PAHWAHR! Lol.