Re: warning: pointer not aligned at address
ld: warning: pointer not aligned at address 0x100050C7D Are you running macOS and recently installed an update to Xcode? I ran into this today as well. Looks like other have too: https://issues.dlang.org/show_bug.cgi?id=17289
Re: warning: pointer not aligned at address
Conveniently the site is down immediately after I posted that so
here is the code to which I was referring:
import std.stdio, std.algorithm, std.range;
enum DoorState : bool { closed, open }
alias Doors = DoorState[];
Doors flipUnoptimized(Doors doors) pure nothrow {
doors[] = DoorState.closed;
foreach (immutable i; 0 .. doors.length)
for (ulong j = i; j < doors.length; j += i + 1)
if (doors[j] == DoorState.open)
doors[j] = DoorState.closed;
else
doors[j] = DoorState.open;
return doors;
}
Doors flipOptimized(Doors doors) pure nothrow {
doors[] = DoorState.closed;
for (int i = 1; i ^^ 2 <= doors.length; i++)
doors[i ^^ 2 - 1] = DoorState.open;
return doors;
}
void main() {
auto doors = new Doors(100);
foreach (const open; [doors.dup.flipUnoptimized,
doors.dup.flipOptimized])
iota(1, open.length + 1).filter!(i => open[i -
1]).writeln;
}
warning: pointer not aligned at address
When compiled with any dmd compiler from 2.069.0 through present (2.074.0), https://rosettacode.org/wiki/100_doors#D produces the following linker warning: ld: warning: pointer not aligned at address 0x10004FCEB (_D51TypeInfo_S3std5range13__T4iotaTiTmZ4iotaFimZ6Result6__initZ + 24 from doors100.o) [65 other lines removed for brevity] ld: warning: pointer not aligned at address 0x100050C7D (_D11TypeInfo_xb6__initZ + 16 from doors100.o) specific compilers checked: dmd-2.068.0 dmd-2.068.1 dmd-2.068.2 dmd-2.069.0 dmd-2.070.0 dmd-2.071.2 dmd-2.073.1 dmd-2.073.2 dmd-2.074.0 What's the proper way to address these warnings? The code is linked and works as expected but, to me, there is just something about those warnings that cries out for attention. Is there something I can do to align this code or is this something that needs to be addressed in the compiler? Thanks, Andrew
Re: length = 0 clears reserve
On Tuesday, 11 April 2017 at 20:00:48 UTC, Jethro wrote: On Tuesday, 11 April 2017 at 03:00:29 UTC, Jon Degenhardt wrote: On Tuesday, 11 April 2017 at 01:59:57 UTC, Jonathan M Davis wrote: On Tuesday, April 11, 2017 01:42:32 Jethro via Digitalmars-d-learn wrote: [...] You can't reuse the memory of a dynamic array by simply setting its length to 0. If that were allowed, it would risk allow dynamic arrays to stomp on each others memory (since there is no guarantee that there are no other dynamic arrays referring to the same memory). However, if you know that there are no other dynamic arrays referrin to the same memory, then you can call assumeSafeAppend on the dynamic array, and then the runtime will assume that there are no other dynamic arrays referring to the same memory. [snip] Another technique that works for many cases is to use an Appender (std.array). Appender supports reserve and clear, the latter setting the length to zero without reallocating. A typical use case is an algorithm doing a series of appends, then setting the length to zero and starts appending again. --Jon Appender reports clear? Are you sure? Seems appender is no different than string, maybe worse? string as assumeSafeAppend, reserve and clear(although clear necessarily reallocates. They should have a function called empty, which resets the length to zero but doesn't reallocate. See the Appender.clear documentation (https://dlang.org/phobos/std_array.html#.Appender.clear), the key piece being: Clears the managed array. This allows the elements of the array to be reused for appending. I've tried using both dynamic array and appender in this way, setting the length of the dynamic array to zero vs using Appender.clear, in this cycle of fill-the-array by appending, operate on the array, clearing, and repeating. Appender is dramatically faster. And, if you look at GC reports you find that setting a dynamic array to zero creates garbage to collect, while Appender.clear does not. (Use the --DRT-gcopt=profile:1 command line option to see GC reports, described here: https://dlang.org/spec/garbage.html#gc_config).
Re: length = 0 clears reserve
On Tuesday, 11 April 2017 at 03:00:29 UTC, Jon Degenhardt wrote: On Tuesday, 11 April 2017 at 01:59:57 UTC, Jonathan M Davis wrote: On Tuesday, April 11, 2017 01:42:32 Jethro via Digitalmars-d-learn wrote: [...] You can't reuse the memory of a dynamic array by simply setting its length to 0. If that were allowed, it would risk allow dynamic arrays to stomp on each others memory (since there is no guarantee that there are no other dynamic arrays referring to the same memory). However, if you know that there are no other dynamic arrays referrin to the same memory, then you can call assumeSafeAppend on the dynamic array, and then the runtime will assume that there are no other dynamic arrays referring to the same memory. [snip] Another technique that works for many cases is to use an Appender (std.array). Appender supports reserve and clear, the latter setting the length to zero without reallocating. A typical use case is an algorithm doing a series of appends, then setting the length to zero and starts appending again. --Jon Appender reports clear? Are you sure? Seems appender is no different than string, maybe worse? string as assumeSafeAppend, reserve and clear(although clear necessarily reallocates. They should have a function called empty, which resets the length to zero but doesn't reallocate.
Re: GNU Guile D language interop
On Monday, 10 April 2017 at 05:15:50 UTC, new2d wrote: Think you can share the code? I cannot find it at the moment. If I come upon it, I will post a link here. I remember now that Guile is less friendly than other Schemes, so I created a C library to handle the data passing between Guile and D. That is not a perfect solution so I changed to Gambit instead.
Re: What is this error message telling me?
On Tuesday, April 11, 2017 14:51:44 Anonymous via Digitalmars-d-learn wrote:
> I was watching a dconf presentation from last year and wanted to
> try this out: https://github.com/luismarques/parnas72. It doesn't
> compile / run as it is and the problem seems to be in the
> function below.
>
> import std.algorithm;
> import std.range;
> import std.uni;
> /// Performs [["foo", "bar"], ["baz"]] -> ["baz", "foo bar"]
> auto alphabetized(Range)(Range range)
> {
> return range
> .map!(line => line.joiner(" "))
> .array
> .sort!((a, b) => icmp(a, b) < 0);
> }
>
> void main()
> {
> auto a = alphabetized([["foo", "bar"], ["baz"]]);
> }
>
>
> More specifically, icmp doesn't seem to be allowed as the
> predicate for sort:
>
> Here's the error message I get:
>
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\uni.d(7082): Error:
> function 'std.algorithm.searching.skipOver!(Result,
> dstring).skipOver' is not nothrow
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\uni.d(7055): Error:
> nothrow function 'std.uni.fullCasedCmp!(Result).fullCasedCmp' may
> throw
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\uni.d(7136): Error:
> template instance std.uni.fullCasedCmp!(Result) error
> instantiating
> test.d(14):instantiated from here: icmp!(Result, Result)
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm\sorting.d(1851):
> instantiated from here: __lambda3!(Result, Result) test.d(14):
> instantiated from here: sort!((a, b) =>
> icmp(a, b) < 0, cast(SwapStrategy)0, Result[])
> test.d(19):instantiated from here:
> alphabetized!(string[][])
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm\sorting.d(1863):
> Error: static assert "Invalid predicate passed to sort: __lambda3"
> test.d(14):instantiated from here: sort!((a, b) =>
> icmp(a, b) < 0, cast(SwapStrategy)0, Result[])
> test.d(19):instantiated from here:
> alphabetized!(string[][])
>
>
> My question is, how do I begin to understand error messages like
> the above? I looked at the signature for sort and icmp and don't
> get what the problem is.
Well, it's telling you that skipOver isn't nothrow, which only matters if
it's being called from a nothrow function. It's then telling you that
fullCasedCmp can't compile, because it's marked as nothrow, and it's calling
a function that isn't nothrow (and thus could throw) - since it's calling
skipOver. In turn, it's telling you that it can't instantiate fullCasedCmp
(since it couldn't compile it, because it's nothrow but is calling a
function that can throw). It's then telling you that fullCaseCmp was
instantiated inside of icmp and that icmp was instantiated inside of a
lambda that's at line 14 of test.d. At that point, you see a line in your
code, so you know where in your code things went wrong, but it continues on,
indicating that that means that sort won't compile and then that
alphabetized won't compile.
So, the problem here at the root of all of this is that when icmp is
compiled with the ranges that you gave it, skipOver is inferred to _not_ be
nothrow, whereas fullCasedCmp which is calling skipOver and in turn is
called from icmp is marked as nothrow. So, the ranges that you're passing to
icmp have functions which are called in skipOver which are not nothrow
(probably front and popFront).
This is a bug with fullCasedCmp (which is a private function calle by icmp).
Someone decided to mark it as nothrow when it should _not_ have been marked
as nothrow. It's also marked as @trusted and pure - both of which are also
wrong. The code is incorrectly assuming that the ranges that will be passed
in have pure and nothrow functions and that they're not doing anything
@system which can't be assumed to be @trusted. That will be true for some
ranges but not others. In general, marking templated functions with
attributes is a problem for exactly this reason. They must correctly apply
to _all_ valid template arguments, or they shouldn't be there.
So, this should be reported as a bug in icmp.
https://issues.dlang.org/
- Jonathan M Davis
Re: What is this error message telling me?
On Tuesday, 11 April 2017 at 14:51:44 UTC, Anonymous wrote:
I was watching a dconf presentation from last year and wanted
to try this out: https://github.com/luismarques/parnas72. It
doesn't compile / run as it is and the problem seems to be in
the function below.
import std.algorithm;
import std.range;
import std.uni;
/// Performs [["foo", "bar"], ["baz"]] -> ["baz", "foo bar"]
auto alphabetized(Range)(Range range)
{
return range
.map!(line => line.joiner(" "))
.array
.sort!((a, b) => icmp(a, b) < 0);
}
void main()
{
auto a = alphabetized([["foo", "bar"], ["baz"]]);
}
More specifically, icmp doesn't seem to be allowed as the
predicate for sort:
Here's the error message I get:
C:\D\dmd2\windows\bin\..\..\src\phobos\std\uni.d(7082): Error:
function 'std.algorithm.searching.skipOver!(Result,
dstring).skipOver' is not nothrow
C:\D\dmd2\windows\bin\..\..\src\phobos\std\uni.d(7055): Error:
nothrow function 'std.uni.fullCasedCmp!(Result).fullCasedCmp'
may throw
C:\D\dmd2\windows\bin\..\..\src\phobos\std\uni.d(7136): Error:
template instance std.uni.fullCasedCmp!(Result) error
instantiating
test.d(14):instantiated from here: icmp!(Result, Result)
C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm\sorting.d(1851):
instantiated from here: __lambda3!(Result, Result)
test.d(14):instantiated from here: sort!((a, b) =>
icmp(a, b) < 0, cast(SwapStrategy)0, Result[])
test.d(19):instantiated from here:
alphabetized!(string[][])
C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm\sorting.d(1863): Error: static
assert "Invalid predicate passed to sort: __lambda3"
test.d(14):instantiated from here: sort!((a, b) =>
icmp(a, b) < 0, cast(SwapStrategy)0, Result[])
test.d(19):instantiated from here:
alphabetized!(string[][])
My question is, how do I begin to understand error messages
like the above? I looked at the signature for sort and icmp and
don't get what the problem is.
Thanks.
The following code gives you the output you want:
//code starts
import std.algorithm: joiner, map, sort, cmp;
import std.array: array;
auto alpha(T)(T[][] range) {
return range
.map!(line => line.joiner(" "))
.array
.sort!((a,b) => cmp(a, b) < 0);
}
void main() {
import std.stdio;
auto a = alpha!string([["foo", "bar"], ["baz"]]);
a.writeln;
}
//code ends
I really don't know why your program gave you any errors, but I
can tell you my thinking process. Immediately the first thing I
noticed was that your function parameters didn't look explicit at
all, so I tried to make them more explicit here. Next, i noticed
the use of icmp was the problem in the error message. I thought
maybe that function was outdated or something, so i decided to
use the comparison function in std.algorithm. Third, I used
selective importing in case the compiler got confused what
functions to use.
All and all, for me, I read the error messages from the bottom
up. Also I usually use functions found in std.algorithm because
they seem for stable for me.
Re: Dub, Git, Mercurial, Bazaar
On Tuesday, 11 April 2017 at 04:59:27 UTC, Russel Winder wrote: Go only uses Git, Mercurial, or Bazaar for dependency handling. Rust (via Cargo) allows for a central repository, and Git (, and Mercurial ?) repositories. Dub appears only to allow for central repository, or have I missed it's ability to work with DVCS repositories? https://github.com/dlang/dub/issues/632
What is this error message telling me?
I was watching a dconf presentation from last year and wanted to
try this out: https://github.com/luismarques/parnas72. It doesn't
compile / run as it is and the problem seems to be in the
function below.
import std.algorithm;
import std.range;
import std.uni;
/// Performs [["foo", "bar"], ["baz"]] -> ["baz", "foo bar"]
auto alphabetized(Range)(Range range)
{
return range
.map!(line => line.joiner(" "))
.array
.sort!((a, b) => icmp(a, b) < 0);
}
void main()
{
auto a = alphabetized([["foo", "bar"], ["baz"]]);
}
More specifically, icmp doesn't seem to be allowed as the
predicate for sort:
Here's the error message I get:
C:\D\dmd2\windows\bin\..\..\src\phobos\std\uni.d(7082): Error:
function 'std.algorithm.searching.skipOver!(Result,
dstring).skipOver' is not nothrow
C:\D\dmd2\windows\bin\..\..\src\phobos\std\uni.d(7055): Error:
nothrow function 'std.uni.fullCasedCmp!(Result).fullCasedCmp' may
throw
C:\D\dmd2\windows\bin\..\..\src\phobos\std\uni.d(7136): Error:
template instance std.uni.fullCasedCmp!(Result) error
instantiating
test.d(14):instantiated from here: icmp!(Result, Result)
C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm\sorting.d(1851):
instantiated from here: __lambda3!(Result, Result)
test.d(14):instantiated from here: sort!((a, b) =>
icmp(a, b) < 0, cast(SwapStrategy)0, Result[])
test.d(19):instantiated from here:
alphabetized!(string[][])
C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm\sorting.d(1863): Error: static
assert "Invalid predicate passed to sort: __lambda3"
test.d(14):instantiated from here: sort!((a, b) =>
icmp(a, b) < 0, cast(SwapStrategy)0, Result[])
test.d(19):instantiated from here:
alphabetized!(string[][])
My question is, how do I begin to understand error messages like
the above? I looked at the signature for sort and icmp and don't
get what the problem is.
Thanks.
Re: Dub and compilation
On Tue, 2017-04-11 at 13:24 +, Mike Parker via Digitalmars-d-learn wrote: > On Tuesday, 11 April 2017 at 11:13:30 UTC, Russel Winder wrote: > > > This is not what seems to happen with unit-threaded. for the > > directory ~/.dub/packages/unit-threaded-0.7.11/unit-threaded, > > the tree is: > > Just to be clear -- is this what you see after compiling a > project that depends on unit-threaded, or did you do something > like `dub build unit-threaded`? > Actually for 0.7.11 I had done lots of fiddling so could not guarantee. However 0.7.13 appeared unexpectedly and so is a fresh install driven by an application build dependent on unit-threaded. It has the exact same structure. So it is the way Dub builds unit-threaded, requiring rebuild for every change of configuration or platform. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Dub and compilation
On Tuesday, 11 April 2017 at 11:13:30 UTC, Russel Winder wrote: This is not what seems to happen with unit-threaded. for the directory ~/.dub/packages/unit-threaded-0.7.11/unit-threaded, the tree is: Just to be clear -- is this what you see after compiling a project that depends on unit-threaded, or did you do something like `dub build unit-threaded`?
Re: Dub, Git, Mercurial, Bazaar
On 11/04/2017 5:59 AM, Russel Winder via Digitalmars-d-learn wrote: Go only uses Git, Mercurial, or Bazaar for dependency handling. Rust (via Cargo) allows for a central repository, and Git (, and Mercurial ?) repositories. Dub appears only to allow for central repository, or have I missed it's ability to work with DVCS repositories? If Dub cannot handle DVCS repositories, it needs to be able to. The rationale is that people can access dependencies that are available but not yet, or never will be, in the central repository. The use case that matters is working with a dependency that is not yet, but definitely will be in the central repository. Experience of Rust, and Herd with Ceylon, shows this to be very valuable to community activity. FYI, if we wanted a user configurable interfacing to any source of projects we would need some complicated "scripting" to allow for it. E.g. I have a little bit of code that can help with this[0]. I'm currently designing a UI for it but ugh, it would be a lot of work to get this working for dub. [0] https://gist.github.com/rikkimax/4718740223748256d94b3b1474525012
Re: Dub, Git, Mercurial, Bazaar
11.04.2017 15:12, Russel Winder via Digitalmars-d-learn пишет: On Tue, 2017-04-11 at 14:21 +0300, drug via Digitalmars-d-learn wrote: 11.04.2017 14:15, Russel Winder via Digitalmars-d-learn пишет: On Tue, 2017-04-11 at 09:55 +0300, drug via Digitalmars-d-learn wrote: […] You can use local repository if you want But that implies something very manual, go and cargo handle all that. How go and cargo know where the local repository is to handle that? I fear we may well have started talking at cross purposes. At the risk of doing the wrong thing I'll reset this thread with: Go allows for any Git, Mercurial or Bazaar repository as a dependency. It fetches the source into the workspace and compiles into the workspace. The go language uses URIs to specify the import so the DVCS nature is up front – and leads to lots of vendoring problems. There is only the Go distribution and DVCS repositories. Cargo fetches source from the central crate repository or from a DVCS repository depending on the contents of the Cargo.toml file. The crate names are the only thing the application source code knows about. There is a central repository and DVCS repositories. Dub cannot get from a DVCS repository but has a sequence of repositories it can reach. It is feasible that these local Dub repositories could have been got by DVCS, but this is a manual thing not something Dub handles, unlike Go and Cargo. I feel that Dub should behave more like Cargo. I see. Thanks for clarification.
Re: Dub, Git, Mercurial, Bazaar
On Tuesday, April 11, 2017 05:59:27 Russel Winder via Digitalmars-d-learn wrote: > Go only uses Git, Mercurial, or Bazaar for dependency handling. Rust > (via Cargo) allows for a central repository, and Git (, and Mercurial > ?) repositories. Dub appears only to allow for central repository, or > have I missed it's ability to work with DVCS repositories? > > If Dub cannot handle DVCS repositories, it needs to be able to. > > The rationale is that people can access dependencies that are available > but not yet, or never will be, in the central repository. The use case > that matters is working with a dependency that is not yet, but > definitely will be in the central repository. > > Experience of Rust, and Herd with Ceylon, shows this to be very > valuable to community activity. dub works well overall, but I don't think that there's any question that it could use some improvements. If you have concrete ideas on how you'd like to see it improved, I'd suggest heading over to the dub forums and discussing them there: http://forum.rejectedsoftware.com/ If nothing else, I believe that Sonke is a lot more likely to see posts about it there than here. So, I would expect that making suggestions there would be more productive. - Jonathan M Davis
Re: Dub, Git, Mercurial, Bazaar
On Tue, 2017-04-11 at 14:21 +0300, drug via Digitalmars-d-learn wrote: > 11.04.2017 14:15, Russel Winder via Digitalmars-d-learn пишет: > > On Tue, 2017-04-11 at 09:55 +0300, drug via Digitalmars-d-learn > > wrote: > > > […] > > > You can use local repository if you want > > > > But that implies something very manual, go and cargo handle all > > that. > > > > How go and cargo know where the local repository is to handle that? I fear we may well have started talking at cross purposes. At the risk of doing the wrong thing I'll reset this thread with: Go allows for any Git, Mercurial or Bazaar repository as a dependency. It fetches the source into the workspace and compiles into the workspace. The go language uses URIs to specify the import so the DVCS nature is up front – and leads to lots of vendoring problems. There is only the Go distribution and DVCS repositories. Cargo fetches source from the central crate repository or from a DVCS repository depending on the contents of the Cargo.toml file. The crate names are the only thing the application source code knows about. There is a central repository and DVCS repositories. Dub cannot get from a DVCS repository but has a sequence of repositories it can reach. It is feasible that these local Dub repositories could have been got by DVCS, but this is a manual thing not something Dub handles, unlike Go and Cargo. I feel that Dub should behave more like Cargo. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Dub, Git, Mercurial, Bazaar
11.04.2017 14:15, Russel Winder via Digitalmars-d-learn пишет: On Tue, 2017-04-11 at 09:55 +0300, drug via Digitalmars-d-learn wrote: […] You can use local repository if you want But that implies something very manual, go and cargo handle all that. How go and cargo know where the local repository is to handle that?
Re: Dub, Git, Mercurial, Bazaar
On Tue, 2017-04-11 at 09:55 +0300, drug via Digitalmars-d-learn wrote: > […] > You can use local repository if you want But that implies something very manual, go and cargo handle all that. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Dub and compilation
On Tue, 2017-04-11 at 09:57 +0300, drug via Digitalmars-d-learn wrote: > […] > There is possibility to place binaries to specified directory using > `targetPath` (see `Build settings` in Dub documentation) That is fine for the project code, but doesn't help with the dependencies. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Dub and compilation
On Tue, 2017-04-11 at 06:45 +, Mike Parker via Digitalmars-d-learn wrote: > […] > DUB downloads the source of dependencies from github and stores > it all in the system cache. Each package has its own versioned > folder in the cache and, when compiled, is given a .dub > subdirectory in the package root. Beneath that is a 'build' > directory, with more subdirectories containing the compiled > binaries, each directory named according to the build > configuration. […] This is not what seems to happen with unit-threaded. for the directory ~/.dub/packages/unit-threaded-0.7.11/unit-threaded, the tree is: . ├── appveyor.yml ├── dub.json ├── example │ ├── example_fail.d │ └── example_pass.d ├── gen │ └── gen_ut_main.d ├── gen_ut_main ├── libunit-threaded.a ├── LICENSE ├── msbuild.proj ├── README.md ├── source │ └── unit_threaded │ ├── asserts.d │ ├── attrs.d │ ├── dub.d │ ├── factory.d │ ├── integration.d │ ├── io.d │ ├── meta.d │ ├── mock.d │ ├── options.d │ ├── package.d │ ├── property │ │ └── package.d │ ├── randomized │ │ ├── benchmark.d │ │ ├── gen.d │ │ ├── package.d │ │ └── random.d │ ├── reflection.d │ ├── runner.d │ ├── runtime.d │ ├── should.d │ ├── testcase.d │ ├── tests │ │ ├── issue33.d │ │ ├── mocks.d │ │ ├── module_with_attrs.d │ │ ├── module_with_setup.d │ │ ├── module_with_tests.d │ │ ├── parametrized.d │ │ ├── structs_are_not_classes.d │ │ └── tags.d │ ├── testsuite.d │ └── uda.d ├── tests │ ├── fail │ │ ├── composite.d │ │ ├── delayed.d │ │ ├── exception.d │ │ ├── klass.d │ │ ├── normal.d │ │ └── priv.d │ └── pass │ ├── attributes.d │ ├── delayed.d │ ├── fixtures.d │ ├── io.d │ ├── issue51.d │ ├── mock.d │ ├── normal.d │ ├── property.d │ ├── register.d │ └── types.d └── TODO.txt Note that the gen_ut_main executable and the libunit-threaded.a library are at the top level and have to recompiled for each configuration/platform change. There is no separation of the various configurations and platforms. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Single exe vibe.d app
On 11/04/2017 8:08 AM, Suliman wrote: On Friday, 7 April 2017 at 07:15:44 UTC, rikki cattermole wrote: I'm going to give you a very bad but still a good place to begin with explanation. So, what is an executable? Well in modern operating systems that is a file with a very complex structure inside, like PE-COFF or ELF. It has a bunch of things as part of this, a dynamic relocation table, sections and symbols. Now, there is a very important symbol it provides a "main" function. Normally the libc takes ownership of this and then on calls to the c-main that we all know and love (druntime uses this and then passes it to another symbol called _Dmain). What is the difference between a shared library and an executable? Well not much, no main function for starters (although Win32 based ones do have something like it in its place) and a couple of attributes stored in the file. Executables like shared libraries are final binaries, they cannot be further linked with, at least with the most common formats + linkers anyway. You asked about the difference between a static library and a shared library, it isn't quite the right comparison. You should be asking about static libraries versus object files. In essence a static library is just a group of object files. Not too complicated. Ok, but what about Go? I have heard that it's compile all code to single exe? What is the way it's done there? I can't quote what Go has for a runtime (and if it does the _Dmain trick) but over all, since it is a native language everything I have said should be valid. I just checked[0] it is all completely valid, Go forces you to jump through hoops to do it though. [0] http://blog.hashbangbash.com/2014/04/linking-golang-statically/
Re: Single exe vibe.d app
On Friday, 7 April 2017 at 07:15:44 UTC, rikki cattermole wrote: I'm going to give you a very bad but still a good place to begin with explanation. So, what is an executable? Well in modern operating systems that is a file with a very complex structure inside, like PE-COFF or ELF. It has a bunch of things as part of this, a dynamic relocation table, sections and symbols. Now, there is a very important symbol it provides a "main" function. Normally the libc takes ownership of this and then on calls to the c-main that we all know and love (druntime uses this and then passes it to another symbol called _Dmain). What is the difference between a shared library and an executable? Well not much, no main function for starters (although Win32 based ones do have something like it in its place) and a couple of attributes stored in the file. Executables like shared libraries are final binaries, they cannot be further linked with, at least with the most common formats + linkers anyway. You asked about the difference between a static library and a shared library, it isn't quite the right comparison. You should be asking about static libraries versus object files. In essence a static library is just a group of object files. Not too complicated. Ok, but what about Go? I have heard that it's compile all code to single exe? What is the way it's done there?
Re: Dub and compilation
11.04.2017 08:15, Russel Winder via Digitalmars-d-learn пишет: As I understand it, Dub compiles a downloaded dependency into the local Dub cache. This means you cannot store a debug build and a release build for multiple architectures and different compilers, at the same time, and you only get a .a file, no .so file. Cargo downloads source to the cache but compiles to the project area, separating debug and release builds. Each project has it's own compilation of the shared source. I believe Cargo has this right and Dub has this wrong. So wrong that SCons, CMake, and Meson have a strong role in the D world. As it stands, Dub is fine for fetching dependencies and then has no more role to play in the build of a project. Actually then the Dub command has no useful role since it may well be better for the build tools to just use the Dub repository API directly. Unless I have misunderstood Dub, or someone is fixing it. There is possibility to place binaries to specified directory using `targetPath` (see `Build settings` in Dub documentation)
Re: Dub, Git, Mercurial, Bazaar
11.04.2017 07:59, Russel Winder via Digitalmars-d-learn пишет: Go only uses Git, Mercurial, or Bazaar for dependency handling. Rust (via Cargo) allows for a central repository, and Git (, and Mercurial ?) repositories. Dub appears only to allow for central repository, or have I missed it's ability to work with DVCS repositories? If Dub cannot handle DVCS repositories, it needs to be able to. The rationale is that people can access dependencies that are available but not yet, or never will be, in the central repository. The use case that matters is working with a dependency that is not yet, but definitely will be in the central repository. Experience of Rust, and Herd with Ceylon, shows this to be very valuable to community activity. You can use local repository if you want
