Re: cannot find source code for runtime library file 'object.d'

2023-11-22 Thread thinkunix via Digitalmars-d-learn

denis via Digitalmars-d-learn wrote:

On Monday, 20 November 2023 at 07:50:22 UTC, thinkunix wrote:

denis via Digitalmars-d-learn wrote:

```
$ zypper install dmd
$ dmd main.d
Error: cannot find source code for runtime library file 'object.d'
    dmd might not be correctly installed. Run 'dmd -man' for 
installation instructions.

    config file: /etc/dmd.conf


I would say the package has files in the wrong locations.
Try the binary from dlang.org:
https://downloads.dlang.org/releases/2.x/2.105.3/dmd-2.105.3-0.openSUSE.x86_64.rpm 


Thank you Scot, I confirm that installing manually does the trick


You should open a bug report with OpenSUSE to let them know their
official package does not work.  Point them to the dlang.org
openSUSE package which does work for how to "do it right".

scot


Re: Doubt about type Inference on templates

2023-11-22 Thread Paul Backus via Digitalmars-d-learn

On Wednesday, 22 November 2023 at 17:53:15 UTC, Antonio wrote:
Basically, it doesn't know witch version of ```filter``` to 
use, because it is inferring `i=>i%2==0` is `void` ?!?!?!


```
!()(IIterable!int, void)
```

If I explicitly write `(int i)=>i%2==0`, it compiles correctly 
again.


**Is it mandatory to explicitly tell that `S` is `int` when 
```IIterable!S source``` is  `IIterable!int` alredy?**


This is a bug/limitation in the compiler. I couldn't find an 
existing report on issues.dlang.org, so I've reported it myself 
as [issue 24255][1].


For now, I think the best way to work around it is to specify the 
type in the lambda, as in `(int i) => i%2 == 0`.


The reason you see `void` is that when the compiler cannot figure 
out the type of a function literal, it treats it as a template 
function:


```d
static assert(__traits(isTemplate, i => i % 2 == 0));
```

And for silly historical reasons, when the compiler tries to 
determine the type of a template, it returns `void` instead of 
giving an error:


```d
template example() {}
static assert(is(typeof(example) == void)); // what??
```

[1]: https://issues.dlang.org/show_bug.cgi?id=24255


Doubt about type Inference on templates

2023-11-22 Thread Antonio via Digitalmars-d-learn
Just for fun, I'm trying to implement an alternative base library 
to avoid template/mixin/static/traits code with only one 
objective:  make "intelliSense" code analyzers tasks easier.


I need "Generics"... but D has not generics:  I use templates in 
the "simplest" possible way


I.E.:
```d
interface IIterable(T)
{
  bool empty();
  void popFront();
  T front();
}

IIterable!S toIterable(S)(S[] source)
  => new ArrayIterable!S(source);
IIterable!S filter(S)(IIterable!S source, bool delegate(S item) 
predicate)

  => new Filter!S(source, predicate);
IIterable!S filter(S)(S[] source, bool delegate(S item) predicate)
  => toIterable(source).filter(predicate);
// ...

```

Then, in main.d I do
```d
import std.stdio;
void main(){
  
[1,2,3,4,5,6].toIterable!int.filter!int(i=>i%2==0).map!int(i=>i*2).toArray.writeln();

}

```

It works properly... until I remove the ```!int``` from the 
```filter``` method.


```
main.d(3,38): Error: none of the overloads of template `filter` 
are callable using argument types `!()(IIterable!int, void)`
iterable.d(21,13):Candidates are: `filter(S)(IIterable!S 
source, bool delegate(S item) predicate)`
iterable.d(23,13):`filter(S)(S[] source, 
bool delegate(S item) predicate)`

