Re: Is there an easy way to convert a C header to a D module?
On Monday, 15 March 2021 at 02:43:01 UTC, Tim wrote: On Monday, 15 March 2021 at 02:03:09 UTC, Adam D. Ruppe wrote: On Monday, 15 March 2021 at 01:53:31 UTC, Tim wrote: I'm needing to use a c/c++ library in a D program and I'm struggling with creating a binding as it seems like an enormous amount of regex modifications. Is there an existing program that can create most if not all of a binding for me? https://github.com/jacob-carlborg/dstep That does most of it, then you fix it up with some regex or whatever to finish the job. Seems pretty good. Does it work on c++ stuff too? (shameless plug) You can try my crappy generator[1] for C++ There is also dpp[2] which probably can convert C++ decls to D [1] https://github.com/Superbelko/ohmygentool [2] https://code.dlang.org/packages/dpp
Re: Is there an easy way to convert a C header to a D module?
On Monday, 15 March 2021 at 02:47:12 UTC, Adam D. Ruppe wrote: On Monday, 15 March 2021 at 02:43:01 UTC, Tim wrote: Seems pretty good. Does it work on c++ stuff too? I don't think so Bother. Well, I'm sure it will still be useful though. Thanks for the heads up
Re: Is there an easy way to convert a C header to a D module?
On Monday, 15 March 2021 at 02:43:01 UTC, Tim wrote: Seems pretty good. Does it work on c++ stuff too? I don't think so
Re: Is there an easy way to convert a C header to a D module?
On Monday, 15 March 2021 at 02:03:09 UTC, Adam D. Ruppe wrote: On Monday, 15 March 2021 at 01:53:31 UTC, Tim wrote: I'm needing to use a c/c++ library in a D program and I'm struggling with creating a binding as it seems like an enormous amount of regex modifications. Is there an existing program that can create most if not all of a binding for me? https://github.com/jacob-carlborg/dstep That does most of it, then you fix it up with some regex or whatever to finish the job. Seems pretty good. Does it work on c++ stuff too?
Re: Is there an easy way to convert a C header to a D module?
On Monday, 15 March 2021 at 01:53:31 UTC, Tim wrote: I'm needing to use a c/c++ library in a D program and I'm struggling with creating a binding as it seems like an enormous amount of regex modifications. Is there an existing program that can create most if not all of a binding for me? https://github.com/jacob-carlborg/dstep That does most of it, then you fix it up with some regex or whatever to finish the job.
Is there an easy way to convert a C header to a D module?
I'm needing to use a c/c++ library in a D program and I'm struggling with creating a binding as it seems like an enormous amount of regex modifications. Is there an existing program that can create most if not all of a binding for me? Thanks
How to open a compressed file in gz format ?
I want to read the content(file.gz) line by line,the following
code is not friendly to large files of hundreds of Gb, and the
memory overhead is also very large.
import std.stdio;
import std.process;
import std.string;
void main(string[] args){
string fileName = args[1];
string command = "gzip -dc " ~ fileName ;
auto dmd = executeShell(command);
if(dmd.status != 0){
writeln("Compilation failed:\n", dmd.output);
}
else{
auto all=chomp(dmd.output).split("\n");
writeln(typeid(all));
for(int i=0; i
Re: Forbidden file names?
On Sunday, 14 March 2021 at 20:57:39 UTC, Paul Backus wrote: This is the error you get when you try to call a function that has the same name as the current module. The best way to fix it is to rename the module, but if you can't, you can use an alias to disambiguate: alias sort = std.algorithm.sort; Thanks.
Re: Forbidden file names?
On Sunday, 14 March 2021 at 20:47:00 UTC, Brian wrote: Hello -- Apologies if this is answered somewhere in the documentation. I was trying out the sample code on the dlang.org home page. When I got to the "Sort an Array at Compile-Time" example, I saved it on my machine as sort.d. When I tried to build sort.d, the compile failed. But when I renamed sort.d to anything else (e.g., array.d), the compilation was fine. [...] /home/brian/d $ dmd sort.d sort.d(9): Error: function expected before `()`, not `module sort` of type `void` This is the error you get when you try to call a function that has the same name as the current module. The best way to fix it is to rename the module, but if you can't, you can use an alias to disambiguate: alias sort = std.algorithm.sort;
Forbidden file names?
Hello --
Apologies if this is answered somewhere in the documentation.
I was trying out the sample code on the dlang.org home page.
When I got to the "Sort an Array at Compile-Time" example, I
saved it on my machine as sort.d. When I tried to build sort.d,
the compile failed. But when I renamed sort.d to anything else
(e.g., array.d), the compilation was fine.
I am wondering if this is expected.
Thanks! Terminal output below explaining the above.
~Brian
/home/brian/d $ cat sort.d
void main()
{
import std.algorithm, std.conv, std.stdio;
"Starting program".writeln;
// Sort a constant declaration at Compile-Time
enum a = [ 3, 1, 2, 4, 0 ];
static immutable b = sort(a);
// Print the result _during_ compilation
pragma(msg, text("Finished compilation: ", b));
}
/home/brian/d $ dmd sort.d
sort.d(9): Error: function expected before `()`, not `module
sort` of type `void`
sort.d(12):while evaluating `pragma(msg, text(T...)(T
args) if (T.length > 0)("Finished compilation: ", b))`
/home/brian/d $ mv sort.d array.d
/home/brian/d $ dmd array.d
Finished compilation: immutable(SortedRange!(int[], "a < b",
SortedRangeOptions.assumeSorted))([0, 1, 2, 3, 4])
Re: Workaround to "import" an exception from a DLL
On Sunday, 14 March 2021 at 15:45:19 UTC, Imperatorn wrote: On Sunday, 14 March 2021 at 09:35:40 UTC, frame wrote: In the past I've used a two patterns which are kinda wierd but. Basically the first is returning a tuple w value and exception and just check it, kinda like Go. The second approach is to have a function u can call to get the latest ex, kinda like GetLastError win api I think that is like my pattern actually. I can call a method for the latest exception. But to throw it I need to create a new instance and copy the data. I would like to have a proxy that can copy the data into a new instance without manually checking for the type via string comparison. I don't care for the call trace, this data is collected and saved as string before the DLL function returns. The idea is to scan the TypeInfo memory area of the exception and replace it with the one that is valid for current context so the object can be recognized later and set the call stack reference or whatever the crash causes to null. Alternatively a new instance should be created and data just copied automatically.
Re: Workaround to "import" an exception from a DLL
On Sunday, 14 March 2021 at 12:27:17 UTC, evilrat wrote: On Sunday, 14 March 2021 at 09:35:40 UTC, frame wrote: As a workaround maybe you could introduce special DLLWrapperException with reference to original exception using cast hack? This is unsatisfying. I want to switch-catch the exceptions also via their types.
Re: Why are enums with base type string not considered strings?
On Sunday, 14 March 2021 at 16:09:39 UTC, Imperatorn wrote:
On Sunday, 14 March 2021 at 10:42:17 UTC, wolframw wrote:
enum BoolEnum : bool { TestBool = false }
enum CharEnum : char { TestChar = 'A' }
enum StringEnum : string { TestString = "Hello" }
pragma(msg, isBoolean!BoolEnum); // true
pragma(msg, isSomeChar!CharEnum); // true
pragma(msg, isSomeString!StringEnum); // false
Why does isSomeString not return true for an enum with base
type string
May be a regression?
https://issues.dlang.org/show_bug.cgi?id=16573
Indeed: https://run.dlang.io/is/liSDBZ
It regressed in 2.079.1. Seems to be worth an issue report.
—Bastiaan.
Re: Why are enums with base type string not considered strings?
On Sunday, 14 March 2021 at 10:42:17 UTC, wolframw wrote:
enum BoolEnum : bool { TestBool = false }
enum CharEnum : char { TestChar = 'A' }
enum StringEnum : string { TestString = "Hello" }
pragma(msg, isBoolean!BoolEnum); // true
pragma(msg, isSomeChar!CharEnum); // true
pragma(msg, isSomeString!StringEnum); // false
Why does isSomeString not return true for an enum with base
type string while
other isX functions return true for enums with an according
base type X?
Regarding whether enums should be considered by these
functions, I can see the
case being made one of both ways (personally, I'd say they
should), but in the
example above it seems that different rules are applied.
May be a regression?
https://issues.dlang.org/show_bug.cgi?id=16573
Re: Workaround to "import" an exception from a DLL
On Sunday, 14 March 2021 at 09:35:40 UTC, frame wrote: I know I cannot throw exceptions from a DLL, it will crash. So I currently use a wrapper that collects exceptions and pick it up if the wrapper method returns a failure state. As I know what type of exception will be thrown, I can copy all important data to a new exception object and then throwing it in the current context. However, I wonder if there is way to copy the exception data via Throwable interface direct because checking for types via typeid() and string comparsion is just meh. It is possible to fetch the exception data: // Throwable e; // this returns null in the program (but works in a debugger watch): MyExceptionObj imported = cast(MyExceptionObj)e; // this actually works: MyExceptionObj imported = cast(MyExceptionObj) cast(void*)e; But for some reason throwing this object directly would crash. Is there are way to copy the exception data in a new Throwable instance that can be thrown from the current context? Or can the runtime be tricked by overwriting the TypeInfo in memory? (I don't know exactly what the actual problem is.) In the past I've used a two patterns which are kinda wierd but. Basically the first is returning a tuple w value and exception and just check it, kinda like Go. The second approach is to have a function u can call to get the latest ex, kinda like GetLastError win api
Re: Workaround to "import" an exception from a DLL
On Sunday, 14 March 2021 at 12:27:17 UTC, evilrat wrote: The problem is that TypeInfo is not shared on Windows, which is actually roots deeper in the other problems with "sharing". Unfortunately I cannot provide you with details, but this situation is well known long standing issue. It isn't just the typeinfo too, the catch tables are also not merged. https://github.com/dlang/druntime/pull/2874 I wrote that like infinity years ago and it hacks some of the problems but like the typeinfo string compare is not generally correct and idk how to solve that part without hacking the compiler too.
Re: How do I load dylib (i.e. phobos and druntime for ldc) in Macos sandboxed app?
On Sunday, 14 March 2021 at 11:40:25 UTC, David wrote: This is more a macos thing than a D thing but still relevant. In another thread I was asking about cleaning up a D dylib for using in Excel. Ldc was suggested though first I have to figure out how to make the phobos and druntime loadable from within the sandbox. (I've posted in a new topic as it was drift from the original question - hope that helps anyone else searching for the same answers). I'm not expecting many relies - unless someone has happened to have solved it. Will post links once I've figured a solution. Solved using install_name_tool and https://medium.com/@donblas/fun-with-rpath-otool-and-install-name-tool-e3e41ae86172
Re: Workaround to "import" an exception from a DLL
On Sunday, 14 March 2021 at 09:35:40 UTC, frame wrote: // this returns null in the program (but works in a debugger watch): MyExceptionObj imported = cast(MyExceptionObj)e; // this actually works: MyExceptionObj imported = cast(MyExceptionObj) cast(void*)e; Is there are way to copy the exception data in a new Throwable instance that can be thrown from the current context? Or can the runtime be tricked by overwriting the TypeInfo in memory? (I don't know exactly what the actual problem is.) As a workaround maybe you could introduce special DLLWrapperException with reference to original exception using cast hack? The problem is that TypeInfo is not shared on Windows, which is actually roots deeper in the other problems with "sharing". Unfortunately I cannot provide you with details, but this situation is well known long standing issue. From what I understand it is such a mess because D compiler/linker doesn't merge multiple symbols in running program which is how it basically works in C++ where DLL's works "as expected".
How do I load dylib (i.e. phobos and druntime for ldc) in Macos sandboxed app?
This is more a macos thing than a D thing but still relevant. In another thread I was asking about cleaning up a D dylib for using in Excel. Ldc was suggested though first I have to figure out how to make the phobos and druntime loadable from within the sandbox. (I've posted in a new topic as it was drift from the original question - hope that helps anyone else searching for the same answers). I'm not expecting many relies - unless someone has happened to have solved it. Will post links once I've figured a solution.
Re: Is it possible to suppress standard lib and dlang symbols in dylib (macos)
On Sunday, 14 March 2021 at 01:38:23 UTC, David Skluzacek wrote: On Thursday, 11 March 2021 at 22:10:04 UTC, David wrote: I wasn't aware that object files could be manipulated like the strip manual page - thx for the heads up. With the caveats that the linked post is almost 14 years old, I can't try this command myself, and the ldc solution is probably preferable if you can get it to work - if you want to compile with dmd and use the strip command, this might help you (the OP answered his own question at the bottom): https://forum.juce.com/t/how-to-build-dylib-exporting-only-wanted-symbols/2180 He suggests doing: strip -u -r -s FILE_CONTAINING_EXPORTS_LIST MY_DYLIB.dylib It looks straight forward that way - thx
Re: Is it possible to suppress standard lib and dlang symbols in dylib (macos)
On Sunday, 14 March 2021 at 00:00:59 UTC, Adam D. Ruppe wrote: On Saturday, 13 March 2021 at 23:41:28 UTC, David wrote: So Excel complains that it can't load my library - presumably because libphobos2 and libdruntime are not in the sandbox.ly You *might* be able to compile with --link-defaultlib-shared=false to use the static phobos+druntime... but with shared libs it prefers shared and might not allow this. Probably worth a try. Otherwise I'd try to just add the phobos so to your sandbox somehow. or the rpath set to current directory and putting them in your correct directory may also work. I don't know how that works on Mac but on Linux it is passing... `-L-rpath -L.` or something like that when compiling... I can't find my notes on this but something like that. I think figuring out how to add phobos to the sandbox is probably the best option as I'm sure it won't be the last dylib I need to load. Anyone else done this? Pointers welcome.
Why are enums with base type string not considered strings?
enum BoolEnum : bool { TestBool = false }
enum CharEnum : char { TestChar = 'A' }
enum StringEnum : string { TestString = "Hello" }
pragma(msg, isBoolean!BoolEnum); // true
pragma(msg, isSomeChar!CharEnum); // true
pragma(msg, isSomeString!StringEnum); // false
Why does isSomeString not return true for an enum with base type
string while
other isX functions return true for enums with an according base
type X?
Regarding whether enums should be considered by these functions,
I can see the
case being made one of both ways (personally, I'd say they
should), but in the
example above it seems that different rules are applied.
Workaround to "import" an exception from a DLL
I know I cannot throw exceptions from a DLL, it will crash. So I currently use a wrapper that collects exceptions and pick it up if the wrapper method returns a failure state. As I know what type of exception will be thrown, I can copy all important data to a new exception object and then throwing it in the current context. However, I wonder if there is way to copy the exception data via Throwable interface direct because checking for types via typeid() and string comparsion is just meh. It is possible to fetch the exception data: // Throwable e; // this returns null in the program (but works in a debugger watch): MyExceptionObj imported = cast(MyExceptionObj)e; // this actually works: MyExceptionObj imported = cast(MyExceptionObj) cast(void*)e; But for some reason throwing this object directly would crash. Is there are way to copy the exception data in a new Throwable instance that can be thrown from the current context? Or can the runtime be tricked by overwriting the TypeInfo in memory? (I don't know exactly what the actual problem is.)
