Please verify: Traceinfo gone

[frame via Digitalmars-d-learn]

On Sunday, 25 July 2021 at 11:17:26 UTC, frame wrote:

The issue is: w/o calling test() there are stack lines 
available but when I compile it with the test() call, no stack 
lines are available?


So if my usage is valid I would file a bug report - but maybe my 
setup is just broken.
Could some Windows user please verify this issue with static 
linked?


```d
try
{
   throw new Exception("test");
}
catch (Throwable e)
{
   const(char)[] lines;
   foreach (n; e.info) lines ~= n;
   assert(lines.length == 0); // true if test() call was compiled 
in

}
```

Re: POST request with std.net.curl

[frame via Digitalmars-d-learn]

On Monday, 26 July 2021 at 14:13:53 UTC, bachmeier wrote:

In doubt you can turn on the verbose() method on the HTTP 
object.


That's a modest improvement (for the small number of people 
that find the option in the docs) but definitely not at the 
same level of information as the curl CLI. I created an issue 
requesting better output: 



I see your intention but this is a bad example. Status 400 means 
"Bad request" because of a wrong header or wrong payload or any 
error in the request. "Empty content" wouldn't describe the 
actual error if you have sent data.


In fact the client cannot know whats wrong. "Content-Type: 
Application/json" may be wrong from the sight of the server 
(which is NOT, they are case insensitive btw) but the protocol 
allows you to use whatever content-type you want and no client 
needs to know how to handle all. It's just wrong if your CLI tool 
interprets a status 400 as "Empty content" by arbitrary 
assumptions.


All better the lib could do is to print the text for the status 
too and the raw payload sent by the server aka error description, 
if any.

Re: Passing delegate indirectly to createLowLevelThread doesn't work

[Tejas via Digitalmars-d-learn]

On Monday, 26 July 2021 at 17:21:04 UTC, Adam D Ruppe wrote:

On Monday, 26 July 2021 at 17:14:45 UTC, Tejas wrote:
Yeah after reading the error diagnostics carefully I realized 
that the compiler is inferring many attributes when passing 
```func``` directly but not when passing via delegate


Well, technically, it is inferred there too, but since you 
specified `void delegate()` it implicitly casts to that and 
drops the detail.


Similar to the difference between like

Object o = new MyClass;
// now o is still Object since the class implicitly casted and 
thus drops the extensions in the child class


and

auto c = new MyClass;
// no conversion requested there, c has the full type of MyClass


Thank you very much for further explaining this :D

Re: Passing delegate indirectly to createLowLevelThread doesn't work

[Adam D Ruppe via Digitalmars-d-learn]

On Monday, 26 July 2021 at 17:14:45 UTC, Tejas wrote:
Yeah after reading the error diagnostics carefully I realized 
that the compiler is inferring many attributes when passing 
```func``` directly but not when passing via delegate


Well, technically, it is inferred there too, but since you 
specified `void delegate()` it implicitly casts to that and drops 
the detail.


Similar to the difference between like

Object o = new MyClass;
// now o is still Object since the class implicitly casted and 
thus drops the extensions in the child class


and

auto c = new MyClass;
// no conversion requested there, c has the full type of MyClass

Re: Passing delegate indirectly to createLowLevelThread doesn't work

[Tejas via Digitalmars-d-learn]

On Monday, 26 July 2021 at 17:01:13 UTC, JG wrote:

On Monday, 26 July 2021 at 16:46:40 UTC, Tejas wrote:

On Monday, 26 July 2021 at 15:42:44 UTC, Paul Backus wrote:

On Monday, 26 July 2021 at 15:29:26 UTC, Tejas wrote:

[...]


The delegate must be `nothrow`:

```d
void delegate() nothrow f;
```


Doesn't seem to matter. I tried that beforehand. And even if 
it did why does passing it directly work without explicitly 
qualifying it as nothrow then?


It does work for me. To me running the following explains why:

```d
import std;
import core.thread.osthread;

void delegate() f;
void main()
{
void func(){}
f = 
pragma(msg,typeof());
pragma(msg,typeof(f));
createLowLevelThread(, 2<<30);//works
//createLowLevelThread(f, 2<<30);// doesn't  work!!
}
```


Yeah after reading the error diagnostics carefully I realized 
that the compiler is inferring many attributes when passing 
```func``` directly but not when passing via delegate

Re: __FILE__

[Stefan Koch via Digitalmars-d-learn]

