Re: length's type.

2024-02-09 Thread thinkunix via Digitalmars-d-learn

Kevin Bailey via Digitalmars-d-learn wrote:

On Thursday, 8 February 2024 at 08:23:12 UTC, thinkunix wrote:


I would never write code like this.


By all means, please share with us how you would have written that just 
as elegantly but "correct".


First off I, I am just a beginner with D.  I joined this list to try to
learn more about the language not to but heads with experts.  I'm sorry
if you took my response that way.

My post was merely to show how, with my rudimentary knowledge, I could
get the loop to execute 4 times, which appeared (to me) to be the intent 
of your code.  Thank you for the exercise.  I learned more about the D 
type system.


I said I would not write code like that because:
* why start at -1 if array indexes start at 0?
* why use auto which made the type different than what .length is?

You provided no context, or comment indicated what you were trying
to achieve by starting with -1.  Clearly I didn't understand your
intent.


It would also break if the array 'something' had more than int.max 
elements.


Then don't cast it to an int. First of all, why didn't you cast it to a 
long? 


I only "cast(int)something.length" so the type would match the type
that "auto i = -1" would get, which was int, and this was to prevent
comparing incompatible types, which caused the conversion, and the
loop not to execute at all.

As a beginner, I would expect that if you mismatch types, you can
expect bad things to happen, and this is probably true in any language.
If your issue is that the compiler didn't catch this, shouldn't you
raise the issue on a compiler internals list?  Maybe I've misunderstood
the purpose of d-learn "Questions about learning and using D".

scot



Re: length's type.

2024-02-08 Thread thinkunix via Digitalmars-d-learn

Kevin Bailey via Digitalmars-d-learn wrote:
How many times does the following loop print? I ran into this twice 
doing the AoC exercises. It would be nice if it Just Worked.

```
import std.stdio;

int main()
{
   char[] something = ['a', 'b', 'c'];

   for (auto i = -1; i < something.length; ++i)
     writeln("less than");

   return 0;
}
```



Pretty nasty.

This seems to work but just looks bad to me.  I would never write
code like this.  It would also break if the array 'something' had
more than int.max elements.

```
import std.stdio;

int main()
{
char[] something = ['a', 'b', 'c'];

// len = 3, type ulong
writeln("len: ", something.length);
writeln("typeid(something.length): ", typeid(something.length));

// To make the loop execute, must cast something.length
// which is a ulong, to an int, which prevents i from
// being promoted from int to ulong and overflowing.
// The loop executes 4 times, when i is -1, 0, 1, and 2.
for (auto i = -1; i < cast(int)something.length; ++i) {
writeln("i: ", i);
}
return 0;
}
```
output:

len: 3
typeid(something.length): ulong
i: -1
i: 0
i: 1
i: 2


Re: Providing implicit conversion of

2024-01-21 Thread thinkunix via Digitalmars-d-learn

Gavin Gray via Digitalmars-d-learn wrote:

The following code:

   ulong charlie = 11;
   long johnstone = std.algorithm.comparison.max(0, -charlie);
   writeln(format!"johnstone %s"(johnstone));

Results in (without any warning(s)):
johnstone -11

However you choose to look at it, this means -11 > 0 (regardless of all 
arguments concerning implicit conversions, 1's and 2's complements, 
being efficient, etc).


The language should not allow unary unsigned anything.



I have no idea what your use case is for this but...
WHY are you doing this??

If you declared charlie as unsigned, why would you then attempt to
compare using a negative value?  If you even had the possibility that
charlie might be negative, why wouldn't you use a type that can 
accomodate the sign?


Using the proper type, you get a proper result:

long b = 12;
long n = std.algorithm.comparison.max(0, -b);
long o = std.algorithm.comparison.max(0, b);
writeln("n: ", n);  // prints 0
writeln("o: ", o);  // prints 12

Seems obvious to me, but am I missing something?

scot


Re: Reading .txt File into String and Matching with RegEx

2023-12-10 Thread thinkunix via Digitalmars-d-learn

BoQsc via Digitalmars-d-learn wrote:
This is something I've searched on the forum and couldn't find exact 
answer.


TLDR: `r"^."` is matching the very first two character in the `input` 
string.


Don't you need two dots to match two characters?
Each dot being the regex to match a single character,
so `r"^.."` instead of `r"^."` to get the first two characters.

