September 09

On Monday, 9 September 2024 at 17:56:04 UTC, monkyyy wrote:

>

On Monday, 9 September 2024 at 17:39:46 UTC, WraithGlade wrote:

>

import std;
auto parse(char[] s)=>s[9..$-2];
void show(T,string file= FILE,int line=LINE)(T t){
writeln(File(file).byLine.drop(line-1).front.parse," == ",t);
}
void main(){
int i=3;
show(i++ + ++i * i);
show(i);
}

I tested this version on my machine and the output isn't correct. It gets cut off.

Here's the reformatted and slightly altered version I tested:

import std;

auto parse(char[] s) => s[9 .. $ - 2];

void show(T, string file = __FILE__, int line = __LINE__)(T t) {
  File(file)
    .byLine
    .drop(line - 1)
    .front
    .parse
    .writeln(" == ", t);
}

void main(){
  int i = 3;
  show(i++ + ++i * i);
  show(i);
}

It outputs this erroneous result:

+ + ++i * i) == 28
 == 5

This is not that surprising considering it uses hardcoded numbers and doesn't look right.

Also, moving the built EXE out of the source code directory and into a different folder causes the program to crash when it runs due to not being able to find the source code file.

That seems to indicate that this code's file reading doesn't actually happen in compile-time. Maybe there are compiler build options for D that'll write this in in compile time though?

In any case, this version seems more brittle than the others at least

September 09

On Monday, 9 September 2024 at 20:52:09 UTC, WraithGlade wrote:

>

This is not that surprising considering it uses hardcoded numbers and doesn't look right.

I made it on dlang.io which does space tabs, if its not ovisous to a beginner, parse is lazy not correct, it need to do find substring nonsense for real code

>

That seems to indicate that this code's file reading doesn't actually happen in compile-time. Maybe there are compiler build options for D that'll write this in in compile time though?

This is one of the old fights, you will have a bad time

"ctfe io isnt safe", if your making your own build system -J=. and string imports are an option but that will not be aviable for generic code; meaning you cant make something nice for the std.

September 09

On Monday, 9 September 2024 at 20:52:09 UTC, WraithGlade wrote:

>

In any case, this version seems more brittle than the others at least

After all, you will need it in 2 ways: 1. to learn, 2. to test. After testing, you can disable it with just the version parameter while compiling. It is even possible to turn it on/off by embedding ```// version = logOn; in the code and removing the comment feature. For this, embed VERSION(logOn) in the relevant lines...

SDB@79

September 11

On Sunday, 8 September 2024 at 22:01:10 UTC, WraithGlade wrote:

>

Specifically, I want a way to create a print command that behaves like @show from Julia lang or dump from (if my memory is correct) Nim.

Yes.

https://github.com/baryluk/echo/blob/master/echo.d#L205-L209

mixin(echo("echo test: i=$i j=$j Escaping: \\$j, Complicated i+j=${i+j}, End of tests."));

There are other ways of doing similar (using mixing templates for example), but the machinery would be very similar.

This code is about 13 years old, but still works. (It is functional and works, but I never it used more than what is in this repo).

But now that we have interpolation sequences in the language, it would be way easier, cleaner and more powerful to use them.

I have my custom Linux IO library, that utilizes this, and you can do thing like this:

Println(i"Ala ma $(ShortHex(123+foo*bar)) $(&m3) $(y.ptr) maybe");

(with zero memory allocations or excessive memory copies).

September 11

On Wednesday, 11 September 2024 at 18:29:39 UTC, WB wrote:

>

This code is about 13 years old, but still works. (It is functional and works, but I never it used more than what is in this repo).

But now that we have interpolation sequences in the language, it would be way easier, cleaner and more powerful to use them.

        assert(echo2("T $i, b, ${i-2}") == "writefln(\"T \", i, \", b, \", (i-2));\n");

It looks clean and understandable. What is not understandable is that it has not been included in std.stdio for over 10 years. I know, string interpolation has just been integrated, but why hasn't something like this been developed in 10 years that would have no side effects and would attract the attention of beginners?

SDB@79

September 11

On Wednesday, 11 September 2024 at 19:44:54 UTC, Salih Dincer wrote:

>

It looks clean and understandable. What is not understandable is that it has not been included in std.stdio for over 10 years. I know, string interpolation has just been integrated, but why hasn't something like this been developed in 10 years that would have no side effects and would attract the attention of beginners?

SDB@79

Honestly, D, does not really need it, and most of solutions (like above) do have one or few limitations and drawbacks. Some will be acceptable in some projects, some not.

There is plenty of stuff in language and library already, adding small things like that are not really the best thing. There is plenty of very successful languages, that do not offer this (Go, C++, Python 3.5 and earlier, Lua, older JavaScript, etc) and just adding it will not make D automatically more successful. I feel there is too much already in D and standard library, and things are added to quickly and eagerly, and years later we end up in a mess that cannot be solved (because of compatibility).

Interpolation strings (added this year) are ok and pretty decent, and well tough in terms of what one can do with them. We still do not know if it is a good or bad design, but we will see. Interpolation string are way more powerful, and cleaner, so it is good half solution like my mixin echo code was not used as a general solution.

If you want to use something, just put it in your own project, and it will work to your liking. It does not need to be in a standard library.

September 11

On Wednesday, 11 September 2024 at 22:06:54 UTC, WB wrote:

>

I feel there is too much already in D and standard library, and things are added to quickly and eagerly, and years later we end up in a mess that cannot be solved (because of compatibility).

this isnt autodecoding, cant be, your oping in debuging code and is for temp stuff

September 12

On Wednesday, 11 September 2024 at 22:06:54 UTC, WB wrote:

>

Honestly, D, does not really need it, and most of solutions (like above) do have one or few limitations and drawbacks. Some will be acceptable in some projects, some not.

There is plenty of stuff in language and library already, adding small things like that are not really the best thing. There is plenty of very successful languages, that do not offer this (Go, C++, Python 3.5 and earlier, Lua, older JavaScript, etc) and just adding it will not make D automatically more successful. I feel there is too much already in D and standard library, and things are added to quickly and eagerly, and years later we end up in a mess that cannot be solved (because of compatibility).

Yes, I agree; what I see is a very complicated Phobos2. Because it has become like this over time and submodules have been developed to eliminate the confusion. For example, there are things in std.math that we do not use often, a very basic algorithm like gcd() is expected to be written in std.numeric or the factorial() function by you.

In short, Phobos3 will adapt better to the language for beginners if it is written systematically from the beginning; std.math should be reorganized from scratch.

SDB@79

1 2
Next ›   Last »