Re: Static if on release build
On Friday, 20 October 2017 at 02:36:37 UTC, Fra Mecca wrote:
I can't find any documentation regarding conditional
compilation in release and debug mode.
I have read the page regarding the topicon dlang.org but adding
the snippet below makes no difference when compiling with dub
-b release
{
version(full) {
//do something
} else {
//do something else
}
How can I produce a release version with different parameters
from debug using dub and static if's?
The most close compile condition is
version(assert)
{
// build for testing
}
else
{
// build for release
}
see https://dlang.org/spec/version.html#predefined-versions:
"assertChecks are being emitted for AssertExpressions"
And at the same time
https://dlang.org/dmd-linux.html#switch-release
"compile release version, which means not emitting run-time
checks for contracts and asserts. Array bounds checking is not
done for system and trusted functions, and assertion failures are
undefined behaviour."
Re: Release D v2.076.1
On Thursday, 12 October 2017 at 14:20:42 UTC, b4s1L3 wrote: On Wednesday, 11 October 2017 at 13:38:10 UTC, b4s1L3 wrote: On Wednesday, 11 October 2017 at 13:08:38 UTC, Petar Kirov [ZombineDev] wrote: On Wednesday, 11 October 2017 at 10:20:01 UTC, b4s1L3 wrote: On Monday, 9 October 2017 at 19:44:24 UTC, Martin Nowak wrote: Glad to announce D v2.076.1. http://dlang.org/download.html This point release fixes a few issues over v2.076.1, see the changelog for more details. http://dlang.org/changelog/v2.076.1.html - -Martin I didn't test the beta and missed this regression discovered by a CRON at TravisCI: https://issues.dlang.org/show_bug.cgi?id=17893 Sound like we need more test coverage on the Project Tester (https://github.com/dlang/ci/blob/master/pipeline.groovy#L319). The regression was discovered in iz, which was at least another time "victim" of a regression (almost day for day 1 year ago). https://github.com/BBasile/iz. This time it is trivial to overcome. It happens in a contract so checking for a version number does the job and the release version is not affected at all. I can still add dmd beta as D Compiler in the CI. I think that iz occasionally breaks because it covers many programming style, not because of its "edginess", which means that's its probably not worth adding it to the Project tester. Also i'd like to say that the policy that is that regression fixes are commited on stable and that the fact that they only come to master in a "sync operation" is a problem. In the travis yaml we have to test dmd, dmd beta (stable, not yet released) and finally dmd master (current working tree). The policy should be changed so that regression fixes are commited to both master and stable, allowing to decrease the CI complexity. The problem is mainly that testing a project with dmd beta is pointless. It's only useful 1 or 2 weeks before a release, which happens , let's say, 4 times per years, leading to a waste of computing resources at the CI service. With reg fixes put in master at the same time that in stable, testing 3 versions of the DMD compiler would not be necessary anymore, i think.
Re: Release D v2.076.1
On Wednesday, 11 October 2017 at 13:38:10 UTC, b4s1L3 wrote: On Wednesday, 11 October 2017 at 13:08:38 UTC, Petar Kirov [ZombineDev] wrote: On Wednesday, 11 October 2017 at 10:20:01 UTC, b4s1L3 wrote: On Monday, 9 October 2017 at 19:44:24 UTC, Martin Nowak wrote: Glad to announce D v2.076.1. http://dlang.org/download.html This point release fixes a few issues over v2.076.1, see the changelog for more details. http://dlang.org/changelog/v2.076.1.html - -Martin I didn't test the beta and missed this regression discovered by a CRON at TravisCI: https://issues.dlang.org/show_bug.cgi?id=17893 Sound like we need more test coverage on the Project Tester (https://github.com/dlang/ci/blob/master/pipeline.groovy#L319). The regression was discovered in iz, which was at least another time "victim" of a regression (almost day for day 1 year ago). https://github.com/BBasile/iz. This time it is trivial to overcome. It happens in a contract so checking for a version number does the job and the release version is not affected at all. I can still add dmd beta as D Compiler in the CI. I think that iz occasionally breaks because it covers many programming style, not because of its "edginess", which means that's its probably not worth adding it to the Project tester.
Re: Release D v2.076.1
On Wednesday, 11 October 2017 at 13:08:38 UTC, Petar Kirov [ZombineDev] wrote: On Wednesday, 11 October 2017 at 10:20:01 UTC, b4s1L3 wrote: On Monday, 9 October 2017 at 19:44:24 UTC, Martin Nowak wrote: Glad to announce D v2.076.1. http://dlang.org/download.html This point release fixes a few issues over v2.076.1, see the changelog for more details. http://dlang.org/changelog/v2.076.1.html - -Martin I didn't test the beta and missed this regression discovered by a CRON at TravisCI: https://issues.dlang.org/show_bug.cgi?id=17893 Sound like we need more test coverage on the Project Tester (https://github.com/dlang/ci/blob/master/pipeline.groovy#L319). The regression was discovered in iz, which was at least another time "victim" of a regression (almost day for day 1 year ago). https://github.com/BBasile/iz. This time it is trivial to overcome. It happens in a contract so checking for a version number does the job and the release version is not affected at all.
Re: Release D v2.076.1
On Monday, 9 October 2017 at 19:44:24 UTC, Martin Nowak wrote: Glad to announce D v2.076.1. http://dlang.org/download.html This point release fixes a few issues over v2.076.1, see the changelog for more details. http://dlang.org/changelog/v2.076.1.html - -Martin I didn't test the beta and missed this regression discovered by a CRON at TravisCI: https://issues.dlang.org/show_bug.cgi?id=17893
ASYNCREAD in dmd driver (mars.d)
I've just noticed some dead code (at least since self-hosting started, because otherwise git blame is not useful) in dmd's driver. All the *static if* blocks that test the value of ASYNCREAD are dead. Should they be removed or something ? https://github.com/dlang/dmd/blame/32bb4ed7526b2bd622c0576734e5a6a6bd3c8278/src/ddmd/mars.d#L1361 although That's not much code.
Re: Add a precompiled c++ obj file to dub
On Sunday, 8 October 2017 at 04:03:27 UTC, user1234 wrote: On Sunday, 8 October 2017 at 02:58:36 UTC, Fra Mecca wrote: On Saturday, 7 October 2017 at 23:54:50 UTC, user1234 wrote: On Saturday, 7 October 2017 at 19:56:52 UTC, Fra Mecca wrote: Hi all, I am writing a backend that is partly Vibe.d and partly clucene in c++. I have some object files written in c++ and compiled with g++ that are not considered by dub during the linking phase and throws `function undefined error ` every time. Is there a way to tell dub to let dmd handle that .o files? Yes, add this to your JSON: "sourceFiles-linux-x86_64" : [ "somepath/yourobject.o" ], I tried the sourceFiles approach, it failed and I could reproduce that in some days. At the end I added them as linking options (lflags) but it is kinda odd that it works given that everything is supplied to dmd as -Lobj.o Huh, i'm surprised but well, if it works for you. My advice was based on https://github.com/BBasile/dbeaengine/blob/master/dub.json (object file is passed to dmd) which works, I often use it. Yeah that's becuz passing *.o / *.obj files to the linker or to dmd is the same buisness under the hood. The problem with this DUB project is that it will only compiles with DMD. Maybe the OP used another compiler. other compilers may not support the shortcut here: https://github.com/dlang/dmd/blob/master/src/ddmd/mars.d#L626
Re: Finding class template instantiations via runtime reflection (for openmethods)
On Thursday, 21 September 2017 at 20:32:38 UTC, Jean-Louis Leroy
wrote:
It did not take long! Someone tried to create templatized open
methods and it didn't work right of the box. I expected that,
but in fact there may be a bit of hope. You cannot have virtual
function templates in C++ or in D because the layout of the
vtables have to be known at compile time - but openmethods
creates its method tables at runtime so maybe it can be made to
work.
I stumbled upon a problem very quickly: it seems that classes
that come from class template instantiations are not registered
in ModuleInfo - see below,
[...]
Neither 'Bar!int' nor 'BarInt' appear in 'localClasses'.
Ideas?
Yeah. You can setup a custom registry that maps names to their
TypeInfo_Class.
I do something similar in iz (though the real point in iz is a
GC-free factory but the principle of the registry would be the
the same for you)
Example:
---
/+ dub.sdl:
name "dub_script"
dependency "iz" version="0.6.0"
+/
module dub_script;
import iz.memory, std.stdio;
class Foo(T){this(){writeln("fooDeInt");}}
TypeInfo_Class[string] registry; // you need that...
static this()
{
registerFactoryClass!(Foo!int)(registry); // ...and that,
maybe with another name
}
void main()
{
auto fooDeInt = iz.memory.factory(registry, "Foo!int");
destruct(cast(Object) fooDeInt);
}
---
Re: how to build project with locally compiled phobos
On Saturday, 23 September 2017 at 11:58:40 UTC, Mengu wrote: hi all i've successfully compiled phobos master with gmake on freebsd. (make fails, i've no clue at all as to why) how do i compile my project now against my local phobos with dub? with plain dmd? i tried (in dub.sdl): - full path to new libphobos.so with -defaultlib to dflags - full path to new libphobos.so to lflags i checked with ldd and saw the original libphobos.so was used. my current workaround is copying mine to /usr/lib. thanks in advanced. Hello, what you want to do is certainly possible but... I'd rather build a full custom dmd+runtime+phobos with its own sc.conf file Why ? - Easier to invoke dub w/ the option --compiler=path. - The custom DMD will alsways use the right phobos (when not using dub).
Re: How to check if string is available at compile time
On Thursday, 21 September 2017 at 11:42:36 UTC, David Bennett wrote: Hi Guys, Is there an easy way to check if the value of string passed to a template is available at compile time? Yeah , sure and I have such a template in my library: https://github.com/BBasile/iz/blob/master/import/iz/types.d#L627 see just above too, the template "isCompileTimeValue"
Re: Specifying @nogc on structs seems to have no effect
On Wednesday, 20 September 2017 at 16:13:44 UTC, Craig Black wrote: On Wednesday, 20 September 2017 at 02:43:44 UTC, B4s1L3 wrote: It's another way of doing things. It's less strict than checking all the functions. note: the script can be run directly by passing the file to DUB (single file package). Wow! Yeah that seems like almost exactly what I want. Sorry what is iz? Thank you! -Craig It's a D user library: https://github.com/BBasile/iz. I forgot to say but the @NoGc data annotation relies on construct(). Neither `new` not `std.experimental.allocator.make` are usable, because `AddGcRoot()`, when needed, is called inside `construct` (which is, if you remove the ability to handle the annotation, similar to make).
Re: What the hell is wrong with D?
On Wednesday, 20 September 2017 at 02:16:16 UTC, EntangledQuanta wrote: Your an idiot, I know about how operator precedence works far more than you do. Wanna bet? how much? Your house? your wife? Your life? It's about doing things correctly, you seem to fail to understand, not your fault, can't expect a turd to understand logic. You should swallow your ego a bit. In first place you've made an error. Just recognize this error, it's not so serious finally. You are discrediting yourself for nothing.
Re: Specifying @nogc on structs seems to have no effect
On Tuesday, 19 September 2017 at 13:11:03 UTC, Craig Black wrote:
I've recently tried coding in D again after some years. One of
my earlier concerns was the ability to code without the GC,
which seemed difficult to pull off. To be clear, I want my
programs to be garbage collected, but I want to use the GC
sparingly so that the mark and sweep collections will be fast.
So I want guarantees that certain sections of code and certain
structs will not require the GC in any way.
I realize that you can allocate on the non-GC heap using malloc
and free and emplace, but I find it troubling that you still
need to tell the GC to scan your allocation. What I would like
is, for example, to be able to write a @nogc templated struct
that guarantees that none of its members require GC scanning.
Thus:
@nogc struct Array(T)
{
...
}
class GarbageCollectedClass
{
}
void main()
{
Array!int intArray; // fine
}
I've implemented data annotation in iz, if you want to take a
look.
It's quite near from what you descibed in a more recent answer:
/+ dub.sdl:
name "dub_script"
dependency "iz" version="0.6.0"
+/
module dub_script;
import iz.memory;
// defines a class that has a member
// which is usually handled by the GC
class Foo {void* looks_gc_managed;}
// defines a class and marks member as nogc-"trusted"
class Bar {@NoGc Foo foo;}
// defines a class without annotation
class Baz {Foo foo;}
// verified statically
static assert(!MustAddGcRange!Bar);
static assert( MustAddGcRange!Baz);
void main(string[] args)
{
Foo foo = construct!Foo;
destruct(foo);
}
It's another way of doing things. It's less strict than checking
all the functions.
note: the script can be run directly by passing the file to DUB
(single file package).
Re: Editor recommendations for new users.
On Wednesday, 30 August 2017 at 11:28:35 UTC, Anonymouse wrote: Dutyl[3] seems much more interesting but also more daunting, considering that my vim knowledge so far largely consists of :wq and :q!. Yeah, haha, that's the basic command you need to know when the time comes to rebase a git branch in console mode.
Update the ArchWiki page about D
See https://wiki.archlinux.org/index.php/D where is stated that "The main difference is that the dmd's back end is not FOSS (licensed from Symantec), while the others compilers are completely FOSS." Time to update this.