When I run your program (on linux with rdmd from DMD 2.106.0), I get:

[["H"]]


Re: anonymous structs within structs

2023-12-04 Thread thinkunix via Digitalmars-d-learn

DLearner via Digitalmars-d-learn wrote:

On Monday, 4 December 2023 at 21:55:29 UTC, Mike Shah wrote:

[...]


Is something like this what you had in mind?

```
void main() {
   import std.stdio;

   mixin template A() {
  int I1;
  int I2;
  char X;
   }

   struct B {
  mixin A;
  int Var1;
  int Var2;
   }

    B someObject;
    writeln(someObject.I1);
    writeln(someObject.I2);
}
```


More like
```
B someObject;
  writeln(someObject.Var1);
  writeln(someObject.Var2);
```

In the areas where B is used, don't want I1 or I2 to be visible.



If you don't want members of A to be visible in B, why are you
even including struct A as part of B?

Why wouldn't you use a class and make the members private?

I'm certainly not a D expert and I don't know your use case
so maybe I'm missing something.

scot


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: cannot find source code for runtime library file 'object.d'

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

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

I'm not familiar with zypper but I'll bet you can install it by:
# zypper install ./dmd-2.105.3-0.openSUSE.x86_64.rpm

On a RHEL-like distro, this works:
# yum install ./pkgname.rpm

Just be sure to use your package manager tool (yum, zypper, whatever)
to install the binary so it can later be removed or updated.


More details:

I ran into something similar,'object.d' not found, when trying to
build dmd from source.  In the end I grabbed the prebuilt dmd binary
RPM from dlang.org and followed the locations where it placed files,
then everything "just works".

If you have the rpm command, you can run the following to get the file
list without installing it:

$ rpm -qlp pkgname.rpm

If you do not have the rpm command, you can use rpm2cpio to convert the
rpm into a cpio archive, then read it:

$ rpm2cpio pkgname.rpm > pkgname.cpio
$ cpio -itv < pkgname.cpio | more



$ cat /etc/dmd.conf
[Environment32]
DFLAGS=-I/usr/include/dlang/dmd -L-L/usr/lib -L--export-dynamic -fPIC

[Environment64]
DFLAGS=-I/usr/include/dlang/dmd -L-L/usr/lib64 -L--export-dynamic -fPIC



Here's what's in my /etc/dmd.conf;
Note there is no 'dlang' subdir in /usr/include, just 'dmd'.

cut here
[Environment32]
DFLAGS=-I/usr/include/dmd/phobos -I/usr/include/dmd/druntime/import 
-L-L/usr/lib -L--export-dynamic -fPIC


[Environment64]
DFLAGS=-I/usr/include/dmd/phobos -I/usr/include/dmd/druntime/import 
-L-L/usr/lib64 -L--export-dynamic -fPIC

cut here



$ ls /usr/include/dlang/dmd



/usr/include/dmd should have two directories:  druntime and phobos,
nothing else.

object.d lives here:
/usr/include/dmd/druntime/import/object.d



$ cat /etc/os-release
NAME="openSUSE Tumbleweed"
VERSION="20231006"

