Re: Why are immutable array literals heap allocated?

2019-07-06 Thread Nick Treleaven via Digitalmars-d-learn

On Friday, 5 July 2019 at 23:05:32 UTC, Jonathan M Davis wrote:
Yes, I was wondering why the compiler doesn't statically 
allocate it automatically as an optimization.


It would have to be set up to store the literal somewhere else.


I was thinking the read-only data segment.

Certainly, it can't just put it on the stack, because that 
risks it going out of scope and causing memory problems. It


It can do that with small-ish sized literals if they don't escape 
(-dip1000). I think Walter may have advocated something like 
this. This one can be done even with literals of mutable elements.


no matter what optimizations the compiler does with array 
literals, that shouldn't affect whether the function can be 
@nogc. For it to affect that, it would have to be something 
that was guaranteed by the language's semantics regardless of 
whether any optimizations were being done.


Yes, just like string literals I think static allocation can be 
part of the language for immutable data.




Re: Why are immutable array literals heap allocated?

2019-07-05 Thread Nick Treleaven via Digitalmars-d-learn

On Thursday, 4 July 2019 at 11:06:36 UTC, Eugene Wissner wrote:

static immutable arr = [1, 2];

You have to spell it out that the data is static.


Yes, I was wondering why the compiler doesn't statically allocate 
it automatically as an optimization.


Why are immutable array literals heap allocated?

2019-07-04 Thread Nick Treleaven via Digitalmars-d-learn

immutable(int[]) f() @nogc {
return [1,2];
}

onlineapp.d(2): Error: array literal in `@nogc` function 
`onlineapp.f` may cause a GC allocation


This makes dynamic array literals unusable with @nogc, and adds 
to GC pressure for no reason. What code would break if dmd used 
only static data for [1,2]?


Re: [TWiD] static foreach loop variable

2019-05-28 Thread Nick Treleaven via Digitalmars-d-learn

Ok, thanks for explaining. Nice idea.



Re: Create object from a library's Class returns Null

2019-05-28 Thread Nick Treleaven via Digitalmars-d-learn

On Tuesday, 28 May 2019 at 09:25:51 UTC, dangbinghoo wrote:


class NSconf
{
String name;
...
}


Does this class have a non-default constructor?


Re: Create object from a library's Class returns Null

2019-05-28 Thread Nick Treleaven via Digitalmars-d-learn

On Tuesday, 28 May 2019 at 09:25:51 UTC, dangbinghoo wrote:

writeln(Object.factory("gwlib.entity.nsconf.NSConf"));


Typo, should be NSconf.


[TWiD] static foreach loop variable

2019-05-28 Thread Nick Treleaven via Digitalmars-d-learn

Hi,
Last week's TWiD had a tip that didn't make sense:
http://dpldocs.info/this-week-in-d/Blog.Posted_2019_05_20.html#tip-of-the-week

template Locals(int i) {
alias Whatever = int;
}

static foreach(i; [1, 2, 3]) {
   Locals!i.Whatever;
}

The body is just `int;`. Not sure how to reach Adam. What was 
intended?


Re: Escaping address of

2018-04-12 Thread Nick Treleaven via Digitalmars-d-learn

On Thursday, 12 April 2018 at 00:32:49 UTC, Uknown wrote:
Adding a destructor makes the compiler return an error about 
lifetimes, with or without -dip1000


Thanks. Filed, mentioning this:
https://issues.dlang.org/show_bug.cgi?id=18756


Escaping address of

2018-04-11 Thread Nick Treleaven via Digitalmars-d-learn

Is this a known bug? With v2.079.0, with or without -dip1000:

@safe unittest
{
struct S
{
int i;
}
auto p = ().i;
}

The address of field `i` should not escape, right? It's also 
incorrectly allowed when using an lvalue of S (when -dip1000 is 
not present).


Re: how to make private class member private

2018-03-29 Thread Nick Treleaven via Digitalmars-d-learn
On Sunday, 18 March 2018 at 18:45:23 UTC, Steven Schveighoffer 
wrote:

unittest
{
   auto foo = new Foo;
   assert(foo.internalbuffer.empty); // note, this is a private 
symbol.

}


I don't understand why you would want a private symbol in a 
*documented* unittest, the reader of the *documentation* will not 
be able to run the example code.


I can do the same thing in ddoc, but without the benefit of 
having the unit test run.


