On Saturday, 27 April 2019 at 13:23:55 UTC, number wrote:
There are links to the previous blog post and github code but
there is no link to the github code for this one. It's probably
this one:
Hi,
I am wrapping some C++ code for my personal project (opencvd),
and I am creating so many array pointers at cpp side and
containing them in structs. I want to learn if I am leaking
memory like crazy, although I am not facing crashes so far. Is GC
of D handling things for me? Here is an
On Saturday, 27 April 2019 at 16:24:40 UTC, Robert M. Münch wrote:
I thought that public only applies to the upward chain, not to
the same level.
There is no "same level" really (except for the `package`
protection level); it is just inside the module or outside the
module for imports.
But
On Saturday, 27 April 2019 at 22:25:58 UTC, Ferhat Kurtulmuş
wrote:
Hi,
I am wrapping some C++ code for my personal project (opencvd),
and I am creating so many array pointers at cpp side and
containing them in structs. I want to learn if I am leaking
memory like crazy, although I am not
On Monday, 22 April 2019 at 16:24:53 UTC, Taylor Hillegeist wrote:
Saw this tool and thought D could probably do something like
this pretty easily. Is there such a tool out there already?
https://github.com/cool-RR/pysnooper
Or would this not be easy at all with D?
First line of that link:
On Friday, 26 April 2019 at 11:14:23 UTC, Ron Tarrant wrote:
Once again it's Friday and a new blog post is up. And just a
room at the Hotel California (any time of year) you can find it
here:
http://gtkdcoding.com/2019/04/26/0030-radiomenuitem-practical.html
There are links to the previous
A/a.d has module A.a;
A/b.d has module A.b;
A/package.d
import A.a;
import A.b;
A.b needs to access something from A.a
I assumed if I do
import package.d
that A.b sees the content of A.a now and doens't need an explicit line with
a/b.d
import A.a;
But this
On 2019-04-27 15:06:01 +, Adam D. Ruppe said:
On Saturday, 27 April 2019 at 14:58:01 UTC, Robert M. Münch wrote:
import A.a;
`import` by itself is a private import, meaning it cannot be seen from
outside the module.
Make it `public import` and it can be seen from the outside;
On Thursday, 25 April 2019 at 10:33:00 UTC, Vladimirs Nordholm
wrote:
Hello.
Is there a current "Best Practices" for logging in D?
For the actual logging, I know of `std.experimental.logger`.
However, the `experimental` has kept me away from it.
Is it good, or are there any better
On Saturday, 27 April 2019 at 14:58:01 UTC, Robert M. Münch wrote:
import A.a;
`import` by itself is a private import, meaning it cannot be seen
from outside the module.
Make it `public import` and it can be seen from the outside; the
other modules importing it can access them too.
On 2019-04-26 23:16, Jacob Carlborg wrote:
You need to install the Xcode command line tools, by running
"xcode-select --install". This will create the "/usr/include" directory.
I'm guessing this is because DStep is linked against the open source
version of Clang and not the one provided by
On 2019-04-26 17:14, Robert M. Münch wrote:
I'm trying the new DStep version but have some problems with standard
include files:
=> dstep --output ./d -v -I/opt/local/libexec/llvm-5.0/include/c++/v1
myinclude.h
clang version 5.0.2 (tags/RELEASE_502/final)
Target: x86_64-apple-darwin18.5.0
On 2019-04-27 09:40:46 +, Jacob Carlborg said:
I created an enhancement request for this. Hopefully it's possible to
fix without having the user installing the SDK in /usr/include.
https://github.com/jacob-carlborg/dstep/issues/227
Thanks! Your tip worked and yes, OSX out of the box
13 matches
Mail list logo