```

Basically, it doesn't know witch version of ```filter``` to use, 
because it is inferring `i=>i%2==0` is `void` ?!?!?!


```
!()(IIterable!int, void)
```

If I explicitly write `(int i)=>i%2==0`, it compiles correctly 
again.


**Is it mandatory to explicitly tell that `S` is `int` when 
```IIterable!S source``` is  `IIterable!int` alredy?**












Re: import issue?

2023-11-22 Thread DLearner via Digitalmars-d-learn
On Wednesday, 22 November 2023 at 16:51:54 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

On 23/11/2023 5:34 AM, DLearner wrote:
Is the encapsulation issue resolved if the struct itself is 
held in another module, and imported from that module into 
both the 'main' and 'Ex_mod' files?


Each module is its own encapsulation unit.

As long as you are using the same distinct type in both 
modules, the issues are resolved.


Where the distinct type is defined does not matter for matching 
of function parameters.


OK thanks.


Re: import issue?

2023-11-22 Thread Richard (Rikki) Andrew Cattermole via Digitalmars-d-learn

On 23/11/2023 5:34 AM, DLearner wrote:
Is the encapsulation issue resolved if the struct itself is held in 
another module, and imported from that module into both the 'main' and 
'Ex_mod' files?


Each module is its own encapsulation unit.

As long as you are using the same distinct type in both modules, the 
issues are resolved.


Where the distinct type is defined does not matter for matching of 
function parameters.


Re: import issue?

2023-11-22 Thread DLearner via Digitalmars-d-learn
On Wednesday, 22 November 2023 at 16:11:03 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

You have two ``SA`` structs, each in different encapsulations.

Each of them are different, even if they have similar members.

In D types that look the same do not combine, they are distinct.

You can see this by comparing the mangling of each.

``pragma(msg, SA.mangleof);``


Is the encapsulation issue resolved if the struct itself is held 
in another module, and imported from that module into both the 
'main' and 'Ex_mod' files?


Re: import issue?

2023-11-22 Thread Richard (Rikki) Andrew Cattermole via Digitalmars-d-learn

You have two ``SA`` structs, each in different encapsulations.

Each of them are different, even if they have similar members.

In D types that look the same do not combine, they are distinct.

You can see this by comparing the mangling of each.

``pragma(msg, SA.mangleof);``


import issue?

2023-11-22 Thread DLearner via Digitalmars-d-learn

Please,
Why does:

```
// Test module Ex_mod
struct SA {
   int   SAIntFld1;
   int   SAIntFld2;
}

bool AddEle(ref void* StartPtr, SA PayLoad1) {

   import core.stdc.stdlib : malloc;

   struct Ele {
  SA   PayLoad;
  Ele* EleNxtPtr;
  Ele* ElePrvPtr;
   }

   Ele*ElePtr;
   Ele*  wkElePtr;

   return true;
}

```

imported into:
```
// Test harness

struct SA {
   int   SAIntFld1;
   int   SAIntFld2;
}


void main() {

   import std.stdio: writeln;

   import Ex_mod;

   SA SAVar;
   void* SA_StartPtr = null;

   SAVar.SAIntFld1 = 3;
   SAVar.SAIntFld2 = -5;

   if (AddEle(SA_StartPtr, SAVar)) {
  writeln("Element linked");
   } else {
  writeln("Element not linked");
   }

}
```

Fail with:
```
ex_main.d(21): Error: function `Ex_mod.AddEle(ref void* StartPtr, 
SA PayLoad1)` is not callable using argument types `(void*, SA)`
ex_main.d(21):cannot pass argument `SAVar` of type 
`ex_main.SA` to parameter `Ex_mod.SA PayLoad1`


```

When eliminating the import via:

```
// Test harness

struct SA {
   int   SAIntFld1;
   int   SAIntFld2;
}

bool AddEle(ref void* StartPtr, SA PayLoad1) {

   import core.stdc.stdlib : malloc;

   struct Ele {
  SA   PayLoad;
  Ele* EleNxtPtr;
  Ele* ElePrvPtr;
   }

   Ele*ElePtr;
   Ele*  wkElePtr;

   return true;
}


void main() {

   import std.stdio: writeln;

//   import Ex_mod;

   SA SAVar;
   void* SA_StartPtr = null;

   SAVar.SAIntFld1 = 3;
   SAVar.SAIntFld2 = -5;

   if (AddEle(SA_StartPtr, SAVar)) {
  writeln("Element linked");
   } else {
  writeln("Element not linked");
   }

}
```

works correctly?