Re: OSX DStep / Standard Includes
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 Apple. The one provided by Apple might be built/configured differently. If you're on macOS Mojave you need to run this command as well: sudo installer -pkg /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg -target / -- /Jacob Carlborg
Re: OSX DStep / Standard Includes
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 Thread model: posix InstalledDir: ignoring nonexistent directory "/usr/include" #include "..." search starts here: #include <...> search starts here: /opt/local/libexec/llvm-5.0/include/c++/v1 /8542414 /usr/local/include /opt/local/libexec/llvm-5.0/lib/clang/5.0.2/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. /opt/local/libexec/llvm-5.0/include/c++/v1/string.h:61:15: fatal error: 'string.h' file not found So I'm wondering what this "'string.h' file not found" means as the file seems to be found... any ideas? 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 -- /Jacob Carlborg
Re: Logging best practices
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 alternatives? I also use it for all of my applications. But I really miss a RotatedTimeFileLogger. One big log file which will grow and grow is not that usuable in cloud environment. Also I haven't found out wheter it is safe / how to write from different threads to the same log file. Kind regards Andre
Re: Does D have a tool like pySnooper?
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: "PySnooper is a poor-man's debugger". I don't think it is possible to do what PySnooper does at runtime without significantly changing the code you write to accomodate it, D and Python are just structured too differently. However I see no advantage in having something like PySnooper either because D has real debuggers. Using gdb you can do everything that pysnooper does, dynamically and with the corresponding lines of code. You also get much much more such as memory inspection, memory modification, disassembly or the magical ability to rewind time from a crash. PySnooper is nice for python, but I fail to see any advantage over a real debugger in D.
Re: OSX DStep / Standard Includes
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 support would be great. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: gtkDcoding Blog: Post #0030 - A More Practical RadioMenuItem Example
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 blog post and github code but there is no link to the github code for this one. It's probably this one: https://github.com/rontarrant/gtkDcoding/blob/master/012_menus/menu_012_12_observed_radiomenuitems.d
Packages / imports & references between modules
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 doesn't seem to be the case. Or am I missing something? -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: Packages / imports & references between modules
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.
Re: Packages / imports & references between modules
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; the other
modules importing it can access them too.
I thought that public only applies to the upward chain, not to the same level.
However, using public doens't help as there are still some undefined
identifiers between modules on the same level. I think I need to
elaborate on my case a bit more:
I use DStep to convert some C library headers. And these use forward
references to structs.
A/a.d
module A.a;
struct myStruct;
A/b.d
module A.b;
struct myStruct {...}
A/c.d
module A.c;
struct myOtherStruct {
myStruct ms;
}
A/package.d
import A.a;
import A.b;
import A.c;
I get an "undefined identifier" error in A/c.d for myStruct. Changing A/c.d to:
A/c.d
module A.c;
import A.b;
struct myOtherStruct {
myStruct ms;
}
works. But this would end up in adding a lot of imports to avoid the
"undefined identifier" problem to many files manually and somehow break
the DStep workflow.
So, is there a way to avoid this? With public import it doesn't seem to work.
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: Packages / imports & references between modules
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 I see what you are doing now...
A/c.d
module A.c;
struct myOtherStruct {
myStruct ms;
}
This will never work in D. The module needs to work by itself. It
can see public imports from another module it itself imports:
module A.c;
import A; // thanks to this, it can see a `public import A.a;`
from the A package..
But without that explicit import, it cannot see anything outside
itself.
You might be able to get away with listing the `public import`s
in package.d, and then just `import A;` in each individual module
though.
But it won't just inherit stuff from other modules, like C's
#include does. A D module is parsed independently of other
modules.
works. But this would end up in adding a lot of imports to
avoid the "undefined identifier" problem to many files manually
and somehow break the DStep workflow.
maybe dstep could automatically add imports to generated files
too.
Re: gtkDcoding Blog: Post #0030 - A More Practical RadioMenuItem Example
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: https://github.com/rontarrant/gtkDcoding/blob/master/012_menus/menu_012_12_observed_radiomenuitems.d Yup, and oops! I didn't even include a broken link. Fixed now and thanks, number.
Memory management by interfacing C/C++
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 example:
```
//declaration in d
struct IntVector {
int* val;
int length;
}
// in cpp
typedef struct IntVector {
int* val;
int length;
} IntVector;
// cpp function returning a struct containing an array pointer
allocated with "new" op.
IntVector Subdiv2D_GetLeadingEdgeList(Subdiv2D sd){
std::vector iv;
sd->getLeadingEdgeList(iv);
int *cintv = new int[iv.size()]; // I don't call delete
anywhere?
for(size_t i=0; i < iv.size(); i++){
cintv[i] = iv[i];
}
IntVector ret = {cintv, (int)iv.size()};
return ret;
};
// call extern c function in d:
extern (C) IntVector Subdiv2D_GetLeadingEdgeList(Subdiv2d sd);
int[] getLeadingEdgeList(){
IntVector intv = Subdiv2D_GetLeadingEdgeList(this);
int[] ret = intv.val[0..intv.length]; // just D magic. Still
no delete anywhere!
return ret;
}
```
The question is now: what will happen to "int *cintv" which is
allocated with new operator in cpp code? I have many code similar
in the project, but I have not encounter any problem so far even
in looped video processings. Is GC of D doing deallocation
automagically?
https://github.com/aferust/opencvd
Re: Memory management by interfacing C/C++
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 facing crashes so far. Is GC of D handling things for me? Here is an example: [...] The question is now: what will happen to "int *cintv" which is allocated with new operator in cpp code? I have many code similar in the project, but I have not encounter any problem so far even in looped video processings. Is GC of D doing deallocation automagically? https://github.com/aferust/opencvd D's GC only collects memory allocated with D's `new` operator. Memory allocated by C++'s `new` operator must be freed by C++'s `delete` operator.