$ dmd --version
DMD64 D Compiler v2.105.3
```

Help?


If you decide to build from source, keep in mind you need a D
compiler to build dmd.  Either use a binary tarball from dlang.org,
or you have to bootstrap dmd 2.067.1 with a C++ compiler, then
keep upgrading dmd until you get to the version you want.  It can be
done and does work, but takes time.  Instructions are here:

https://wiki.dlang.org/Building_under_Posix

I'm guessing the person who build the package was thinking they
wanted to allow allow installing mulitple D compilers, all under
/usr/include/dlang, like so:

/usr/include/dlang/{dmd,gdc,ldc2}

and libraries would go under /usr/lib64/dlang/{dmd,gdc,ldc2}.
I made several attempts at this and they failed.  Like I said,
follow the locations of the dlang.org prebuilt rpm and it all
just works, or use a binary from dlang.org.

scot


Re: Indenting standards religions K, whitesmiths etc

2023-05-31 Thread thinkunix via Digitalmars-d-learn

matheus via Digitalmars-d-learn wrote:

On Wednesday, 31 May 2023 at 16:24:38 UTC, Cecil Ward wrote:

...
So my question: would I get lynched for the following? (below)
...


I don't know nothing about all this but looking your example code, I 
write and I'd prefer to read something like this (Editing your own code):



pure nothrow etc T foo(T, T2)(in T param x,in T2 param y)
if (template-qualification-whatever) in {
     static assert(…);
}
out (ret){
     …
     assert(test ret);
}do{
    blah
    if (test) {
   if-body
   …
    }
    back to main block
    …
    …
}

Matheus.


+1 here.  I think Matheus's code is much easier to read.
Code that is easy to read is easier to understand.


Re: phobos build issue with dmd-2.102.2 (RESOLVED)

2023-05-09 Thread thinkunix via Digitalmars-d-learn

This is a followup to my original post on March 9 about issues building
dmd-2.102.2 on an old Linux x86_64 system.

See bugzilla:
https://issues.dlang.org/show_bug.cgi?id=23846

The short answer is it is fixed as of dmd-2.104.0-beta.1, that version
now builds dmd and phobos successfully.



Re: Linking external functions?

2023-04-18 Thread thinkunix via Digitalmars-d-learn

DLearner via Digitalmars-d-learn wrote:

On Tuesday, 18 April 2023 at 21:31:21 UTC, thinkunix wrote:
[...]

If not calling C code, why use extern(C) for D code?
Wanted to test out options of calling D routine (possibly -betterC) from 
both C and (full) D.





OK, thanks.


Re: Linking external functions?

2023-04-18 Thread thinkunix via Digitalmars-d-learn

DLearner via Digitalmars-d-learn wrote:

Wanted to try out linking two source files independantly compiled.

ExtCallee.d source file:
```
extern(C) void ExtCallee() {
    import std.stdio;

    writeln("Entered: ", __FUNCTION__);
    writeln("Exiting: ", __FUNCTION__);
}
```
ExtMain.d source file:
```
void main() {
    import std.stdio;
    extern(C) void ExtCallee();


    writeln("Entered: ", __FUNCTION__);

    ExtCallee();

    writeln("Exiting: ", __FUNCTION__);
}



What is the advantage of using extern(C)?
Since both are D source files, why wouldn't you do just this:

```d
// ExtCallee.d
void ExtCallee()
{
import std.stdio;

writeln("Entered:  ", __FUNCTION__);
writeln("Exiting:  ", __FUNCTION__);
}
```

```d
// ExtMain.d
void main()
{
import std.stdio;
import ExtCallee;

writeln("Entered:  ", __FUNCTION__);

// I had to scope this to get it to compile
// If instead I put the function in myfn.d and
// did "import myfn;" it works without the scope operator.
ExtCallee.ExtCallee();

writeln("Exiting:  ", __FUNCTION__);
}
```

Compile with:
$ dmd ExtCallee.d ExtMain.d -of=prog


Without extern(C), the linker mangles names:

$ nm ExtCallee.o | grep ExtCallee
 R _D9ExtCallee12__ModuleInfoZ
 W _D9ExtCalleeQkFZv

$ nm ExtMain.o | grep ExtCallee
 U _D9ExtCalleeQkFZv


With extern(C), the linker does not mangle names:

$ nm ExtCallee.o | grep ExtCallee
 W ExtCallee
 R _D9ExtCallee12__ModuleInfoZ

$ nm ExtMain.o | grep ExtCallee
 U ExtCallee


If not calling C code, why use extern(C) for D code?
scot


Re: short guide on getting started with D

2023-04-04 Thread thinkunix via Digitalmars-d-learn

cgenie via Digitalmars-d-learn wrote:

Hello,

I created a short guide on getting started with D: 
https://blog.mmksoft.uk/#A%20short%20guide%20on%20getting%20started%20with%20D%20programming 



This is because I recently I started to explore the language and, having 
read the forum, I see DUB being discouraged quite often.


I would appreciate any remarks.



My observations:
#1 typo:  After that, add this meso.build file:

"meso.build" should be "meson.build"

#2 Does it matter where the dlang = import... block goes in the
meson.build file?  I added it after the "test(..." in the first
block and it seemed to work, but...

#3 where is dep?  Is it a file or do I have to create it?

I could only get you demo to work by removing the line

  dependencies: deps

from meson.build.  Then it created dub.json and dub ran it OK.

No need for a reply, just my obvservations from someone who knows
a little D and less meson.

scot




phobos build issue with dmd-2.102.2

2023-03-08 Thread thinkunix via Digitalmars-d-learn

