Re: Undefined symbol: _dyld_enumerate_tlv_storage (OSX)
On Monday, 14 October 2019 at 18:49:04 UTC, Jacob Carlborg wrote: On 2019-10-14 07:36, Joel wrote: I use Home Brew (brew upgrade dmd, and brew upgrade dub) Brew is only up to 2.087.1 at the moment - John Colvin seems to be the man that mantains dmd with brew. You can use DVM [1] to install the latest version of DMD. [1] https://github.com/jacob-carlborg/dvm Thanks, but I’m not sure, since I’m using home for D, I’m not sure I won’t get complications. I guess it should be fine, I think I’ll just use TimeMachine and then try DVM.
Re: Reading parquet files from D
On Monday, 14 October 2019 at 19:27:04 UTC, Andre Pany wrote: [snip] I found this tool https://github.com/gtkd-developers/gir-to-d from Mike Wey which translates GObject GIR files to D headers. It might be interesting for some of this functionality to get included in dpp.
Re: A proper WAT moment
On Monday, 14 October 2019 at 17:00:56 UTC, John Colvin wrote:
Different ability to access a property depending if I'm inside
something else when I look?
[snip]
You're attempting to call one of S's member functions without an
instance of S to call it on. Reduced version:
struct S
{
int a;
int e() @property { return a; }
}
void foo(S s)
{
pragma(msg, __LINE__, " ", __traits(compiles, S.e)); // true
(???)
S.e; // Error: need `this` for `e` of type `@property int()`
}
struct C
{
void foo(S s)
{
pragma(msg, __LINE__, " ", __traits(compiles, S.e)); //
false
S.e; // Error: `this` for `e` needs to be type `S` not
type `C`
}
}
The real issue here is that the first `__traits(compiles)` check
succeeds, even though the actual expression fails.
Re: Reading parquet files from D
On Monday, 14 October 2019 at 09:39:11 UTC, Andre Pany wrote: Hi, did someone has some info or even an example of reading Parquet files from D? Parquet is part of Arrow (https://github.com/apache/arrow/). It has C and C++ headers. The C headers using GObject Introspection. Maybe that is the reason why they look little bit different than usual C headers? I am not sure whether it makes more sense using the C++ headers, because I am not sure whether D has already that compatibility level... Kind regards I found this tool https://github.com/gtkd-developers/gir-to-d from Mike Wey which translates GObject GIR files to D headers.
Re: Undefined symbol: _dyld_enumerate_tlv_storage (OSX)
On 2019-10-14 09:29, Robert M. Münch wrote: => nm /usr/lib/system/libdyld.dylib | grep _dyld_enumerate_tlv_storage 00017eca T _dyld_enumerate_tlv_storage Strange, the output shows that the symbol is present. -- /Jacob Carlborg
Re: Undefined symbol: _dyld_enumerate_tlv_storage (OSX)
On 2019-10-14 07:36, Joel wrote: I use Home Brew (brew upgrade dmd, and brew upgrade dub) Brew is only up to 2.087.1 at the moment - John Colvin seems to be the man that mantains dmd with brew. You can use DVM [1] to install the latest version of DMD. [1] https://github.com/jacob-carlborg/dvm -- /Jacob Carlborg
A proper WAT moment
Different ability to access a property depending if I'm inside
something else when I look?
struct S
{
int a;
static int b;
int c() { return a; }
static int d() { return 3; }
int e() @property { return a; }
static int f() @property { return 3; }
}
void foo(S s)
{
pragma(msg, __LINE__, " ", __traits(compiles,
__traits(getMember, s, "a")));
pragma(msg, __LINE__, " ", __traits(compiles,
__traits(getMember, S, "a")));
pragma(msg, __LINE__, " ", __traits(compiles,
__traits(getMember, s, "b")));
pragma(msg, __LINE__, " ", __traits(compiles,
__traits(getMember, S, "b")));
pragma(msg, __LINE__, " ", __traits(compiles,
__traits(getMember, s, "c")));
pragma(msg, __LINE__, " ", __traits(compiles,
__traits(getMember, S, "c")));
pragma(msg, __LINE__, " ", __traits(compiles,
__traits(getMember, s, "d")));
pragma(msg, __LINE__, " ", __traits(compiles,
__traits(getMember, S, "d")));
pragma(msg, __LINE__, " ", __traits(compiles,
__traits(getMember, s, "e")));
pragma(msg, __LINE__, " ", __traits(compiles,
__traits(getMember, S, "e")));
pragma(msg, __LINE__, " ", __traits(compiles,
__traits(getMember, s, "f")));
pragma(msg, __LINE__, " ", __traits(compiles,
__traits(getMember, S, "f")));
}
struct C(S)
{
void foo(S s)
{
pragma(msg, __LINE__, " ", __traits(compiles,
__traits(getMember, s, "a")));
pragma(msg, __LINE__, " ", __traits(compiles,
__traits(getMember, S, "a")));
pragma(msg, __LINE__, " ", __traits(compiles,
__traits(getMember, s, "b")));
pragma(msg, __LINE__, " ", __traits(compiles,
__traits(getMember, S, "b")));
pragma(msg, __LINE__, " ", __traits(compiles,
__traits(getMember, s, "c")));
pragma(msg, __LINE__, " ", __traits(compiles,
__traits(getMember, S, "c")));
pragma(msg, __LINE__, " ", __traits(compiles,
__traits(getMember, s, "d")));
pragma(msg, __LINE__, " ", __traits(compiles,
__traits(getMember, S, "d")));
pragma(msg, __LINE__, " ", __traits(compiles,
__traits(getMember, s, "e")));
// ALL True except for this one:
pragma(msg, __LINE__, " ", __traits(compiles,
__traits(getMember, S, "e")));
pragma(msg, __LINE__, " ", __traits(compiles,
__traits(getMember, s, "f")));
pragma(msg, __LINE__, " ", __traits(compiles,
__traits(getMember, S, "f")));
}
}
alias C0 = C!S;
Re: x64 ABI
On Monday, 14 October 2019 at 16:05:34 UTC, Stefan Koch wrote: On Monday, 14 October 2019 at 16:02:28 UTC, Marcel wrote: It appears that the ABI specification only describes the register convention for x86. Where can I find which registers get preserved across function calls for 64-bit targets? It's the same as c++. https://en.wikipedia.org/wiki/X86_calling_conventions#x86-64_calling_conventions Excellent, thank you!
Re: x64 ABI
On Monday, 14 October 2019 at 16:02:28 UTC, Marcel wrote: It appears that the ABI specification only describes the register convention for x86. Where can I find which registers get preserved across function calls for 64-bit targets? It's the same as c++. https://en.wikipedia.org/wiki/X86_calling_conventions#x86-64_calling_conventions
x64 ABI
It appears that the ABI specification only describes the register convention for x86. Where can I find which registers get preserved across function calls for 64-bit targets?
Re: Permission to Use Comments?
On Monday, 14 October 2019 at 11:14:50 UTC, Ron Tarrant wrote: Hi all, I've been thinking about how to take GtkDcoding to the next level and one idea is to use (favourable) comments made here on the forum to help promote the blog. So, since I'm not clear on copyright law and how it affects forum posts, I decided to ask... 1) Does anyone know how copyright laws stand regarding reuse of comments on a forum? 2) Does anyone object to me quoting them for promotional purposes? Pretty sure since this is a public forum, legally you just need to reference your sources (if even that). Asking permission is just polite. I don't say anything good, but you're free to use mine.
Permission to Use Comments?
Hi all, I've been thinking about how to take GtkDcoding to the next level and one idea is to use (favourable) comments made here on the forum to help promote the blog. So, since I'm not clear on copyright law and how it affects forum posts, I decided to ask... 1) Does anyone know how copyright laws stand regarding reuse of comments on a forum? 2) Does anyone object to me quoting them for promotional purposes?
Reading parquet files from D
Hi, did someone has some info or even an example of reading Parquet files from D? Parquet is part of Arrow (https://github.com/apache/arrow/). It has C and C++ headers. The C headers using GObject Introspection. Maybe that is the reason why they look little bit different than usual C headers? I am not sure whether it makes more sense using the C++ headers, because I am not sure whether D has already that compatibility level... Kind regards André
Re: Undefined symbol: _dyld_enumerate_tlv_storage (OSX)
On Monday, 14 October 2019 at 05:36:44 UTC, Joel wrote: On Friday, 11 October 2019 at 11:38:27 UTC, Jacob Carlborg wrote: [...] I get this since Catalina: Joel-Computer:VacSpace joelchristensen$ dub Failed to invoke the compiler dmd to determine the build platform: dyld: lazy symbol binding failed: Symbol not found: _dyld_enumerate_tlv_storage Referenced from: /usr/local/bin/dmd Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _dyld_enumerate_tlv_storage Referenced from: /usr/local/bin/dmd Expected in: /usr/lib/libSystem.B.dylib Joel-Computer:VacSpace joelchristensen$ I use Home Brew (brew upgrade dmd, and brew upgrade dub) Brew is only up to 2.087.1 at the moment - John Colvin seems to be the man that mantains dmd with brew. I confirm that DMD downloaded from the official script works like charms on Catilina. You can rely on that right now ...
Re: Undefined symbol: _dyld_enumerate_tlv_storage (OSX)
On 2019-10-11 18:09:01 +, Jacob Carlborg said: No, I don't think that's the problem. I have the same setup and I don't have this problem. Interesting... but the update seems to have solved the problem. Maybe some old DMD compiler stuff lying around got in the way. What result do you get if you run the following command: nm /usr/lib/system/libdyld.dylib | grep _dyld_enumerate_tlv_storage => nm /usr/lib/system/libdyld.dylib | grep _dyld_enumerate_tlv_storage 00017eca T _dyld_enumerate_tlv_storage -- Robert M. Münch http://www.saphirion.com smarter | better | faster
