Re: How to delete dynamic array ?
On Thursday, 18 March 2021 at 21:21:37 UTC, Paul Backus wrote: The source code is here: https://github.com/p0nce/d-idioms/ Thanks for the answer. But it's more complex than I thought. Something like Latex was in my mind.
Re: How to delete dynamic array ?
On Thursday, 18 March 2021 at 18:48:26 UTC, Vinod K Chandran wrote: On Wednesday, 17 March 2021 at 14:30:26 UTC, Guillaume Piolat wrote: I made this article to clear up that point: https://p0nce.github.io/d-idioms/#Slices-.capacity,-the-mysterious-property Sorry for this off-topic question. I am amazed with eye catchy look of that d-idioms page. I want to create a page like it for my ongoing project. I think it's a good form of documentation. How do i create one like it ? The source code is here: https://github.com/p0nce/d-idioms/
Re: How to delete dynamic array ?
On Wednesday, 17 March 2021 at 14:30:26 UTC, Guillaume Piolat wrote: I made this article to clear up that point: https://p0nce.github.io/d-idioms/#Slices-.capacity,-the-mysterious-property Sorry for this off-topic question. I am amazed with eye catchy look of that d-idioms page. I want to create a page like it for my ongoing project. I think it's a good form of documentation. How do i create one like it ?
Re: How to delete dynamic array ?
On Wednesday, 17 March 2021 at 16:20:06 UTC, Steven Schveighoffer wrote: It's important to understand that [] is just a practical syntax for a fat pointer. Thinking of [] just as a fancy pointer helps imho to clarify that the pointed to memory nature is independant of the pointer itself.
Re: question about ref keyword
On Thursday, 18 March 2021 at 16:59:24 UTC, Jack wrote:
let's assume this class:
class C
{
private S m_s;
this()
{
m_s = S(30);
}
ref S value() { return m_s; }
ref S value(ref S s)
{
return m_s = s;
}
}
and I do something like this:
auto s1 = S(40);
auto c = new C();
c.value = s1;
s1.n = 80;
give that value has ref in its signature, the s1 is passed as a
"pointer" right?
right
also, when I do: m_s = s; m_s is a copy of s1 or a reference to
it?
a copy
setting s1.n to 80 in the next line doesn't seem to change
c.value so it seems it passed s1 as a pointer but when it comes
to assignment a copy was made?
You got it.
If you want the pointer, you can get it taking the address of s:
`S* p = `.
question about ref keyword
let's assume this class:
class C
{
private S m_s;
this()
{
m_s = S(30);
}
ref S value() { return m_s; }
ref S value(ref S s)
{
return m_s = s;
}
}
and I do something like this:
auto s1 = S(40);
auto c = new C();
c.value = s1;
s1.n = 80;
give that value has ref in its signature, the s1 is passed as a
"pointer" right? also, when I do: m_s = s; m_s is a copy of s1 or
a reference to it? setting s1.n to 80 in the next line doesn't
seem to change c.value so it seems it passed s1 as a pointer but
when it comes to assignment a copy was made?
Re: noobie question, dub or meson?
On Thursday, 18 March 2021 at 02:28:56 UTC, Chris Piker wrote: Hi D I've started a D layer for one of my C libraries that's adds some new functionality and a bit of an interface upgrade. In turn I'm using this combined code-base as a dependency for D "scripts". Since my software is used by a few outside groups in my field, it seems I should get used to packaging D modules, even if those packages never make it to the central dub repo. Given that source code for the combined library is some D but mostly C, would you recommend that I: 1) Keep the D sources and C sources in separate projects? 2) Use meson to create a combined package? 3) Use dub to create a combined package? 4) Some other option? The D code is useless without it's C core, so a dub package that just includes the D parts would be disappointing. The library's not huge, only about 25K lines, but I don't think I have time for a straight conversion of the whole thing to D at this point. Thanks for your opinions on the matter, The D support from meson is not perfect, but for your use case I'd go for it, esp. if you have do not have many dependencies on dub packages. One problem with meson is that it goes the separate compilation route by default. I recommend just to -I your dependencies and build with -i, to avoid the hit in your compile times.
Re: rawRead from Pipe segfaults
On Wednesday, 17 March 2021 at 23:08:07 UTC, kdevel wrote: [...] How do I keep the pipe open? Having the readEnd and writeEnd closed in the parent is usually the right thing to to. spawnProcess closes the ends which is documented: | Note that if you pass a File object that is not one of the standard | input/output/error streams of the parent process, that stream will | by default be closed in the parent process when this function returns. | See the Config documentation below for information about how to disable | this behaviour. [1] [1] https://dlang.org/phobos/std_process.html#spawnProcess
Re: rawRead from Pipe segfaults
On Thursday, 18 March 2021 at 07:55:01 UTC, Imperatorn wrote:
[...]
Have you tried "scope(exit) wait(" instead?
Yes. Does not make a difference. For the segfault I have filed
Issue 21728
Re: rawRead from Pipe segfaults
On Wednesday, 17 March 2021 at 23:08:07 UTC, kdevel wrote:
In order to watch out for lost bytes in a pipe I encountered
this segfault.
It seems that the readEnd is already closed when rawRead =
fread is
called (uncomment the eof line).
[...]
Have you tried "scope(exit) wait(" instead?
Re: noobie question, dub or meson?
Meson doesn't track dependencies properly for d, so your dirty builds will be wrong if you go that route. You might consider keeping the c and d code in the same repository, but with separate build systems; using dub to build the d code and and whatever tool you prefer for c. Or try reggae.