On Monday, 26 July 2021 at 12:01:23 UTC, Adam D Ruppe wrote:

On Monday, 26 July 2021 at 11:43:56 UTC, workman wrote:

__FILE__[0..$]


Why do you have that [0..$] there? It is probably breaking the 
__FILE__ magic.


Correct.
The compiler has to evaluate the default argument as constant 
expression in order to use it as default value..
Therefore it evaluates (__FILE__)[0 ..$]you first eval __FILE__ 
at CTFE within the module you are defining the function in.

And then you slice it from zero to length.

On the other hand if you use x = __FILE__ it recognizes that as a 
special constant expression which can be put into the callsite 
directly.

Re: Passing delegate indirectly to createLowLevelThread doesn't work

[JG via Digitalmars-d-learn]

On Monday, 26 July 2021 at 16:46:40 UTC, Tejas wrote:

On Monday, 26 July 2021 at 15:42:44 UTC, Paul Backus wrote:

On Monday, 26 July 2021 at 15:29:26 UTC, Tejas wrote:

```d
import std;
import core.thread.osthread;

void delegate() f;
void main()
{
void func(){}
f = 
createLowLevelThread(, 2<<30);//works
createLowLevelThread(f, 2<<30);// doesn't  work!!
}

```

Can someone help?


The delegate must be `nothrow`:

```d
void delegate() nothrow f;
```


Doesn't seem to matter. I tried that beforehand. And even if it 
did why does passing it directly work without explicitly 
qualifying it as nothrow then?


It does work for me. To me running the following explains why:

```d
import std;
import core.thread.osthread;

void delegate() f;
void main()
{
void func(){}
f = 
pragma(msg,typeof());
pragma(msg,typeof(f));
createLowLevelThread(, 2<<30);//works
//createLowLevelThread(f, 2<<30);// doesn't  work!!
}
```

Re: Passing delegate indirectly to createLowLevelThread doesn't work

[Tejas via Digitalmars-d-learn]

On Monday, 26 July 2021 at 16:46:40 UTC, Tejas wrote:

On Monday, 26 July 2021 at 15:42:44 UTC, Paul Backus wrote:

On Monday, 26 July 2021 at 15:29:26 UTC, Tejas wrote:

```d
import std;
import core.thread.osthread;

void delegate() f;
void main()
{
void func(){}
f = 
createLowLevelThread(, 2<<30);//works
createLowLevelThread(f, 2<<30);// doesn't  work!!
}

```

Can someone help?


The delegate must be `nothrow`:

```d
void delegate() nothrow f;
```


Doesn't seem to matter. I tried that beforehand. And even if it 
did why does passing it directly work without explicitly 
qualifying it as nothrow then?


Sorry, it seems to work now.

But why didn't it fail when I didn't qualify ```func``` as 
nothrow?

Re: Passing delegate indirectly to createLowLevelThread doesn't work

[Tejas via Digitalmars-d-learn]

On Monday, 26 July 2021 at 15:42:44 UTC, Paul Backus wrote:

On Monday, 26 July 2021 at 15:29:26 UTC, Tejas wrote:

```d
import std;
import core.thread.osthread;

void delegate() f;
void main()
{
void func(){}
f = 
createLowLevelThread(, 2<<30);//works
createLowLevelThread(f, 2<<30);// doesn't  work!!
}

```

Can someone help?


The delegate must be `nothrow`:

```d
void delegate() nothrow f;
```


Doesn't seem to matter. I tried that beforehand. And even if it 
did why does passing it directly work without explicitly 
qualifying it as nothrow then?

Re: Performance issue with fiber

[jfondren via Digitalmars-d-learn]

On Monday, 26 July 2021 at 15:27:48 UTC, russhy wrote:

```

build:

```
dub build --compiler=ldc -brelease --single primesv1.d
```




-brelease is a typo issue, i don't think that produce defired 
effect, most likely it defaulted to debug build


it should be -b release


No, it builds a release build with -brelease. Try it yourself, 
the first line of output tells you what the build type is. 
Instead of interpreting -abc as -a -b -c like getopt, dub 
interprets it as -a bc


--arch/-a works the same way, and although I don't see this usage 
in the official documentation, I didn't make it up:


https://duckduckgo.com/?q=dub+%22brelease%22=1

Re: Passing delegate indirectly to createLowLevelThread doesn't work

[Paul Backus via Digitalmars-d-learn]

On Monday, 26 July 2021 at 15:29:26 UTC, Tejas wrote:

```d
import std;
import core.thread.osthread;