Hello all,

I have an older system I am trying to build dmd-2.102.2 on from source:

stock Slackware 14.0 x86_64
binutils 2.22.52.0.2, gcc 4.7.1, glibc 2.15, kernel 3.2.x, and
dmd-2.102.1 installed (which I built from source on this system)

I started with dmd-2.067.1, bootstrapped it with only a C++ compiler,
mainly to see if it could done.  It built no problem.  I then used
the dmd just built to build newer versions.  This worked fine up
through dmd-2.102.1.

I have a script that builds dmd, druntime, phobos, and some D tools,
in that order.  I patterned it after instructions in the wiki:
[https://wiki.dlang.org/Building_under_Posix] using the
"make -f posix.mak" build commands for all steps.

Attempting to build dmd-2.102.2, it builds dmd and druntime OK,
but fails building phobos in unittest code, specifically in
phobos-2.102.2/std/math/exponential.d.

...(I removed duplicate 'Error' lines)...

std/math/exponential.d(3782): Error: number `0x0.8p-126f` is not 
representable as a `float`
std/math/exponential.d(3784): Error: number `0x0.56p-126f` is not 
representable as a `float`
std/math/exponential.d(3795): Error: number `0x0.8p-1022` is not 
representable as a `double`
std/math/exponential.d(3797): Error: number `0x0.5p-1022` is 
not representable as a `double`

make: *** [generated/linux/release/64/libphobos2.a] Error 1


It appears related to this commit:
https://github.com/dlang/phobos/commit/a76836b5a66f2e6f89026f48b0a53100d4b65a75

I ran the same build script for dmd-2.102.2 on another system and
everything built OK:

Slackware 14.1 x86_64 heavily modified
binutils 2.25.1, gcc 4.9.4, glibc 2.17, kernel 3.16.x, and
dmd-2.102.1 installed (also built from source)

I was thinking this might be a glibc or binutils issue since
versions are different between the two systems.  I ran the
following tests on both systems:

```c
/* C99: testfloat.c */
/* compile:  gcc -std=c99 testfloat.c */
#include 
int main()
{
float f = 0x0.8p-126f;
printf("f: %0lg\n", f);
return 0;
}
```

The C program is compiled with the system's C compiler.
It prints the same output on both systems:
$ gcc -std=c99 testfloat.c; ./a.out
f: 5.87747e-39

Then I tried the D version, using the existing dmd-2.102.1:

```d
// testfloat.d
import std.stdio;
int main()
{
float f = 0x0.8p-126f;
writeln("f: ", f);
return 0;
}
```

Slackware 14.1 host prints, same as the C version:
f: 5.87747e-39

Slackware 14.0 host returns an error:
$ rdmd testfloat.d
testfloat.d(5): Error: number `0x0.8p-126f` is not representable as a 
`float`

testfloat.d(5):https://dlang.org/spec/lex.html#floatliteral
Failed: ["/usr/bin/dmd", "-v", "-o-", "testfloat.d", "-I."]


Comparing the build logs the only difference I found was in the
phobos build.  Slackware 14.1 has extra options, that I did not add.
I'm not sure where these are coming from:

-shared -defaultlib= -debuglib= -L-lpthread -L-lm

../dmd/generated/linux/release/64/dmd  -conf= -I../dmd/druntime/import 
-w -de -preview=dip1000 -preview=dtorfields -preview=fieldwise -m64 
-fPIC -O -release -shared -defaultlib= -debuglib= -L-lpthread -L-lm 
-ofgenerated/linux/release/64/libphobos2.so.0.102.2 
-L-soname=libphobos2.so.0.102 
../dmd/druntime/../generated/linux/release/64/libdruntime.so.a -L-ldl 
std/array.d std/ascii.d ...massive line

trimmed...

The Slackware 14.0 only has -lib, none of the other options.
The rest of this huge line is the same.

../dmd/generated/linux/release/64/dmd  -conf= -I../dmd/druntime/import 
-w -de -preview=dip1000 -preview=dtorfields -preview=fieldwise -m64 
-fPIC -O -release -lib -ofgenerated/linux/release/64/libphobos2.a 
../dmd/druntime/../generated/linux/release/64/libdruntime.a std/array.d 
std/ascii.d  ...massive line trimmed...



This is mainly an academic exercise, but I would like to understand
why the phobos build fails on the older system.

thanks,
scot