Can opDollar support a jagged 2D array?
Suppose I have a data structure encoding sequence lengths: seq1: 0 1 2 ... N seq2: 0 1 2 3 4 ... M seq3: 0 1 ... P I would like to write opIndex and opDollar to support the notation obj[seq, x .. $] to retrieve sequences. However, given that opDollar is templated on dimension (always 1 in this example) and has no information calling function's context/dimension 0 parameter, this seems impossible. Am I missing an easy solution? Kind regards
Re: Trying to create a trivial 64 bit D Lang DLL on a Windows 10 machine and cant get past linking.
On Thursday, 1 October 2020 at 21:35:42 UTC, WhatMeWorry wrote: On Thursday, 1 October 2020 at 20:28:58 UTC, kinke wrote: [...] Thanks all. I've gotten it to work with: [...] [...] [...] total = 12 [...] 1) try running your commands in Visual Studio Native x64 CMD. 2) try link with msvcrt.lib
Re: Trying to create a trivial 64 bit D Lang DLL on a Windows 10 machine and cant get past linking.
On Thursday, 1 October 2020 at 20:28:58 UTC, kinke wrote: On Thursday, 1 October 2020 at 20:03:19 UTC, WhatMeWorry wrote: Yes, but shouldn't the /NOENTRY option take care of that. Say, I just want to make a DLL of simple functions. Your little example has 2 problems, the first being an incompatible extern(D) ex/import (mydll.myAddSeven vs. user.myAddSeven) and the second being an incomplete/wrong linker cmdline. When changing the myAddSeven declarations to extern(C++) (another option being a mydll.di header for the import), it works with dmd -m64 -shared -L/NOENTRY mydll.d dmd -m64 user.d mydll.lib For more details, see also https://wiki.dlang.org/Win32_DLLs_in_D. Thanks all. I've gotten it to work with: dmd -m64 -ofmydll.dll mydll.d -L/NOENTRY -L/DLL dmd -m64 user.d mydll.lib user.exe total = 12 But then I got cocky and decided to just added a writeln() in the mydll.d file and I've been fighting this link error ever since: C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\bin\Hostx64\x64\link.exe /NOLOGO "mydll.obj" /OUT:"mydll.dll" /DEFAULTLIB:phobos64 /NOENTRY /DLL /OPT:NOICF /LIBPATH:"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\lib\x64" legacy_stdio_definitions.lib /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.18362.0\ucrt\x64" /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\lib\10.0.18362.0\um\x64" Creating library mydll.lib and object mydll.exp mydll.obj : error LNK2019: unresolved external symbol fwrite referenced in function _D3std5stdio__T13trustedFwriteTaZQsFNbNiNePOS4core4stdcQBx6_iobufxAaZm phobos64.lib(object_72_81a.obj) : error LNK2001: unresolved external symbol memcpy phobos64.lib(exception_cf4_fff.obj) : error LNK2001: unresolved external symbol memcpy phobos64.lib(bits_23fa_21c.obj) : error LNK2001: unresolved external symbol memcpy phobos64.lib(gc_2413_a4e.obj) : error LNK2001: unresolved external symbol memcpy phobos64.lib(gc_2415_a03.obj) : error LNK2001: unresolved external symbol memcpy phobos64.lib(gc_2478_432.obj) : error LNK2001: unresolved external symbol memcpy o o o
Re: Trying to create a trivial 64 bit D Lang DLL on a Windows 10 machine and cant get past linking.
On Thursday, 1 October 2020 at 20:03:19 UTC, WhatMeWorry wrote: Yes, but shouldn't the /NOENTRY option take care of that. Say, I just want to make a DLL of simple functions. Your little example has 2 problems, the first being an incompatible extern(D) ex/import (mydll.myAddSeven vs. user.myAddSeven) and the second being an incomplete/wrong linker cmdline. When changing the myAddSeven declarations to extern(C++) (another option being a mydll.di header for the import), it works with dmd -m64 -shared -L/NOENTRY mydll.d dmd -m64 user.d mydll.lib For more details, see also https://wiki.dlang.org/Win32_DLLs_in_D.
Re: Trying to create a trivial 64 bit D Lang DLL on a Windows 10 machine and cant get past linking.
On Thursday, 1 October 2020 at 09:22:29 UTC, user1234 wrote:
On Wednesday, 30 September 2020 at 11:45:53 UTC, Ferhat
Kurtulmuş wrote:
On Tuesday, 29 September 2020 at 21:22:21 UTC, WhatMeWorry
wrote:
module user;
export { int myAddSeven(int a, int b); }
[...]
it is better to use this template
https://github.com/dlang/dmd/tree/master/samples/mydll
You don't have a DllMain.
yeah that's the problem, check [0] OP. The author makes
commercial dll on windows so he knows what he speaks about
[0]
https://forum.dlang.org/post/mscgsclxwtjcferfx...@forum.dlang.org
Yes, but shouldn't the /NOENTRY option take care of that. Say, I
just want to make a DLL of simple functions.
Re: What classification should shared objects in qeued thread pools have?
On Thursday, 1 October 2020 at 14:12:24 UTC, Ola Fosheim Grøstad wrote: Also, atomic operations on members do not ensure the integrity of the struct. For that you need something more powerful (complicated static analysis or transactional memory). I'm very wary of being able to cast away shared, it might completely negate all the advertised (memory management) optimization opportunities for shared. For that to work you need some kind of "unshared" or "borrowed" like concept. Making all variables atomic in a shared struct is a intelligent as putting all hands on 4:00 on an analogue alarm clock if you want to wake up at 4:00. Atomic operations in itself does not ensure thread safety, you can still have races and the lockless algorithm might not be waterproof. They can be very difficult to design. Sometimes, this can show up months after a product has gone live. Furthermore, there is also the possibility to use locking primitives (mutexes, read write locks) inside a shared struct to ensure the thread safety. In that case you really don't all the data member operations to be atomic. In order to have "everything allowed" struct like in C++, shouldn't __gshared also work so that the allocator can successfully do its operations from several threads?
Re: What classification should shared objects in qeued thread pools have?
On Thursday, 1 October 2020 at 00:13:41 UTC, IGotD- wrote: For example completely lockless algorithms can often be a combination of atomic operations and also non-atomic operations on data members. Also, atomic operations on members do not ensure the integrity of the struct. For that you need something more powerful (complicated static analysis or transactional memory). I'm very wary of being able to cast away shared, it might completely negate all the advertised (memory management) optimization opportunities for shared. For that to work you need some kind of "unshared" or "borrowed" like concept.
Re: vibe.d / experience / feedback
On Thursday, 1 October 2020 at 06:32:23 UTC, Robert M. Münch wrote: Hi, we are currently using vibe.d for a prototype and I want to post some experiences. I know one shouldn't only address the problems but provide some solutions. [...] I've been in a similar position once... when it slows you down. Vibe could stay simple and break things down into separate packages. The docs is also a major issue. But try filling issues like these on the repo.
Re: vibe.d / experience / feedback
On Thursday, 1 October 2020 at 08:24:42 UTC, ab wrote: On Thursday, 1 October 2020 at 06:32:23 UTC, Robert M. Münch wrote: 3. Vibe can't handle GET & POST on the same URL... we solved this one as well: fortunately (and: of course) vibe can handle this. what lead us to believe otherwise, was that, unfortunately, one of the handlers crashed (effectively due to a `cast(JSONValue)` of a `Json.Undefined`), without any visible error output; and the only visible error was a "no route matches path" output from vibe. sorry for the confusion. did you run your app with `--`? it usually logs stuff like this there then.
Re: Trying to create a trivial 64 bit D Lang DLL on a Windows 10 machine and cant get past linking.
On Tuesday, 29 September 2020 at 21:22:21 UTC, WhatMeWorry wrote:
module user;
export { int myAddSeven(int a, int b); }
[...]
As example, DLL: https://github.com/vitalfadeev/dlang-dll
Re: Trying to create a trivial 64 bit D Lang DLL on a Windows 10 machine and cant get past linking.
On Wednesday, 30 September 2020 at 11:45:53 UTC, Ferhat Kurtulmuş
wrote:
On Tuesday, 29 September 2020 at 21:22:21 UTC, WhatMeWorry
wrote:
module user;
export { int myAddSeven(int a, int b); }
[...]
it is better to use this template
https://github.com/dlang/dmd/tree/master/samples/mydll
You don't have a DllMain.
yeah that's the problem, check [0] OP. The author makes
commercial dll on windows so he knows what he speaks about
[0]
https://forum.dlang.org/post/mscgsclxwtjcferfx...@forum.dlang.org
Re: vibe.d / experience / feedback
On Thursday, 1 October 2020 at 06:32:23 UTC, Robert M. Münch wrote: 3. Vibe can't handle GET & POST on the same URL... we solved this one as well: fortunately (and: of course) vibe can handle this. what lead us to believe otherwise, was that, unfortunately, one of the handlers crashed (effectively due to a `cast(JSONValue)` of a `Json.Undefined`), without any visible error output; and the only visible error was a "no route matches path" output from vibe. sorry for the confusion.
Re: vibe.d / experience / feedback
On Thursday, 1 October 2020 at 06:39:39 UTC, mipri wrote: On Thursday, 1 October 2020 at 06:32:23 UTC, Robert M. Münch wrote: 5. One can't access the raw HTTP request body, things must be go through Vibe's JSON parser. To get access to the raw body, a lot of workarounds are necessary. given an HTTPServerRequest req, req.bodyReader.readAll for binary data and .readAllUTF8 for text. thanks. that was tough to find from https://vibed.org/api/vibe.core.stream/InputStream (because it's located and thus documented in the helper module https://vibed.org/api/vibe.stream.operations/). a link from InputStream to vibe.stream.operations would be super-good.
Re: vibe.d / experience / feedback
On Thursday, 1 October 2020 at 06:32:23 UTC, Robert M. Münch wrote: 5. One can't access the raw HTTP request body, things must be go through Vibe's JSON parser. To get access to the raw body, a lot of workarounds are necessary. given an HTTPServerRequest req, req.bodyReader.readAll for binary data and .readAllUTF8 for text.
vibe.d / experience / feedback
Hi, we are currently using vibe.d for a prototype and I want to post some experiences. I know one shouldn't only address the problems but provide some solutions. However, our current use-case is that we want to get a job done, and not creating a web-framework. 1. For many things the docs are missing, or inconsistent, or wrong. So, it's pretty hard to make your way through it. Or you just start reading the code and reverse engineer vibe. => We are waisting a lot of time. 2. There are many inconsistencies / half-done implementations in vibe. Again, this makes it hard to find out what works, what doesn't or which parts behave differently. => Costs a lot of time. 3. Vibe can't handle GET & POST on the same URL... and the bad thing is, the later route will just be ignored, so you don't get any hint or crash. The docs don't mention this clearly. => We waisted a lot of time to find out, that this doesn't work. 4. Vide uses an own JSON type, not the standard one. We don't understand why, this just makes things much more complicated and one has to mess around with this. 5. One can't access the raw HTTP request body, things must be go through Vibe's JSON parser. To get access to the raw body, a lot of workarounds are necessary. So, overall... compared to other web-frameworks we know, there are many pitfalls which just cost a lot of time... We think it's a good base, but there needs to be much less magic, much better docs, much less complexity. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: Fiber based HTTP client for load testing
On Thursday, 1 October 2020 at 03:10:32 UTC, ikod wrote:
On Thursday, 1 October 2020 at 00:35:49 UTC, Arun wrote:
I have a REST client that can do load test of my REST
void main()
{
auto urls = ["http://httpbin.org/;,
"http://httpbin.org/image;];
foreach(url; urls)
{
runWorkerTask(, url);
Or maybe just `runTask(, url)` - I'm not sure which
function implements fiber and not worker thread.