void delegate() f;
void main()
{
void func(){}
f = 
createLowLevelThread(, 2<<30);//works
createLowLevelThread(f, 2<<30);// doesn't  work!!
}

```

Can someone help?


The delegate must be `nothrow`:

```d
void delegate() nothrow f;
```

Re: Performance issue with fiber

[russhy via Digitalmars-d-learn]

```

build:

```
dub build --compiler=ldc -brelease --single primesv1.d
```




-brelease is a typo issue, i don't think that produce defired 
effect, most likely it defaulted to debug build


it should be -b release

Passing delegate indirectly to createLowLevelThread doesn't work

[Tejas via Digitalmars-d-learn]

```d
import std;
import core.thread.osthread;

void delegate() f;
void main()
{
void func(){}
f = 
createLowLevelThread(, 2<<30);//works
createLowLevelThread(f, 2<<30);// doesn't  work!!
}

```

Can someone help?

Re: POST request with std.net.curl

[bachmeier via Digitalmars-d-learn]

On Sunday, 25 July 2021 at 15:44:14 UTC, frame wrote:

On Sunday, 25 July 2021 at 13:07:36 UTC, bachmeier wrote:

On Friday, 23 July 2021 at 18:11:51 UTC, bachmeier wrote:

[...]

After all this, it turned out the answer was a simple (but not 
obvious) typo in the header information. It would be nice to 
get more information than "HTTP request returned status code 
400 ()". I don't know if that's possible, but command line 
curl provides better messages.


In doubt you can turn on the verbose() method on the HTTP 
object.


That's a modest improvement (for the small number of people that 
find the option in the docs) but definitely not at the same level 
of information as the curl CLI. I created an issue requesting 
better output: 

Re: Performance issue with fiber

[hanabi1224 via Digitalmars-d-learn]

Thank you for your response! I've got some questions tho.

On Saturday, 24 July 2021 at 09:17:47 UTC, Stefan Koch wrote:


It will not use a fiber pool.


Why fiber pool? Isn't fiber a lightweight logical thread which is 
already implemented with thread pool internally?


Spawning a new fiber is expensive because of the stack 
allocation for it.


Actually, I've benchmarked many stackful coroutine 
implementations in different langs but they're all much faster, 
and BTW, AFAIK go's goroutine is stackful as well (4KB IIRC)

Re: __FILE__

[Adam D Ruppe via Digitalmars-d-learn]

On Monday, 26 July 2021 at 11:43:56 UTC, workman wrote:

__FILE__[0..$]


Why do you have that [0..$] there? It is probably breaking the 
__FILE__ magic.

__FILE__

[workman via Digitalmars-d-learn]

file test.d:

-
module test;
import abc;
void doTest(){
log!"test"();
}
---

file abc.d:
-
module abc;
import test;
void log(string fmt, int line = __LINE__, string path = 
__FILE__[0..$], A...)(A a) {

import core.stdc.stdio;
printf("[%s:%d] \n", path.ptr, line);
}
extern(C) int main() {
doTest();
return 0;
}

-

retult: [abc.d:4]

expect: [test.d:4]

Re: byKeyValue is not available at compilation-time right ?

[Mike Parker via Digitalmars-d-learn]

On Sunday, 25 July 2021 at 17:38:23 UTC, someone wrote:


i.e. your AA initialization is copy-pasted into each use of 
it, which means your program is rebuilding this AA at runtime 
every time it comes up. You probably got to this point as a 
bare `immutable structureLocations` errored out to the 
non-constant expression.


Sounds bad, inefficient at least :(


The whole point of a manifest constant is that it is purely a 
compile-time entity that does not exist at runtime. It has no 
address. In other words, `enum a = 10` can be seen as an alias to 
the integer literal `10`. That means anywhere you use `a`, it's 
just like you typed in `10` instead. It is *not* the same as a 
`const` or `immutable` value.


Think of them as a way to avoid "magic literals". Instead of 
typing `10` or `[1, 2, 3]` in multiple initializers or function 
calls, you use an alias instead, then when you decide to use `20` 
or `[2, 4, 6]` instead, you can simply change the declaration of 
the manifest constant instead of at multiple locations. But 
you're *still* effectively passing a literal. So if at certain 
points in your code you want to avoid any allocations a literal 
would trigger, then you shouldn't be using manifest constants at 
those points either.