You mean not using a unittest?

Forcing me to do it that way is just annoying (I will have to 
duplicate the code).


If you really want your documented unittests not to be runnable 
by a user, you can have a free function with `protected` access 
as a workaround.


Re: how to make private class member private

2018-03-17 Thread Nick Treleaven via Digitalmars-d-learn
On Tuesday, 13 March 2018 at 13:59:00 UTC, Steven Schveighoffer 
wrote:
If you limit to class members, then you have to do something 
like C++ friends, which are unnecessarily verbose.


Not if you also have a module-level visibility modifier, which 
could have been `module`.


IMO, the module-level encapsulation is the right choice. It 
helps with a lot of key features:


1. IFTI factory methods


Aren't these mainly because constructors can't use IFTI, unlike 
C++17, and because nullary struct constructors are banned?



2. unittests


Documented unittests should not be allowed to use private 
symbols, I just filed this:

https://issues.dlang.org/show_bug.cgi?id=18623


Re: how to make private class member private

2018-03-17 Thread Nick Treleaven via Digitalmars-d-learn

On Tuesday, 13 March 2018 at 05:11:48 UTC, psychoticRabbit wrote:
If you have access to the module source, you have access to 
the source of types inside it. Making the module the lowest 
level of encapsulation makes sense from that perspective.


There are two problems I see:

1st - D has broken the concept of class encapsulation, simply 
for convenience at the module level. Not good in my opinion.


It's a language design decision as to whether a particular 
feature is worth supporting. I would like this feature too 
though. I'm not sure how much compiler complexity would be added 
by having another visibility modifier.


I'm surprised how many people here ignore the advantage of being 
able to modify your class/struct fields without the chance of 
breaking template code that might not even be instantiated by a 
unit test. (And no, the answer to this isn't fix your tests, 
because if that's your attitude, why bother with static typing, 
just use duck typing, the unit tests will catch any bugs). In 
theory this and other generic unit test issues could be 
comprehensively solved by having a Rust-like traits feature.


2nd - C++/C#/Java programmers will come to D, use the same 
syntax, but get very different semantics. Not good in my 
opinion. (i.e. I only realised private was not private, by 
accident).


D has made many good design decisions. I do not see this as one 
of them.


+1, D should have used a different keyword, such as `module`. It 
is a classic source of confusion for programmers familiar with 
many statically typed languages, and it comes up regularly here. 
It is a syntax issue, semantically the feature is better than 
just having true private.


Re: building git druntime - range violation in extendedPathThen

2017-12-07 Thread Nick Treleaven via Digitalmars-d-learn
On Wednesday, 6 December 2017 at 17:11:49 UTC, Nick Treleaven 
wrote:
0x005482C2 in nothrow void* 
ddmd.root.filename.extendedPathThen!(ddmd.root.file.File.read().__lambda1).extendedPathThen(const(char*)) at C:\git\dmd\src\ddmd\root\filename.d(834)

0x005480E8 in File at C:\git\dmd\src\ddmd\root\file.d(198)


For now this workaround lets me compile druntime:

--- a/src/ddmd/root/file.d
+++ b/src/ddmd/root/file.d
@@ -193,6 +193,8 @@ nothrow:

 // work around Windows file path length limitation
 // (see documentation for extendedPathThen).
