Re: Why DUB do not import local D modules dependencies?
On Saturday, 10 April 2021 at 02:10:48 UTC, Marcone wrote: How make dub import local D modules (mymodule.d) dependencies? Could you please provide more details about your scenario, otherwise it is quite hard to understand your question. Kind regards Andre
Why DUB do not import local D modules dependencies?
How make dub import local D modules (mymodule.d) dependencies?
Re: weird formattedRead
On 4/9/21 11:17 AM, Berni44 wrote: > I'm on reworking completely the docs of `std.format`. Awesome! :) Ali
Re: KQueue and Fibers
On 2021-04-09 11:00, rashir wrote:
Goodmorning everyone,
I'm trying to understand both Kqueue and Fiber's operation on Mac. Why
don't I get the correct data as long as I read from the socket?
It seems to be reading too early, but Kquue tells me that the socket is
readable.
```D
const bytesRead = recv(fd, b.ptr, readableAmount < b.length ?
readableAmount : b.length, 0);
writeln("read bytesRead: ", bytesRead, "readableAmount:",
readableAmount, " errno:", errno);
assert(bytesRead != EAGAIN && bytesRead != EWOULDBLOCK);
```
`recv` returns the number of bytes received or `-1` if an error
occurred. `EAGAIN` and `EWOULDBLOCK` are error codes. You should not
compare the value returned by `recv` with error codes. The error code
will be placed in `errno`.
```D
assert(eventList[0].filter & EVFILT_READ);
```
The `filter` field of an event is not a flag/bit field. It's just a
plain value, you should use `==` to check if it's a read event.
I'm not sure if fixing these things will solve your issue. But at least
some problems I noticed.
--
/Jacob Carlborg
Re: weird formattedRead
On Friday, 9 April 2021 at 16:11:26 UTC, Oleg B wrote: valid '1/1/1': 0001-Jan-01 00:00:00 <<< see here [...] Is space a special char for `formattedRead` and it simple stop parse without throwing exception if not found space (that represented in fmt string)? Have `formattedRead` any other special chars? Or it's bug? It's a (at least to me) known bug (I haven't taken the time to report it yet; found it a few days ago, when I reworked the docs). `formattedRead` treats space sometimes special and sometimes not, which (obviously) may lead to strange behavior, like it does here. If you like, you can [report this one](https://issues.dlang.org/enter_bug.cgi); I'll probably will care about it in a few weeks/months (I first want to fix the `formattedWrite` bugs and finish implementing formatting floating point numbers without calling `snprintf`.) On Friday, 9 April 2021 at 16:39:30 UTC, Ali Çehreli wrote: P.S. I can't check whether the D standard library documentation includes that information because the documentation looks very different and very skimpy to me at this time. There is nothing on format characters on formattedRead's documentation. (?) When using the `stable` docs you still should get, what you are used to. But I guess, you used the `master` docs and looked at `formattedWrite` where the information used to be. Since about three weeks I'm on reworking completely the docs of `std.format`. Before that, the module has been split in several submodules (package, read, write, specs). Meanwhile I moved the docs you know from `formattedWrite` to [package](https://dlang.org/phobos-prerelease/std_format.html) (but yet not reworked completely, because the review process takes some time and I try to verify everything I state in the new docs in the source code). For [`formattedRead`](https://dlang.org/phobos-prerelease/std_format_read.html#.formattedRead) and [reading in general](https://dlang.org/phobos-prerelease/std_format_read.html), the new docs are already finished. Feedback is welcome.
Re: weird formattedRead
On Friday, 9 April 2021 at 16:11:26 UTC, Oleg B wrote: Is space a special char for `formattedRead` and it simple stop parse without throwing exception if not found space (that represented in fmt string)? Have `formattedRead` any other special chars? Or it's bug? I think it's a bug: The char 0x20 is meant to be skipped till end of the string or a parseable char in the format string by the function readUpToNextSpec(). If the function found a whitespace in the input string, it's fine and skipped as long there is another whitespace char. But if the input string range is already done, it also does just nothing anymore. For other chars if would throw the 'Cannot find character' exception. But the source declared this as "backwards compatibility": ``` string s = " 1.2 3.4 "; double x, y, z; assert(formattedRead(s, " %s %s %s ", , , ) == 2); assert(s.empty); assert(approxEqual(x, 1.2)); assert(approxEqual(y, 3.4)); assert(isNaN(z)); ``` So it seems to be a desired behaviour.
Re: weird formattedRead
On 4/9/21 9:11 AM, Oleg B wrote: > Is space a special char for `formattedRead` and it simple stop parse > without throwing exception if not found space Yes: The space character means "zero or more white space". Ali P.S. I can't check whether the D standard library documentation includes that information because the documentation looks very different and very skimpy to me at this time. There is nothing on format characters on formattedRead's documentation. (?)
weird formattedRead
Hello, I have some doubts about working `formattedRead` with
space chars.
Example:
```d
import std : formattedRead, DateTime, stderr, each;
DateTime parseDT(string str)
{
int d,mo,y, h,m,s;
formattedRead!"%d/%d/%d %d:%d:%d"(str, d,mo,y, h,m,s);
return DateTime(y,mo,d, h,m,s);
}
void tryParse(string s)
{
try
{
auto dt = parseDT(s);
stderr.writefln!"valid '%s': %s"(s, dt);
}
catch (Exception e)
stderr.writefln!"INVALID '%s': %s"(s, e.msg);
}
void main()
{
auto vs = [
"",
"1",
"1/1",
"1/1/1",
"1/1/1 1",
"1/1/1 1:1",
"1/1/1 1:1:1",
];
vs.each!tryParse;
}
```
outputs:
```
INVALID '': 0 is not a valid month of the year.
INVALID '1': parseToFormatSpec: Cannot find character '/' in the
input string.
INVALID '1/1': parseToFormatSpec: Cannot find character '/' in
the input string.
valid '1/1/1': 0001-Jan-01 00:00:00 <<< see here
INVALID '1/1/1 1': parseToFormatSpec: Cannot find character ':'
in the input string.
INVALID '1/1/1 1:1': parseToFormatSpec: Cannot find character ':'
in the input string.
valid '1/1/1 1:1:1': 0001-Jan-01 01:01:01
```
Is space a special char for `formattedRead` and it simple stop
parse without throwing exception if not found space (that
represented in fmt string)?
Have `formattedRead` any other special chars?
Or it's bug?
Re: Counting number of regular expressions matches
On Friday, 9 April 2021 at 15:01:58 UTC, Alain De Vos wrote:
I've got,
import std.regex: regex,matchAll;
...
string regfiltertext="\\b"~entryfilter.getText()~"\\b";
auto reg = regex(regfiltertext);
auto result = name.strip("_").matchAll(reg);
int t=0;
foreach (c; result) t+=1;
This make t the number of regular expressions matches.
Is there a better way to have the number of matches ?
`matchAll` returns `RegexMatch` which is a ForwardRange, so it
should be possible to get it's length using `walkLength`.
```d
auto r = regex(`([a-z])a`);
auto result = "banana".matchAll(r);
writeln(result); // [["ba", "b"], ["na", "n"], ["na", "n"]]
writeln(result.walkLength); // 3
```
I'm not familiar with using matches with `std.regex`, but I hope
this solves your problem.
Counting number of regular expressions matches
I've got,
import std.regex: regex,matchAll;
...
string regfiltertext="\\b"~entryfilter.getText()~"\\b";
auto reg = regex(regfiltertext);
auto result = name.strip("_").matchAll(reg);
int t=0;
foreach (c; result) t+=1;
This make t the number of regular expressions matches.
Is there a better way to have the number of matches ?
Re: DMD64 2.095.1 unresolved _D4core8internal7switch___T14__switch_error in optimized build only
On Friday, 9 April 2021 at 12:41:02 UTC, MoonlightSentinel wrote: On Friday, 9 April 2021 at 11:36:21 UTC, x3g6h7k8 wrote: The interesting point is this happens only in optimized builds. In debug builds everything is fine. Looks like DMD skips the codegen for this template instance because it erroneously assumes that the template is already emitted in another object file. This decision is probably affected by some code in a `debug` statement which makes it work when compiling with `-debug`. You can try to compile the release version with `-allinst`. After posting my message I found this one by chance: https://forum.dlang.org/post/lixbkcxtalzplziwb...@forum.dlang.org It seems to be a different problem but has the same missing symbol (among others). So I tried the given solution there, doing a clean slate, removing project .dub/ and home dub/. This changed nothing on my side. Thereafter I removed the __"inline"__ from the regular dub release buildOptions. With this change an executable was created. Then I saw your reply. So far I can see there is no `debug` statement in my own code. However could it be that `unittest` blocks could trigger a similar behavior? An observation I made now was that compiling unit tests with __["optimize", "inline"]__ in an extra buildType were working fine too. Lastly I tried your suggestion with `-allinst`. This made no difference, same linking error. So for the time being I will stick to not using __"inline"__, this should be not a big problem. Thank you very much for your input to this problem.
Re: Is there a more elegant way to do this in D?
On Thursday, 8 April 2021 at 04:02:26 UTC, Ali Çehreli wrote:
On 4/7/21 8:57 PM, Brad wrote:
auto a = [1,0,1,1,1,0,1,0,1,1,1,1,0];
I want to come out of this with a string that looks like this:
101110100
Me, me, me, me! :)
import std;
void main()
{
auto a = [1,0,1,1,1,0,1,0,1,1,1,1,0];
string s = format!"%-(%s%)"(a);
writeln(s);
}
Ali
I'm really addict to the new shortened methods syntax
import std;
void main() =>
[1,0,1,1,1,0,1,0,1,1,1,0].
format!"%-(%s%)".
writeln;
Re: Asking about performance of std concatenation vs. Appender vs. custom class
reserving cuts down on the reallocations, but that only takes some of the time. Appending a 1000-element int array is going to go from a 16-byte block, to a 32-byte block, etc. up to a 4096 byte block. This involves roughly 8 reallocations per test. But every append requires an opaque function call into the runtime to check if the allocated length is big enough, and reallocate if necessary. So if the reallocations aren't too expensive, then appending performance would not be too much different. For ArrayBuilder, the function call to check length is there too, it is the grow() function. Sure reallocations take time. But the comment of the class talks about an increased performance thanks to *the base pointer being 4 system words instead of two* What did the dev mean by that? Yes, because Appender has direct access to the allocated length, rather than having to go through an opaque call. Alright, ArrayBuilder definitely benefits from the same. This I have no idea on. There are probably a lot of explanations that could be true. Have you tried profiling the code? I just tried to run dub test --build=profile on dterrent, but I get some obscure error message. Not working. Also tried to dmd -unittest -profile arraybuilder.d with an empty main(), not working, I don't get a trace.log. Am I supposed to create a main() test program to have access to profiling, that is to say there is no possible profiling of unittest? Are you compiling with -inline -O? -Steve -inline does not work (segfault) but optimize does not change anything except for stdLength (10ms) and ... ArrayBuilder, which gain even more performance (90ms). Conclusion, ArrayBuilder is still much more efficient, 15 years after this code was written :) It behaves closer to a regular array, maybe because of space reallocation strategy? Any comment appreciated
Re: DMD64 2.095.1 unresolved _D4core8internal7switch___T14__switch_error in optimized build only
On Friday, 9 April 2021 at 11:36:21 UTC, x3g6h7k8 wrote: The interesting point is this happens only in optimized builds. In debug builds everything is fine. Looks like DMD skips the codegen for this template instance because it erroneously assumes that the template is already emitted in another object file. This decision is probably affected by some code in a `debug` statement which makes it work when compiling with `-debug`. You can try to compile the release version with `-allinst`.
DMD64 2.095.1 unresolved _D4core8internal7switch___T14__switch_error in optimized build only
Working on a project with some dozen source files and an external dependency on botan building with integrated dub. There is only minimal templating used on my side. Using DMD 64bit 2.095.1 I get the following error: ``` app_win_dmd_a64_rel.obj : error LNK2019: unresolved external symbol _D4core8internal7switch___T14__switch_errorZQrFNaNbNiNfAyamZv referenced in function _D3std3uni__T21genericDecodeGraphemeVbi0Z__TQBfTAxwZQBnFNaNbNiNfKQrZv .dub\build\mainapp_win_dmd_a64_rel-release-windows-x86_64-dmd_v2.095.1-dirty-76A12175597E4044EE0E049BBF1AC35D\app_win_dmd_a64_rel.exe : fatal error LNK1120: 1 unresolved externals ``` The interesting point is this happens only in optimized builds. In debug builds everything is fine. It happens both with Windows DMD64 and Linux DMD64. Dub compile options in debug: ``` dmd -m64 -c -of.dub\build\app_win_dmd_...\app_win_dmd_a64_dbg.obj -debug -g -wi -de ... ``` Dub compile options in optimized: ``` dmd -m64 -c -of.dub\build\app_win_dmd_...\app_win_dmd_a64_rel.obj -inline -O -wi -de ... ``` template genericDecodeGrapheme(bool getValue) seems to sit in dmd2\src\phobos\std\uni\package.d and has a switch in it. What's going on here? I could imagine the following: 1) The optimizer does some lowering or similar and chooses a different code path not used in debug builds. 2) Something is different with name mangling in debug/optimized builds. Is this a known problem already? Didn't found something about it. Anyone with an idea how to cope with it? Currently I don't have a reduced test case for this and may not be able to create one shortly. Thanks
Re: KQueue and Fibers
On Friday, 9 April 2021 at 09:49:24 UTC, Arjan wrote: On Friday, 9 April 2021 at 09:00:17 UTC, rashir wrote: Goodmorning everyone, I'm trying to understand both Kqueue and Fiber's operation on Mac. Why don't I get the correct data as long as I read from the socket? It seems to be reading too early, but Kquue tells me that the socket is readable. ... yield for readibility kqueue waiting for readibilty resuming fiber as it's readable 131858 read bytesRead: -1readableAmount:131858 errno:35 35 == EAGAIN This informs the operation (recv) could not complete without blocking and should be retried. This does not mean the socket is not readable, but the operation would block (for whatever reason). Thank you, but I don't think I understand, it's not exactly KQueue's purpose to know when I can read in the socket without blocking myself? Why just before the recv reported that there are 131858 bytes, while in reality it is not yet possible to read from the socket? Thank you
Re: KQueue and Fibers
On Friday, 9 April 2021 at 09:00:17 UTC, rashir wrote: Goodmorning everyone, I'm trying to understand both Kqueue and Fiber's operation on Mac. Why don't I get the correct data as long as I read from the socket? It seems to be reading too early, but Kquue tells me that the socket is readable. ... yield for readibility kqueue waiting for readibilty resuming fiber as it's readable 131858 read bytesRead: -1readableAmount:131858 errno:35 35 == EAGAIN This informs the operation (recv) could not complete without blocking and should be retried. This does not mean the socket is not readable, but the operation would block (for whatever reason).
Re: Is there a more elegant way to do this in D?
On Thursday, 8 April 2021 at 22:27:38 UTC, Alain De Vos wrote: So which concrete types do you give for the two auto's. Like Paul said. But if you really wanted to type it out: a is int[], conv is ubyte[] and the map is lazy, so add .array and it evaluates to char[]
