Re: GDC options
On Monday, 5 June 2017 at 18:22:31 UTC, Sebastien Alaiwan wrote: On Wednesday, 22 March 2017 at 13:42:21 UTC, Matthias Klumpp wrote: This is why most of my work in Meson to get D supported is adding weird hacks to translate compiler flags between GNU <-> non-GNU <-> DMD. It sucks quite badly, and every now and then I hit a weird corner case where things break. For example: https://github.com/mesonbuild/meson/commit/d9cabe9f0ca6fb06808c1d5cf5206a7c5158517e One day, we'll have to decide if we should align build systems on compilers, or the other way around. In the meantime, could everyone please align on clang and gcc ? :-) We're getting there, slowly. Although its a tight balance between dmd compatibility and gcc/clang compatibility, see -[f]unittest. https://github.com/ldc-developers/ldc/pull/2149
Re: Can assumeSafeAppend() grab more and more capacity?
On 06/05/2017 03:16 PM, ag0aep6g wrote:
> The spec says [1]: "one may use the .capacity property to determine how
> many elements can be appended to the array without reallocating." So the
> space indicated by `.capacity` is reserved for the array.
Cool. Thanks!
>> 3) Bonus: Shouldn't the array specialization of std.algorithm.remove
>> call assumeSafeAppend if the array has capacity to begin with? (The
>> equivalent of following code?)
>>
>> const oldCap = arr.capacity;
>> // ... do std.algorithm.remove magic on arr ...
>> if (oldCap) {
>> arr.assumeSafeAppend();
>> }
>>
>> I'm aware that there can be multiple slices with non-zero capacity
>> until one of them grabs the capacity for itself but it's ok for
>> remove() to give the capacity to just one of them.
>
> Seems safe, but you'll have to justify claiming the capacity like that.
My justification was that it feels to be a bug anyway to have multiple
slices to data where one is about to remove() elements from (hence
jumbling the others' elements). My thinking was, if capacity were not
guaranteed for any slice to begin with, then why not pull it under some
slices arbitrarily. But I agree with you that remove() should still not
decide on its own.
However, I've noticed an inconsistency when writing the previous
paragraph: If capacity is guaranteed reserved space, multiple slices
start their lives with a lie! :) From my earlier program:
auto a = [ 1, 2, 3, 4 ];
auto b = a;
Both of those slices have non-zero capacity yet one of them will be the
lucky one to grab it. Such semantic issues make me unhappy. :-/
Ali
Re: Can assumeSafeAppend() grab more and more capacity?
On 06/05/2017 11:08 PM, Ali Çehreli wrote:
Imagine an array that wants to reuse its buffer after removing elements
from it. For example, a PID waiting list can remove completed elements
and add new ones at the end.
The code would call assumeSafeAppend like this:
arr = arr.remove!(e => e % 2);
arr.assumeSafeAppend();
1) Assuming that the array is not relocated, is it possible that the
capacity will grow and grow? (Imagine that a new memory page from the GC
beyond the current capacity becomes available? Would assumeSafeAppend()
grab that as capacity as well?)
As far as I understand, assumeSafeAppend only grabs the existing
capacity. New capacity gets created when appending or by calling `reserve`.
When there's free space beyond the capacity, then appending/`reserve`
may extend the memory block instead of relocating. A quick test says
this is done with large arrays (multiple KiB). For smaller arrays, the
GC likely uses pools of fixed-width chunks.
For example, if capacity was non-zero before the two lines above, would
that assumeSafeAppend() call find more capacity than before?
I don't think so.
2) If so, is the capacity "allocated" for this buffer or can the GC use
those pages for other purposes, effectively reducing the array's capacity?
The spec says [1]: "one may use the .capacity property to determine how
many elements can be appended to the array without reallocating." So the
space indicated by `.capacity` is reserved for the array.
But I guess you should claim it by appending, so that the GC is knows
what's happening. I.e., don't claim it by slicing a pointer.
In other words, is having capacity a guarantee like having called
reserve()?
As far as I know, it's exactly the same. `reserve` makes capacity.
3) Bonus: Shouldn't the array specialization of std.algorithm.remove
call assumeSafeAppend if the array has capacity to begin with? (The
equivalent of following code?)
const oldCap = arr.capacity;
// ... do std.algorithm.remove magic on arr ...
if (oldCap) {
arr.assumeSafeAppend();
}
I'm aware that there can be multiple slices with non-zero capacity until
one of them grabs the capacity for itself but it's ok for remove() to
give the capacity to just one of them.
Seems safe, but you'll have to justify claiming the capacity like that.
How is it better than leaving it for the other slices? As it is, a user
can do what you did there when they want the capacity. When `remove`
claims the capacity eagerly, unrelated code may end up relocating
without need.
[1] http://dlang.org/spec/arrays.html#resize
Can assumeSafeAppend() grab more and more capacity?
Imagine an array that wants to reuse its buffer after removing elements
from it. For example, a PID waiting list can remove completed elements
and add new ones at the end.
The code would call assumeSafeAppend like this:
arr = arr.remove!(e => e % 2);
arr.assumeSafeAppend();
1) Assuming that the array is not relocated, is it possible that the
capacity will grow and grow? (Imagine that a new memory page from the GC
beyond the current capacity becomes available? Would assumeSafeAppend()
grab that as capacity as well?)
For example, if capacity was non-zero before the two lines above, would
that assumeSafeAppend() call find more capacity than before?
2) If so, is the capacity "allocated" for this buffer or can the GC use
those pages for other purposes, effectively reducing the array's capacity?
In other words, is having capacity a guarantee like having called reserve()?
3) Bonus: Shouldn't the array specialization of std.algorithm.remove
call assumeSafeAppend if the array has capacity to begin with? (The
equivalent of following code?)
const oldCap = arr.capacity;
// ... do std.algorithm.remove magic on arr ...
if (oldCap) {
arr.assumeSafeAppend();
}
I'm aware that there can be multiple slices with non-zero capacity until
one of them grabs the capacity for itself but it's ok for remove() to
give the capacity to just one of them.
Here is a test program that plays with this idea, starting with two
identical slices with same capacity:
import std.stdio;
import std.array;
import std.algorithm;
void myRemove(ref int[] arr) {
const cap = arr.capacity;
arr = arr.remove!(e => e % 2);
if (cap) {
arr.assumeSafeAppend();
}
}
void info(arrays...)(string title) {
writefln("\n%s", title);
foreach (i, arr; arrays) {
writefln(" %s - ptr: %s, len: %s, cap: %s",
(arrays[i]).stringof, arr.ptr, arr.length, arr.capacity);
}
}
void main() {
auto a = [ 1, 2, 3, 4 ];
auto b = a;
info!(a, b)("before myRemove(a)");
myRemove(a);
info!(a, b)("after myRemove(a)");
myRemove(b);
info!(a, b)("after myRemove(b)");
}
before myRemove(a)
a - ptr: 7F15F40D4060, len: 4, cap: 7
b - ptr: 7F15F40D4060, len: 4, cap: 7
after myRemove(a)
a - ptr: 7F15F40D4060, len: 2, cap: 7 <== 'a' grabbed capacity
b - ptr: 7F15F40D4060, len: 4, cap: 0 <==
after myRemove(b)
a - ptr: 7F15F40D4060, len: 2, cap: 7
b - ptr: 7F15F40D4060, len: 3, cap: 0
Ali
Re: GDC options
On Wednesday, 22 March 2017 at 13:42:21 UTC, Matthias Klumpp wrote: This is why most of my work in Meson to get D supported is adding weird hacks to translate compiler flags between GNU <-> non-GNU <-> DMD. It sucks quite badly, and every now and then I hit a weird corner case where things break. For example: https://github.com/mesonbuild/meson/commit/d9cabe9f0ca6fb06808c1d5cf5206a7c5158517e One day, we'll have to decide if we should align build systems on compilers, or the other way around. In the meantime, could everyone please align on clang and gcc ? :-)
Re: Avast virus warning?
On Monday, 5 June 2017 at 16:40:25 UTC, rikki cattermole wrote: It would be nice to get in touch with their engineers to find out what is really going on. Tried an email and hit a paywall. :c "We’re sorry, but we can’t seem to find a record of your license in our system."
Re: D and GDB
On Mon, Jun 05, 2017 at 05:34:14AM +, Basile B. via Digitalmars-d-learn wrote: > On Monday, 5 June 2017 at 01:07:51 UTC, H. S. Teoh wrote: > > > > It can't be any more trivial than just running ddemangle, which is > > found in the dlang/tools repo on github. [...] > > (Arguably this should be shipped by default with dmd... or is it > > already?) > > Of course it is. Currently i don't use it much but at the beginning of > 2017 it's been very useful to me, to process valgrind's output, dozen > and dozen of times. How can anyone ignore that it's shipped with dmd ? 'cos I run dmd off git HEAD, so I've no idea what it ships with/without. :-D T -- My program has no bugs! Only undocumented features...
Re: Avast virus warning?
On 05/06/2017 5:31 PM, Anonymouse wrote: I just sent a pre-compiled .exe of my project to a friend, and his Avast anti-virus promptly quarantined it and sent it off for analysis. I tried sending him a Hello World[1] with the same results. Is this something common for d programs? Anything I can do to work around it from my end? [1]: http://www.mediafire.com/file/fc51qz141r3ns6r/helloworld.exe Yeah Avast is fairly hit happy for D programs, I've tried to get in touch with them but they don't make it too easy. I have posited on IRC that maybe either somebody is doing something very bad with D (things like _Dmain as a symbol name are pretty obvious to look for!) or they have trained their neural network wrong. It would be nice to get in touch with their engineers to find out what is really going on.
Avast virus warning?
I just sent a pre-compiled .exe of my project to a friend, and his Avast anti-virus promptly quarantined it and sent it off for analysis. I tried sending him a Hello World[1] with the same results. Is this something common for d programs? Anything I can do to work around it from my end? [1]: http://www.mediafire.com/file/fc51qz141r3ns6r/helloworld.exe
Re: rawRead using a struct with variable leght
On Monday, 5 June 2017 at 16:04:28 UTC, ade90036 wrote: Unfortunately the struct doesn't know at compile time what the size of the constant_pool array, or at-least was not able to specify it dynamically. It also won't know ahead of time how many fields, methods or attributes you have either. First I'd say all the arrays will have to be redefined to use [], rather than a fixed size. Glancing at the chapter information, you're probably not going to have an easy time, and will have to simply have to fill in the fields individually in order followed by allocating the arrays and probably filling/loading those immediately (although it's possible the array contents are done at the end, though it seems doubtful).
rawRead using a struct with variable leght
Hi everyone,
I'm trying out Dland, always been and have been a big fan. So to
give it a good run i wanted to create is a java class parser,
based on the spec released here. (
https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html.)
The class file can be represented in the following "struct" like:
ClassFile {
u4 magic;
u2 minor_version;
u2 major_version;
u2 constant_pool_count;
cp_infoconstant_pool[constant_pool_count-1];
u2 access_flags;
u2 this_class;
u2 super_class;
u2 interfaces_count;
u2 interfaces[interfaces_count];
u2 fields_count;
field_info fields[fields_count];
u2 methods_count;
method_infomethods[methods_count];
u2 attributes_count;
attribute_info attributes[attributes_count];
}
where:
u4 == ubyte[4] --> integer
u2 == ubyte[2] --> short
u1 == ubyte[1] --> byte
I have the first 4 fields parsing, however i stumble upon an
example where you can use a rawRead() with a struct, therefore
representing the entire structure and then reading from rawRead()
like
d
ClassFile[1] classFileStruct;
f.rawRead(claddFileStruct);
Unfortunately the struct doesn't know at compile time what the
size of the constant_pool array, or at-least was not able to
specify it dynamically.
What is the best approach to go about parsing such structure?
Should i have structs to represent the blocks of fixed fields
from the structure and then parsing each variable (length)
structure manually?
Something like this?
ClassHeader[1] classHeader;
f.rawRead(classHeader);
CpInfo[] cpInfo = new CpInfo[classHeader.constant_pool_count];
f.rawRead(cpInfo);
`
Really appreciate any knowledgeable suggestions.
Regards
Ade
Re: difference between x = Nullable.init and x.nullify
On Monday, June 05, 2017 10:46:39 Kagamin via Digitalmars-d-learn wrote: > On Sunday, 4 June 2017 at 08:51:44 UTC, Jonathan M Davis wrote: > >> On Saturday, 3 June 2017 at 06:19:29 UTC, Jonathan M Davis > >> > >> wrote: > >> > Assigning Nullable!Test.init is equivalent to setting the > >> > internal value to Test.init and setting _isNull to false. > > > > T _value; > > bool _isNull = true; > > So it was a typo that Nullable.init sets _isNull to false? Yes. - Jonathan M Davis
Re: Linker cannot find malloc and free on OS X
On 2017-06-05 13:48, bvoq wrote:
So I ran: dmd -unittest -main -v -L-lgmp -L-lc -g gmp/*
The error seems to stem from: cc dbgio.o -o dbgio -g -m64 -Xlinker
-no_compact_unwind -lgmp -lc -L/usr/local/Cellar/dmd/2.074.0/lib -lgmp
-lgmp -lgmp -lgmp -lc -lphobos2 -lpthread -lm
Full invocation of command with verbose flag: cc dbgio.o -o dbgio -g
-m64 -Xlinker -no_compact_unwind -lgmp -lc
-L/usr/local/Cellar/dmd/2.074.0/lib -lgmp -lgmp -lgmp -lgmp -lc
-lphobos2 -lpthread -lm -v
gmp -lc -L/usr/local/Cellar/dmd/2.074.0/lib -lgmp -lgmp -lgmp -lgmp -lc
-lphobos2 -lpthread -lm -v
Apple LLVM version 8.1.0 (clang-802.0.42)
Target: x86_64-apple-darwin16.7.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld"
-demangle -lto_library
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib
-dynamic -arch x86_64 -macosx_version_min 10.12.0 -o dbgio
-L/usr/local/Cellar/dmd/2.074.0/lib dbgio.o -no_compact_unwind -lgmp -lc
-lgmp -lgmp -lgmp -lgmp -lc -lphobos2 -lpthread -lm -lSystem
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/8.1.0/lib/darwin/libclang_rt.osx.a
Undefined symbols for architecture x86_64:
"free", referenced from:
_D3gmp1z3MpZ6__ctorMFNaNbNcNiNexAyakZS3gmp1z3MpZ in dbgio.o
_D3gmp1z3MpZ10fromStringMFNaNbNcNiNjNexAyakZS3gmp1z3MpZ in dbgio.o
I've managed to isolate and identified the problem. The problem is these
two lines [1]:
pragma(mangle, "malloc") void* qualifiedMalloc(size_t size);
pragma(mangle, "free") void qualifiedFree(void* ptr);
On macOS all C symbols are mangled with an underscore prefix, meaning
the "free" and "malloc" symbols are actually named _free and _malloc in
the binary.
This is easy to verify by:
$ cat main.c
void foo();
int main()
{
foo();
return 0;
}
$ clang main.c
Undefined symbols for architecture x86_64:
"_foo", referenced from:
_main in main-8a6861.o
Here we can see that the linker is looking for the "_foo" symbol, while
in your output it's looking for "free", without the underscore prefix.
When pragma(mangle) is used on an extern(C) symbol the compiler will
automatically handle the prefixing of the symbol on macOS, making it
line up with any C symbols.
Functions with D linkage have their own mangling, prefixed with _D, the
fully qualified name mangled and the signature. It seems like that when
using pragma(mangle) on function with D linkage the compiler will output
the symbol exactly like it's specified in the source code, in
pragma(mangle). This can be verified by:
$ cat main.d
void foo();
void main()
{
foo();
}
$ dmd -c main.d
$ nm main.o | grep foo
U _D4main3fooFZv
And when using pragma(mangle):
$ cat main.d
pragma(mangle, "foo") void foo();
void main()
{
foo();
}
$ dmd -c main.d
$ nm main.o | grep foo
U foo
No underscore prefix.
This happens to work on Linux because on Linux this mangling (with the
underscore prefix) is not used for C symbols. But since the functions
are not declared as extern(C) we're actually calling C functions using
the D calling conventions, which just happens to work in this case
because the C and D calling conventions are mostly the same.
[1] https://github.com/nordlow/gmp-d/blob/master/src/gmp/z.d#L1164-L1165
--
/Jacob Carlborg
Re: Linker cannot find malloc and free on OS X
On Monday, 5 June 2017 at 10:34:12 UTC, Jacob Carlborg wrote: On 2017-06-05 01:14, bvoq wrote: The flag -L-lc seems to have been passed to the library. This is the full error message after running it with dub test --verbose You need to continue to invoke the sub commands, that is, DMD, Clang and the linker with the verbose flag (-v) added. There's no point in looking for "-lc" since the C standard library on macOS is placed in /usr/lib/libSystem.B.dylib. So I ran: dmd -unittest -main -v -L-lgmp -L-lc -g gmp/* The error seems to stem from: cc dbgio.o -o dbgio -g -m64 -Xlinker -no_compact_unwind -lgmp -lc -L/usr/local/Cellar/dmd/2.074.0/lib -lgmp -lgmp -lgmp -lgmp -lc -lphobos2 -lpthread -lm Full invocation of command with verbose flag: cc dbgio.o -o dbgio -g -m64 -Xlinker -no_compact_unwind -lgmp -lc -L/usr/local/Cellar/dmd/2.074.0/lib -lgmp -lgmp -lgmp -lgmp -lc -lphobos2 -lpthread -lm -v gmp -lc -L/usr/local/Cellar/dmd/2.074.0/lib -lgmp -lgmp -lgmp -lgmp -lc -lphobos2 -lpthread -lm -v Apple LLVM version 8.1.0 (clang-802.0.42) Target: x86_64-apple-darwin16.7.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -dynamic -arch x86_64 -macosx_version_min 10.12.0 -o dbgio -L/usr/local/Cellar/dmd/2.074.0/lib dbgio.o -no_compact_unwind -lgmp -lc -lgmp -lgmp -lgmp -lgmp -lc -lphobos2 -lpthread -lm -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/8.1.0/lib/darwin/libclang_rt.osx.a Undefined symbols for architecture x86_64: "free", referenced from: _D3gmp1z3MpZ6__ctorMFNaNbNcNiNexAyakZS3gmp1z3MpZ in dbgio.o _D3gmp1z3MpZ10fromStringMFNaNbNcNiNjNexAyakZS3gmp1z3MpZ in dbgio.o (maybe you meant: _D2rt4util9container5treap33__T5TreapTS2gc11gcinterface4RootZ5Treap8freeNodeFNbNiPS2rt4util9container5treap33__T5TreapTS2gc11gcinterface4RootZ5Treap4NodeZv, _D2gc4impl12conservative2gc3Gcx8log_freeMFNbPvZv , _D2gc4impl12conservative2gc4Pool12freePageBitsMFNbmKxG4mZv , _D2gc4impl12conservative2gc8freeTimel , _D2rt5minfo11ModuleGroup4freeMFZv , _D2gc4impl6manual2gc8ManualGC4freeMFNbPvZv , _D2gc4impl12conservative2gc14ConservativeGC10freeNoSyncMFNbPvZv , _D2gc4impl12conservative2gc14ConservativeGC163__T9runLockedS63_D2gc4impl12conservative2gc14ConservativeGC10freeNoSyncMFNbPvZvS37_D2gc4impl12conservative2gc8freeTimelS37_D2gc4impl12conservative2gc8numFreeslTPvZ9runLockedMFNbKPvZv , _D2rt4util9container5treap34__T5TreapTS2gc11gcinterface5RangeZ5Treap8freeNodeFNbNiPS2rt4util9container5treap34__T5TreapTS2gc11gcinterface5RangeZ5Treap4NodeZv , _D2gc4impl12conservative2gc15LargeObjectPool9freePagesMFNbmmZv , _D2rt7dwarfeh15ExceptionHeader4freeFPS2rt7dwarfeh15ExceptionHeaderZv , _D2gc4! impl12conservative2gc14ConservativeGC4freeMFNbPvZv , _D4core6memory2GC4freeFNaNbPvZv , _gc_free ) "malloc", referenced from: _D3gmp1z3MpZ19_allocStringzCopyOfMFNaNbNiNexAyaZPa in dbgio.o (maybe you meant: _D2gc4impl12conservative2gc3Gcx10log_mallocMFNbPvmZv, _D2gc4impl12conservative2gc10mallocTimel , _D2gc4impl6manual2gc8ManualGC6mallocMFNbmkxC8TypeInfoZPv , _D2gc4impl12conservative2gc14ConservativeGC207__T9runLockedS83_D2gc4impl12conservative2gc14ConservativeGC13reallocNoSyncMFNbPvmKkKmxC8TypeInfoZPvS40_D2gc4impl12conservative2gc10mallocTimelS40_D2gc4impl12conservative2gc10numMallocslTPvTmTkTmTxC8TypeInfoZ9runLockedMFNbKPvKmKkKmKxC8TypeInfoZPv , _D2gc4impl12conservative2gc14ConservativeGC6mallocMFNbmkxC8TypeInfoZPv , _D2gc4impl12conservative2gc14ConservativeGC12mallocNoSyncMFNbmkKmxC8TypeInfoZPv , _D4core6memory2GC6mallocFNaNbmkxC8TypeInfoZPv , _gc_malloc , _D2rt4util9container6common7xmallocFNbNimZPv , _D2gc4impl12conservative2gc14ConservativeGC200__T9runLockedS79_D2gc4impl12conservative2gc14ConservativeGC12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS40_D2gc4impl12conservative2gc10mallocTimelS40_D2gc4impl12conservative2gc10numMallocslTmTkTmTxC8TypeInfoZ9runLockedMFNbKmKkKmKxC8TypeInfoZPv ) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) -- From there the command which yielded the error is: "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -dynamic -arch x86_64 -macosx_version_min 10.12.0 -o dbgio -L/usr/local/Cellar/dmd/2.074.0/lib dbgio.o -no_compact_unwind -lgmp -lc -lgmp -lgmp -lgmp -lgmp -lc -lphobos2 -lpthread -lm -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/8.1.0/lib/darwin/libclang_rt.osx.a -v The
Re: Implicit casting of int enum members to int
On Monday, 5 June 2017 at 01:23:22 UTC, Mike B Johnson wrote: On Monday, 3 October 2016 at 09:21:37 UTC, Jonathan M Davis wrote: Is this bug ever going to be fixed? I've filed this issue under https://issues.dlang.org/show_bug.cgi?id=16586 a while ago, seems to have not been picked up yet.
Re: difference between x = Nullable.init and x.nullify
On Sunday, 4 June 2017 at 08:51:44 UTC, Jonathan M Davis wrote: On Saturday, 3 June 2017 at 06:19:29 UTC, Jonathan M Davis wrote: > Assigning Nullable!Test.init is equivalent to setting the > internal value to Test.init and setting _isNull to false. T _value; bool _isNull = true; So it was a typo that Nullable.init sets _isNull to false?
Re: Linker cannot find malloc and free on OS X
On 2017-06-05 01:14, bvoq wrote: The flag -L-lc seems to have been passed to the library. This is the full error message after running it with dub test --verbose You need to continue to invoke the sub commands, that is, DMD, Clang and the linker with the verbose flag (-v) added. There's no point in looking for "-lc" since the C standard library on macOS is placed in /usr/lib/libSystem.B.dylib. -- /Jacob Carlborg
Re: D and GDB
On 06/05/2017 03:07 AM, H. S. Teoh via Digitalmars-d-learn wrote: It can't be any more trivial than just running ddemangle, which is found in the dlang/tools repo on github. (Arguably this should be shipped by default with dmd... or is it already?) Recent? versions of gdb also support demangling D symbols, it should detect it's D when you compile with -g. -- Mike Wey
Re: iOS Apps in D
On Wednesday, 31 May 2017 at 12:49:38 UTC, Oleksii wrote: Hi everybody, Perhaps this topic has been raised many times before, but I'm going to go back to it anyways :-P Are there any good reference materials and/or tutorials on programming for iOS and Android in D? Other than this wiki page that shows you how to build a basic Android app and the README for the iOS port, no: https://wiki.dlang.org/Build_LDC_for_Android https://github.com/smolt/ldc-iphone-dev/blob/master/README.md I wonder if anybody could share their story of success with D on mobile? I don't think there has been one. The closest is this demo of porting some DlangUI apps to Android: http://forum.dlang.org/thread/cdekkumjynhqoxvmg...@forum.dlang.org
Re: D scripting in D
On Saturday, 3 June 2017 at 17:28:36 UTC, Adam D. Ruppe wrote: On Saturday, 3 June 2017 at 17:24:08 UTC, Russel Winder wrote: So why isn't rdmd shipped as a separate thing if it can wrap any of the three compilers? it is... the link above is all there is to it, you simply compile it. The docs also call it a download: http://dlang.org/rdmd.html dmd just happens to bundle it. The others prolly should too. Ldc should have it in the next release, except on Windows: https://github.com/ldc-developers/ldc/issues/548#issuecomment-306073946