+if (!name[0])
+return true;
 HANDLE h = name.extendedPathThen!
 (p => CreateFileW([0],
   GENERIC_READ,



Re: Does dmd not always compile all of the source code?

2017-12-06 Thread Nick Treleaven via Digitalmars-d-learn
On Wednesday, 6 December 2017 at 17:04:06 UTC, A Guy With a 
Question wrote:

abstract class Test(T)


Here you have a class template.


It does produce there error when I do this:

class Test2
   : Test!int


You instantiated the template, so the compiler can now type check 
the instantiated class.



class Test
   : ITest!int


Same thing here but with an interface template.

I really do think, regardless of if this is considered a 
template expansion, that dmd should be catching these obvious 
errors. When one writes interfaces and abstract classes they 
are generally not ready to implement the end class yet. And 
getting a ton of errors at once when that occurs is really hard 
to deal with. I really don't understand why the compiler would 
have issues with this.


I sympathize, something like Rust's traits or concept-enhanced 
C++ could probably do what you want, but D doesn't have this 
feature.


building git druntime - range violation in extendedPathThen

2017-12-06 Thread Nick Treleaven via Digitalmars-d-learn

Hi,
I checked out dmd and druntime this morning. dmd seems to build 
fine, but when I try druntime I get this error:


$ make -f win32.mak
..\dmd\generated\windows\release\32\dmd -conf= -c -o- -Isrc 
-Iimport -Hfimport\core\sync\barrier.di src\core\sync\barrier.d

DMD v2.077.1
 DEBUG

core.exception.RangeError@ddmd\root\file.d(199): Range violation

0x005D8784 in _d_arrayboundsp
0x0054832C in nothrow void* 
ddmd.root.filename.extendedPathThen!(ddmd.root.file.File.read().__lambda1).extendedPathThen(const(char*)).__lambda2!(wchar[]).__lambda2(wchar[]) at C:\git\dmd\src\ddmd\root\filename.d(804)
0x005491CF in nothrow void* 
ddmd.root.filename.toWStringzThen!(ddmd.root.filename.extendedPathThen!(ddmd.root.file.File.read().__lambda1).extendedPathThen(const(char*)).__lambda2).toWStringzThen(const(char*)) at C:\git\dmd\src\ddmd\root\filename.d(870)
0x005482C2 in nothrow void* 
ddmd.root.filename.extendedPathThen!(ddmd.root.file.File.read().__lambda1).extendedPathThen(const(char*)) at C:\git\dmd\src\ddmd\root\filename.d(834)

0x005480E8 in File at C:\git\dmd\src\ddmd\root\file.d(198)
0x004BD5F5 in int ddmd.mars.tryMain(uint, const(char)**) at 
C:\git\dmd\src\ddmd\mars.d(327)

0x004BF81F in _Dmain at C:\git\dmd\src\ddmd\mars.d(1116)
0x005DAC87 in void rt.dmain2._d_run_main(int, char**, extern (C) 
int function(char[][])*).runAll().__lambda1()
0x005DAC4B in void rt.dmain2._d_run_main(int, char**, extern (C) 
int function(char[][])*).runAll()

0x005DAB4C in _d_run_main
0x004C1880 in main at C:\git\dmd\src\ddmd\root\stringtable.d(7)
0x005F8FF5 in mainCRTStartup
0x76D83823 in BaseThreadInitThunk
0x7773A9BD in LdrInitializeThunk

--- errorlevel 1

Any ideas?


Re: Andrei's "The D Programming Language" book. Up to date?

2017-11-29 Thread Nick Treleaven via Digitalmars-d-learn
On Wednesday, 29 November 2017 at 17:50:59 UTC, Arun 
Chandrasekaran wrote:

Multiple alias this
You can only have one subtyping member currently.



Shared
Not all of shared's guarantees are implemented yet.



SafeD
@safe (and therefore SafeD) isn't fully implemented. So, it 
doesn't necessarily work quite like it's supposed to yet.


How much of these are relevant today with 2.077.0?


The first two are true AIUI. @safe is mostly implemented, there's 
been a lot of progress on that since TDPL.


Re: Andrei's "The D Programming Language" book. Up to date?

2017-11-29 Thread Nick Treleaven via Digitalmars-d-learn

On Wednesday, 4 October 2017 at 20:49:26 UTC, John Gabriele wrote:
What's changed in the language, library, and community since 
then that I should be aware of if following along with and 
learning from that book?


Here's a list of significant things - maybe incomplete:
https://wiki.dlang.org/Differences_With_TDPL


Re: Compile time foreach with switch

2017-04-24 Thread Nick Treleaven via Digitalmars-d-learn

On Saturday, 22 April 2017 at 11:56:31 UTC, Nick Treleaven wrote:

If I compile the above I get:
Deprecation: switch case fallthrough - use 'goto default;' if 
intended


IMO the compiler should issue this warning with the OP's code.


https://issues.dlang.org/show_bug.cgi?id=7390#c4


Re: Compile time foreach with switch

2017-04-22 Thread Nick Treleaven via Digitalmars-d-learn

On Friday, 21 April 2017 at 19:17:32 UTC, Adam D. Ruppe wrote:
Then realize that it does exactly the same thing when it is 
inside a switch... it always breaks the innermost thing, which 
happens to be this loop. (note that cases are not `breaked`, 
the switch is.)


By coincidence I ran into this issue recently and assumed that 
break should break the switch too (and I hadn't read the 
boost::hana thread). Thanks for explaining, I thought it was 
probably a compiler bug and hadn't gotten round to investigating 
further.


So the compiler generates something like this:

int s = 0;
switch (s) {
case 0:
writeln("matched ");
default:
writeln("no match");
break;
}

If I compile the above I get:
Deprecation: switch case fallthrough - use 'goto default;' if 
intended


IMO the compiler should issue this warning with the OP's code.


Re: Can we disallow appending integer to string?

2017-04-21 Thread Nick Treleaven via Digitalmars-d-learn

On Friday, 21 April 2017 at 08:36:12 UTC, Nick Treleaven wrote:
Converting from char types -> integers, whilst (arguably) bug 
prone, at least is numerically sound. So perhaps we could 
disallow uint -> dchar, which is unsound.


That is in the general case - when VRP can prove an integer fits 
within a dchar, by the logic of this proposal, it is allowed.


Re: Can we disallow appending integer to string?

2017-04-21 Thread Nick Treleaven via Digitalmars-d-learn

On Thursday, 20 April 2017 at 11:05:00 UTC, Nick Treleaven wrote:
On Wednesday, 19 April 2017 at 14:50:38 UTC, Stanislav Blinov 
wrote:
Because integrals implicitly convert to characters of same 
width (byte -> char, short -> wchar, int -> dchar).


Despite char.min > byte.min, char.max < byte.max.


The above mismatches would presumably be handled if we disallow 
implicit conversion between signed/unsigned 
(https://issues.dlang.org/show_bug.cgi?id=12919).


I would like to see some small changes to mitigate against 
things like this, even if we can't agree to prevent the 
conversion overall.


It seems there's a strong case for preventing the int -> dchar 
conversion. wchar.max == ushort.max, char.max == ubyte.max, but 
dchar.max < uint.max.


Converting from char types -> integers, whilst (arguably) bug 
prone, at least is numerically sound. So perhaps we could 
disallow uint -> dchar, which is unsound.


Re: Can we disallow appending integer to string?

2017-04-20 Thread Nick Treleaven via Digitalmars-d-learn
On Wednesday, 19 April 2017 at 14:50:38 UTC, Stanislav Blinov 
wrote:
Because integrals implicitly convert to characters of same 
width (byte -> char, short -> wchar, int -> dchar).


Despite char.min > byte.min, char.max < byte.max. Anyway, 
appending an integer is inconsistent because concatenation is not 
allowed:


int n;
string s;
s = "" ~ n; //error
s ~= n; // ok!

This is the same for dchar instead of int.

This is also a problem for overloading:

alias foo = (char c) => 1;
alias foo = (int i) => 4;

static assert(foo(7) == 4); // fails

I would like to see some small changes to mitigate against things 
like this, even if we can't agree to prevent the conversion 
overall. It would be nice if we filed a bug as a rallying point 
for ideas on this issue.


Can we disallow appending integer to string?

2017-04-19 Thread Nick Treleaven via Digitalmars-d-learn
This bug is fixed as the code no longer segfaults but throws 
instead:

https://issues.dlang.org/show_bug.cgi?id=5995

void main(){
string ret;
int i = -1;
ret ~= i;
}

Why is it legal to append an integer?


Re: A simplification of the RvalueRef idiom

2016-11-27 Thread Nick Treleaven via Digitalmars-d-learn

On Friday, 25 November 2016 at 17:21:52 UTC, Nick Treleaven wrote:

I've started documenting it now, will post a PR soon.


https://github.com/dlang/dlang.org/pull/1519


Re: A simplification of the RvalueRef idiom

2016-11-25 Thread Nick Treleaven via Digitalmars-d-learn

On Thursday, 24 November 2016 at 00:35:39 UTC, TheGag96 wrote:
The thing that gets me more is "return" as a function 
attribute. I see it under "MemberFunctionAttribute" in the 
grammar but I can't find an explanation for its use anywhere...


I've started documenting it now, will post a PR soon.


Re: arr.ptr, @safe and void*

2016-06-16 Thread Nick Treleaven via Digitalmars-d-learn
On Wednesday, 15 June 2016 at 20:33:54 UTC, Steven Schveighoffer 
wrote:


It could probably do this. Dereferencing a void * isn't valid, 
so it kind of has the same effect. However, there are many 
functions which take void * and do write to/read from the data 
pointing at it (e.g. memcpy). These aren't @safe, so they 
should be off-limits.


[...]


OK, thanks for explaining ;-)


Re: arr.ptr, @safe and void*

2016-06-15 Thread Nick Treleaven via Digitalmars-d-learn
On Wednesday, 15 June 2016 at 17:35:49 UTC, Steven Schveighoffer 
wrote:

On 6/15/16 6:32 AM, Nick Treleaven wrote:


My question is: would returning void* instead really be 
unsafe, i.e. is
there a way of dereferencing it in safe code? (I'm not 
thinking about

holes in @safe, but ways by design).


Yes. If the meaning of this expression is different in @safe 
vs. @system, then compiler inference can affect code 
drastically:


auto d = arr1.ptr - arr2.ptr;


I probably wasn't clear - I'm not suggesting .ptr returns void*, 
I agree with you. But I don't get why arr.ptrValue can't be safe 
and return void* instead of uintptr_t.


The PR I think you are referring to is mine: 
https://github.com/dlang/druntime/pull/1592


And this would be able to solve the problem, but I don't know 
if it's ready for prime time (proposed to be in core.internal).


I did see this, it's interesting. I suppose the advantage over 
ptrValue would be type safety.




arr.ptr, @safe and void*

2016-06-15 Thread Nick Treleaven via Digitalmars-d-learn

Hi,
Walter's made a fix for arr[$..$].ptr being unsafe to dereference 
- .ptr will be @system:

https://github.com/dlang/dmd/pull/5860

A referenced druntime pull mentioned having a safe wrapper for 
.ptr that allows comparison of the pointer value, but does not 
allow dereference. The wrapper would return uintptr_t (an integer 
guaranteed to be big enough to hold a pointer value).


My question is: would returning void* instead really be unsafe, 
i.e. is there a way of dereferencing it in safe code? (I'm not 
thinking about holes in @safe, but ways by design).


Re: Instantiate!(Template, args) in Phobos?

2016-04-25 Thread Nick Treleaven via Digitalmars-d-learn

On 25/04/2016 11:16, Nick Treleaven wrote:

On Friday, 22 April 2016 at 19:09:40 UTC, David Nadlinger wrote:

alias Instantiate(alias Template, Params...) = Template!Params;


Ah, maybe I'd even seen this in passing and forgot. Good point about
aliasSeq template elements, let's make this public.


https://github.com/dlang/phobos/pull/4234


Re: Instantiate!(Template, args) in Phobos?

2016-04-25 Thread Nick Treleaven via Digitalmars-d-learn

On Friday, 22 April 2016 at 19:09:40 UTC, David Nadlinger wrote:

From std.meta:

---
/*
 * Instantiates the given template with the given list of 
parameters.

 *
 * Used to work around syntactic limitations of D with regard 
to instantiating
 * a template from an alias sequence (e.g. T[0]!(...) is not 
valid) or a template
 * returning another template (e.g. Foo!(Bar)!(Baz) is not 
allowed).

 */
// TODO: Consider publicly exposing this, maybe even if only 
for better

// understandability of error messages.
alias Instantiate(alias Template, Params...) = Template!Params;


Ah, maybe I'd even seen this in passing and forgot. Good point 
about aliasSeq template elements, let's make this public.


Re: Instantiate!(Template, args) in Phobos?

2016-04-22 Thread Nick Treleaven via Digitalmars-d-learn

On 22/04/2016 14:40, Steven Schveighoffer wrote:

OK, I get it. I think this used to work, but I think D has long since
disallowed direct access to eponymous members.

So what you really want to do is:

staticEx!(Exception, msg)!(file, line), but of course this doesn't
follow proper grammar.

I think you are right, this cannot be done without such a template. It
brings back access to the eponymous nested template, interesting. I
think we should add it.


OK, great :-)


Re: Instantiate!(Template, args) in Phobos?

2016-04-22 Thread Nick Treleaven via Digitalmars-d-learn

On 21/04/2016 18:03, Steven Schveighoffer wrote:

This doesn't work?

alias staticEx(string msg, string file = __FILE__, size_t line =
__LINE__) = staticEx!(Exception, msg).staticEx!(file, line);


No, nor using the module dot prefix `= .staticEx!(...).staticEx` either:

staticex.d(3): Error: template identifier 'staticEx' is not a member of 
template 'staticex.staticEx!(Exception, "Look ma, @nogc 
exception!").staticEx(string file = __FILE__, uint line = __LINE__)()'
staticex.d(20): Error: template instance staticex.staticEx!("Look ma, 
@nogc exception!", "staticex.d", 20u) error instantiating



I would think something with AliasSeq could come in handy, it's the way
to alias a compile-time list.


Not sure how that would help.


Instantiate!(Template, args) in Phobos?

2016-04-21 Thread Nick Treleaven via Digitalmars-d-learn

Hi,
There doesn't seem to be something like this in Phobos:

alias Instantiate(alias Template, T...) = Template!T;

Here's an example of why I need it:

alias staticEx(string msg, string file = __FILE__, size_t line = 
__LINE__) =

Instantiate!(.staticEx!(Exception, msg), file, line);

template staticEx(T:Throwable, args...)
{
auto staticEx(string file = __FILE__, size_t line = __LINE__)()
...

Full code:
http://dpaste.dzfl.pl/810e55b1acd76

I found std.meta.ApplyLeft but it doesn't seem to work here. I've 
needed this before and ended up doing a workaround with a 
template block and temporary alias but it might be nice if Phobos 
had this. Or is there a simpler solution?


Re: @nogc inconsistent for array comparison depending on mutability of elements

2016-04-08 Thread Nick Treleaven via Digitalmars-d-learn

On Friday, 8 April 2016 at 10:11:43 UTC, Rene Zwanenburg wrote:

On Friday, 8 April 2016 at 09:56:41 UTC, Nick Treleaven wrote:
If the comparison with b shouldn't be allowed, I suggest we 
add opEquals to std.range.only. This removes a need to import 
std.algorithm.equal and reduces bracket nesting:


assert(b == only(1, 2));


equal[1] can compare ranges of different types.


opEquals would too. Not sure what you're saying. It wouldn't 
replace equal, only equal(only()). Pun intended.



It's a bit less clear than the original code though.

b.equal(only(1, 2));


I'd argue the opposite.



[1] http://dlang.org/phobos/std_algorithm_comparison.html#.equal





Re: @nogc inconsistent for array comparison depending on mutability of elements

2016-04-08 Thread Nick Treleaven via Digitalmars-d-learn

On Friday, 8 April 2016 at 03:14:40 UTC, Xinok wrote:

On Friday, 8 April 2016 at 01:36:18 UTC, rcorre wrote:

@nogc unittest {
int[2] a = [1, 2];
assert(a == [1, 2]); // OK

immutable(int)[2] b = [1, 2];
assert(b == [1, 2]); // fail: array literal may cause 
allocation

}

Is there any logic behind allowing the comparison with `a` but 
not `b`, or is this a compiler bug?


Semantically, array literals are always allocated on the heap. 
In this case, the optimizer can obviously place the array on 
the stack or even make it static/global.


So @nogc is enforced by the optimizer?

If the comparison with b shouldn't be allowed, I suggest we add 
opEquals to std.range.only. This removes a need to import 
std.algorithm.equal and reduces bracket nesting:


assert(b == only(1, 2));


Disallow destroy(structPtr)?

2015-02-20 Thread Nick Treleaven via Digitalmars-d-learn

Hi,

The following code is supposed to destroy the struct instance:

import std.stdio;
struct S{
~this(){destruct.writeln;}
}
auto p = new S;
destroy(p);
end.writeln;

It works correctly if I use destroy(*p), but the above code could 
perhaps be statically rejected by object.destroy to help prevent bugs. 
Currently, the pointer p is set to null without calling the destructor 
(with recent dmd the destructor is called, but only after end is printed).


Here is the destroy overload:

void destroy(T)(ref T obj)
if (!is(T == struct)  !is(T == interface)  !is(T == class)  
!_isStaticArray!T)

{
obj = T.init;
}


Problem building dmd d_do_test tool - missing link operand

2014-09-27 Thread Nick Treleaven via Digitalmars-d-learn

Hi,
I used to run the ddoc tests with no problem, but for the last month or 
so I ran into problems building the d_do_test tool from latest Git dmd. 
(As I didn't need the latest dmd at the time, I just used an older one 
for a while).


Maybe I'm doing something wrong with my build setup for 
dmd/druntime/phobos, or maybe it's something else. Here's the output:


# in dmd/test
$ make DMD=../src/dmd.exe QUIET=''
Building d_do_test tool
OS: win32
../src/dmd.exe -m32 -unittest -run d_do_test.d -unittest
/usr/bin/link: missing operand after `d_do_test,,nul,user32+kernel32/noi;'
Try `/usr/bin/link --help' for more information.
DMD v2.067 DEBUG
--- errorlevel 1
make: *** [test_results/d_do_test.exe] Error 1


If I comment out the d_do_test unittest line in dmd/test/Makefile:

$ make DMD=../src/dmd.exe QUIET=''
Building d_do_test tool
OS: win32
#../src/dmd.exe -m32 -unittest -run d_do_test.d -unittest
../src/dmd.exe -m32 -odtest_results -oftest_results\\d_do_test.exe 
d_do_test.d
/usr/bin/link: missing operand after 
`test_results\\d_do_test,test_results\\d_do_test.exe,nul,user32+kernel32/noi;'

Try `/usr/bin/link --help' for more information.
DMD v2.067 DEBUG
--- errorlevel 1
make: *** [test_results/d_do_test.exe] Error 1


Any ideas?


Re: Problem building dmd d_do_test tool - missing link operand

2014-09-27 Thread Nick Treleaven via Digitalmars-d-learn

On 27/09/2014 12:59, Nick Treleaven wrote:

# in dmd/test
$ make DMD=../src/dmd.exe QUIET=''
Building d_do_test tool
OS: win32
../src/dmd.exe -m32 -unittest -run d_do_test.d -unittest
/usr/bin/link: missing operand after `d_do_test,,nul,user32+kernel32/noi;'
Try `/usr/bin/link --help' for more information.


Found the problem - I'd accidentally commented out this line from sc.ini:

LINKCMD=C:\D\dm\bin\link.exe



Re: ddoc and CODE_HIGHLIGHT macro

2014-07-27 Thread Nick Treleaven via Digitalmars-d-learn

On 27/07/2014 09:44, Alix Pexton wrote:

On 26/07/2014 4:31 PM, Nick Treleaven wrote:

Hi,
Ddoc doesn't seem to expand a macro near top of
http://dlang.org/hash-map.html:

// The $(CODE_HIGHLIGHT KeyType) is string

Which is weird because it expands it for 'remove' on this line not far
below it:

b.remove(hello);

Maybe a bug in dmd?


This is because the macro is used within a comment in a code section
(between lines of hyphens). Macros are normally expanded within code
sections, but inside comments they get ignored.

I filed an enhancement request.

https://issues.dlang.org/show_bug.cgi?id=13211


OK, great.


Also, I build some dlang.org docs individually and CODE_HIGHLIGHT is
inserting a line break in the html. I think this is because the macro
has an empty line after it:

CODE_HIGHLIGHT=$(B $(I $0))

MDASH=nobr#x200A;mdash;#x200A;/nobr

I can't tell from git blame when it was introduced, the website html
doesn't show the line break. Is there a workaround, or just remove the
empty line?


I've reproduced this, it seems it is related to the platform of the
file, ie a macro with a blank line after it declared in a file with
windows line endings (CR; + LF;) will have a line break on the end but
one in file with single character line breaks won't.

I filed that one as a bug.

https://issues.dlang.org/show_bug.cgi?id=13212


Interesting, so assuming the site docs were generated on Linux that's 
why they are OK. Git on Windows checks out the file as CRLF automagically.




ddoc and CODE_HIGHLIGHT macro

2014-07-26 Thread Nick Treleaven via Digitalmars-d-learn

Hi,
Ddoc doesn't seem to expand a macro near top of 
http://dlang.org/hash-map.html:


// The $(CODE_HIGHLIGHT KeyType) is string

Which is weird because it expands it for 'remove' on this line not far 
below it:


b.remove(hello);

Maybe a bug in dmd?

Also, I build some dlang.org docs individually and CODE_HIGHLIGHT is 
inserting a line break in the html. I think this is because the macro 
has an empty line after it:


CODE_HIGHLIGHT=$(B $(I $0))

MDASH=nobr#x200A;mdash;#x200A;/nobr

I can't tell from git blame when it was introduced, the website html 
doesn't show the line break. Is there a workaround, or just remove the 
empty line?