repo https://github.com/timotheecour/D_vs_nim/
with the goal: up to date and objective comparison of features
between D and nim, and 1:1 map of features, tools, idioms and
libraries to help D users learn nim and vice versa.
On Thursday, 26 January 2017 at 07:38:50 UTC, Jacob Carlborg
wrote:
On 2017-01-26 04:43, Timothee Cour via Digitalmars-d wrote:
Can we do this is 1 step?
```
rdmd -offoo.o -c foo.d
g++ -o foo foo.o -pie -Wl,--export-dynamic
```
Ideally something like this would be great:
```
rdmd -offoo -extr
On Wednesday, 7 March 2018 at 22:28:26 UTC, ketmar wrote:
H. S. Teoh wrote:
I've pestered Brad about it before, but the real trouble is
the Mailman
software. If you feel motivated enough, pestering the
upstream Mailman
authors about it might actually get us closer to fixing this
problem, as
On Tuesday, 27 February 2018 at 05:28:41 UTC, Timothee Cour wrote:
https://github.com/llvm-mirror/lldb/pull/3
+
https://github.com/timotheecour/dtools/blob/master/dtools/lldbdplugin.d
on OSX, it works great except when encountering large symbols
which
cause segfault when GC does a collection
On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote:
As promised [1], I have started setting up a DIP to improve
tuple ergonomics in D:
https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md
This DIP aims to make code like the following valid D:
...
Would this DIP allow
On Friday, 16 February 2018 at 00:42:02 UTC, Timothee Cour wrote:
is there a way to get typeid of extern(C++) classes (eg for
ones in
dmd/astbase.d but not limited to that) ?
as a workaround, could the compiler insert (eg, depending on a
version(insert_typeid)) a virtual method in each extern
On Tuesday, 13 February 2018 at 04:16:22 UTC, Nick Sabalausky
(Abscissa) wrote:
On 02/09/2018 07:11 AM, Kagamin wrote:
On Friday, 9 February 2018 at 11:16:01 UTC, Nick Sabalausky
(Abscissa) wrote:
On 02/09/2018 05:31 AM, Kagamin wrote:
version(none)q{ FOO }; is likely to work for most stuff to
On Thursday, 11 January 2018 at 15:37:20 UTC, Seb wrote:
On Wednesday, 10 January 2018 at 15:07:40 UTC, Luís Marques
It's not well documented, but you can always overwrite DUB with
DFLAGS:
DFLAGS="-dw" dub
It will give you a warning though, but it's justified as you
might have `DFLAGS` set
On Monday, 12 February 2018 at 01:27:19 UTC, Walter Bright wrote:
Know what is a heavyweight problem worth our while? Having dmd
be able to directly read C .h files, so the poor user does not
have to manually translate them.
read directly C++ header files instead of C .h files is what we
shou
On Monday, 12 February 2018 at 01:39:31 UTC, Walter Bright wrote:
Easy:
mixin template comment(string s) { }
mixin comment!q"EOS
This is a multi-line
heredoc comment allowing
/+ documented unittests containing nesting comments +/
and weird urls like
https://gcc.gnu.org/
On Monday, 5 February 2018 at 19:32:37 UTC, Timothee Cour wrote:
just filed https://issues.dlang.org/show_bug.cgi?id=18377:
@wilzbach
It probably makes sense to have a look at how other languages
are dealing with this. Seems to be a common problem
some links:
*
https://www.ncover.com/suppor
On Tuesday, 6 February 2018 at 21:13:50 UTC, timotheecour wrote:
On Tuesday, 6 February 2018 at 20:39:09 UTC, Timothee Cour
wrote:
should we force force casting through `void*` for extern(C++)
classes ?
i.e. `cast(Derived) cast(void*) base_instance;`
currently, `cast(A) unrelad_cpp_instance
On Wednesday, 22 October 2008 at 18:43:15 UTC, Denis Koroskin
wrote:
On Wed, 22 Oct 2008 22:39:10 +0400, bearophile
wrote:
[...]
You can use the following short-cut to avoid double casting:
if (auto foo = cast(Foo)obj) {
...
} else if (auto bar = cast(Bar)bar) {
...
} else {
..
On Tuesday, 6 February 2018 at 20:39:09 UTC, Timothee Cour wrote:
should we force force casting through `void*` for extern(C++)
classes ?
i.e. `cast(Derived) cast(void*) base_instance;`
currently, `cast(A) unrelad_cpp_instance` happily compiles but
shouldn't, it's very error prone even though
On Sunday, 19 November 2017 at 04:44:24 UTC, Meta wrote:
On Friday, 24 March 2017 at 16:34:46 UTC, Martin Nowak wrote:
On Tuesday, 21 March 2017 at 20:16:00 UTC, Atila Neves wrote:
git rebase master my_branch
git checkout master
git merge --no-ff my_branch
Yes, that's about what we aim for, r
On Saturday, 27 January 2018 at 10:38:46 UTC, Kagamin wrote:
dmd
see also this horrendous stacktrace when calling getopt with a
bad argument:
full stacktrace:
https://gist.github.com/timotheecour/d6b623bd3d223f5d958cd86adffd7807
just 1 line of this stacktrace:
```
28 dscanner
On Friday, 26 January 2018 at 18:40:23 UTC, Seb wrote:
Want to know what it prints? Run the file!
Spoiler: it's similar to new the AST feature at run.dlang.io:
prettyPrint produces valid D code except for template
instantiations:
```
writeln!int
{
@safe void writeln(int _param_0)
On Saturday, 27 January 2018 at 01:10:35 UTC, timotheecour wrote:
On Saturday, 27 January 2018 at 00:47:01 UTC, timotheecour
the bug is that homebrew dmd installs dmd.conf in
/Users/timothee/homebrew/etc/dmd.conf; findDMDConfig should
instead look for dmd.conf by calling `dmd -v|grep 'C
On Saturday, 27 January 2018 at 00:47:01 UTC, timotheecour wrote:
on OSX:
chmod u+x main.d
./main.d
WARNING: A deprecated branch based version specification is
used for the dependency dmd. Please use numbered versions
instead. Also note that you can still use the
dub.selections.json file to
On Saturday, 27 January 2018 at 01:36:17 UTC, Seb wrote:
On Saturday, 27 January 2018 at 01:25:18 UTC, timotheecour
Agreed, but prettyPrint:
https://github.com/dlang/dmd/blob/master/src/dmd/frontend.d#L275
is just a nice wrapper around the existing PrettyPrintVisitor:
https://github.com
On Friday, 26 January 2018 at 08:44:26 UTC, Seb wrote:
What is the benefit of using link-time renaming (a linker
specific feature) instead of directly renaming the symbol in
the compiler? We could be quite radical and hash all symbols >
a certain threshold. As long as we have a hash function wi
On Friday, 26 January 2018 at 18:40:23 UTC, Seb wrote:
In case someone wants to play with DMD as a library, it got a
lot easier as of today.
Here's an example:
```
#!/usr/bin/env dub
/+dub.sdl:
dependency "dmd" version="~master"
+/
void main()
{
import dmd.frontend;
import std.algorithm
this compiles, but equivalent in C++ (const int vs int) would
give a
compile error (error: redefinition of 'fun'); what's the
rationale for
allowing these overloads?
```
void fun(int src){ writeln2(); }
void fun(immutable int src){ writeln2(); }
void fun(const int src){ writeln2(); }
void main
On Sunday, 11 June 2017 at 07:09:33 UTC, timotheecour wrote:
On Sunday, 11 June 2017 at 05:21:23 UTC, Timothee Cour wrote:
[...]
NOTE: this is on linux, and the above simple case doesn't
reproduce
the error, but my test case is similar albeit from a larger
program
that's hard
On Sunday, 11 June 2017 at 05:21:23 UTC, Timothee Cour wrote:
```
NOTE: this is on linux, and the above simple case doesn't
reproduce
the error, but my test case is similar albeit from a larger
program
that's hard to reduce.
the code that crashes is in druntime:
/**
* Check for module coll
On Wednesday, 13 November 2013 at 13:34:37 UTC, Jacob Carlborg
wrote:
On 2013-11-13 13:20, Timothee Cour wrote:
alas, no, I posted on exactly this some times ago:
glob is non-recursive in D:
http://forum.dlang.org/post/mailman.2367.1382320537.1719.digitalmars-d-le...@puremagic.com
Hmm, right,
On Wednesday, 15 February 2017 at 20:21:45 UTC, Nick Treleaven
wrote:
On Wednesday, 15 February 2017 at 20:09:46 UTC, Timothee Cour
wrote:
This thread completely diverged from the original post, which
was propsing `::` instead of `from!`:
```
void fun(T)(std.stdio::File input, T value) if
(st
On Sunday, 15 May 2016 at 14:08:57 UTC, Joseph Rushton Wakeling
wrote:
(2) It's probably more idiomatic to use `void[]` for buffers of
binary data, although I imagine you may have some reasons for
using `ubyte[]` ... ?
curious about this. https://dlang.org/phobos/std_outbuffer.html
defines:
On Monday, 30 November 2015 at 14:55:53 UTC, yawniek wrote:
would anyone be interested in doing the work for adding D /
vibe.d to
https://github.com/grpc/grpc ?
we currently lack the manpower but would be able to sponsor it
(or parts, depending on the effort needed).
grpc is probably going
On Friday, 17 August 2012 at 13:10:52 UTC, Timon Gehr wrote:
On 08/17/2012 02:17 PM, Marco Leise wrote:
Am Tue, 14 Aug 2012 12:15:35 +0200
schrieb Don Clugston:
Seriously, if you are finding ANY error messages for things
which are
not real errors, that is a bug.
What about errors that are a
On Sunday, 12 April 2015 at 04:08:47 UTC, Andrei Alexandrescu
wrote:
On 4/11/15 12:25 AM, Vladimir Panteleev wrote:
[...]
The actual command line generated by is:
../dmd/src/dmd -conf= -I../druntime/import -w -dip25 -m64 -g
-debug -main -unittest generated/osx/debug/64/libphobos2.a
-defau
On Thursday, 11 July 2013 at 03:29:13 UTC, Kenji Hara wrote:
On Thursday, 11 July 2013 at 03:10:38 UTC, timotheecour wrote:
On Thursday, 11 July 2013 at 02:17:13 UTC, Timothee Cour wrote:
[snip]
can we add this to std.traits?
it allows (among other things) to write unittests for CTFE,
etc
On Thursday, 11 July 2013 at 02:17:13 UTC, Timothee Cour wrote:
template isCallableCTFE(alias fun){
template isCallableCTFE_aux(alias T){
enum isCallableCTFE_aux=T;
}
enum
isCallableCTFE=__traits(compiles,isCallableCTFE_aux!(fun()));
}
template isCallableCTFE2(fun...){
enum isCallableCTFE2=tru
On Saturday, 8 June 2013 at 02:21:01 UTC, Timothee Cour wrote:
not to mention its much harder to implement in language,
whereas its
trivial in the library. Also, it makes instrumentation easier,
if one wants
to add a callback/logging/breakpoint for a particular cast
operation. Seems
much harde
I'd like public alias x this to reset protection attribute on a
(private) member x:
b.d:
struct B(T){
private T x;// would normally prevent alias this from doing
anything useful
public alias x this;
}
a.d:
void main(){
auto a=B!int();
a++;//should do a.x++; semantic change: ev
looks like no one read the DIP till the last section :)
I proposed there 2 ways to support both current flags and new
flags, without possible confusion nor code breakage.
2a): dmd -flagstyle=new -of=blah ... (+ other stuff/deprecations
taken into account)
2b): dmd2 (reminds of D2, ldc2, ldmd2
On Tuesday, 14 May 2013 at 03:20:59 UTC, Kenji Hara wrote:
Currently conditional compilation would stop IFTI.
template foo(T)
{
static if (is(T == int))
void foo(T) {}
}
void main()
{
foo(1); // shouldn't work
}
Same as above, DIP40 should prevent following case.
template foo
The link:
http://wiki.dlang.org/DIP40
The paper links mentioned in the abstract are given in this DIP.
OK, First remark on the way the DIP is presented. You start
right away with example which make it hard to understand o
general big picture.
I've clarified differences with the rejected DIP36 in the
abstract and added more context.
Second, ^ is not unused in D and the DIP introduce an ambigui
On Saturday, 30 March 2013 at 18:05:27 UTC, bearophile wrote:
Zach the Mystic:
{c, $_} = tup;
{c, @} = tup;
{c, @_} = tup;
{c, $$} = tup;
{c, {}} = tup;
{c, {_}} = tup;
{c, $~} = tup;
{c, @~= tup;
etc.
{c, ?} = tup;
Right, I was forgetting that.
Or this if you want to keep the single "?" fo
BTW, why was the constructor added to Proxy and the "dummy"
argument?
because I wanted to simplify syntax from 'auto
ret2=named!fun.z(3).x(4).call();' to 'auto
ret2=named!fun.z(3).x(4)();'
In doing that, I was having CT errors without it due to ambiguity
between default unnamed constructor and o
I updated
https://github.com/timotheecour/dtools/blob/master/dtools/util/functional.d
to incorporate Jacob Carlborg's idea (thanks for the
working+clean code! let me know if attribution is ok)
auto a=named!fun.z(3).x(4).call();
and then simplified it a bit to:
auto a=named!fun.z(3
revive.
More later.
see:
https://github.com/timotheecour/dtools/blob/master/dtools/util/functional.d
nothing to install, just call:
rdmd --main -unittest dtools/util/functional.d
auto s=callNamed!(fun,`x,y`)(10,20);
given a function:
auto fun(int x,int y=2,double z=z_val, string z2="
it would have to be agreed upon
whether assertions should be used or whether RangeError should
be used (or
that using either was valid, though that's a bad idea IMHO).
if we force range code to throw RangeError, wouldn't that prevent
optimization in release mode? If so, that's no good. Also,
testing that a conformant range throws a RangeError from
popFront when it's empty (as Nick was suggesting) would not be
correct at this point
ok what about the following: should work regardless it's
RangeError or an assert(0) in th eparticular implementation of a
range.
bool isThrown(
[reposted here from D.learn on Jonathan M Davis' request]
Can we replace phobos' and tools' Makefile with D with following
advantages:
* no more 3 distinct files (posix.mak,win32.mak,win64.mak),
instead use version() to maximize code reuse.
* less verbosity / bugs / forward compatibility issues
when I click on source next to abs, it goes to
"http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-Num.html#abs";
which is not a very precise location, and it's not clear the doc
is in sync with code shown
In order to link to the local file system, the distribution
needs to co
enhancement request:
in the ddoc documentation generation, hyperlinks should appear:
bool equal(Range1, Range2)(Range1 r1, Range2 r2);
=> should contain a hyperlink from 'equal' to source code
defining that function.
The hyperlink target should be customizable, either a url (eg:
github, making
right now std.range.indexed takes a randomAccessRange of elements
and a inputRange of indexes.
Why not also support lazy inputs, with sorted integral indexes ?
That's make it possible to, say, get every 10 lines of a file,
lazily.
right now:
struct Indexed(Source, Indices) if (isRandomAccessR
spontaneously... I love it!
is there any other spontaneous feedback?
how about a predicate isSentinel instead of a fixed sentinel
value?
That'd allow more flexibility such as more than one sentinel
value.
Not usable in a switch/case statement.
why is that needed?
On Thursday, 28 February 2013 at 01:56:33 UTC, Walter Bright
wrote:
On 2/27/2013 5:53 PM, Zach the Mystic wrote:
What if more than one
value can end the range, EOF, '\0'?
I have never seen a need for that.
how about a predicate isSentinel instead of a fixed sentinel
value?
That'd allow more
Use dtoh to initiate and conduct an incremental port of the
compiler.
How about going the other way around?
Using swig to make existing dmd C++ code available to D, so we
can advance with a mix of D and C++ code until all of C++ code is
converted.
I was able to successfully convert large code
On Wednesday, 27 February 2013 at 19:55:41 UTC, Jacob Carlborg
wrote:
On 2013-02-27 11:07, Andrei Alexandrescu wrote:
Good idea. Should be in bugzilla as an enh, although it'll
take a while
to get to that.
I wonder how good the implementation will be if one just pass
the line to rdmd and pr
I proposed this a few weeks ago, but nobody gave feedback. This
would enable it without worrying about special cases.
http://forum.dlang.org/thread/miqtvuufvlwgfzble...@forum.dlang.org
feature request: special optional argument (__FILE__, ...) AFTER
variadic template.
Please let me know what
I'd like to suggest a new feature to help discoverability : a
function in phobos that finds candidate function names given
input-output constraints (not just type constraints) that the
function should satisfy (and optionally, other constraints such
as type traits). That'll be valuable not only
There's current disagreement regarding the syntax &a.fun, as it
makes &a.fun be different from &(a.fun):
&a.fun : address of member function
&(a.fun) : address of return value of a.fun
This breaks the usual rules of scoping and makes the expression
&a.fun special. More complex cases can arise
actually, we can use
"T0[T.length]ret=void;"
instead of
"T0[T.length]ret;"
inside the definition of S. It doesn't make a difference for ldc
which optimizes it away, but it does for dmd (which is also about
10x slower than ldc).
Static arrays suffer from:
1) bad implementation that allocates on the heap when we do:
"int[3]=[1,2,3];"
2) lack of syntactic sugar to declare them on on the fly, eg when
we want to pass a static array to a function without declaring an
intermediate variable. See my proposal for "auto x=[1,
seems like my original post regarding __ARGS__ was completely
hijacked by the discussion on AST macros (however fruitful and
interesting). I agree macros would solve this issue while
providing a much more general solution, however, it's very
unclear when that would be implemented, surely not an
As of the proposal in itself, out parameter is known to be
confusing. They are here simply for C compat, and because D is
unable to return multiple values. Fixing that problem is
probably way then introducing something that promote out
parameter usage.
D can return tuples, and certainly its s
currently there's a limitation with logging using variadic
templates:
eg:
the following is not allowed because it's ambiguous:
void DEBUG(T...)(T a, string file=__FILE__) {...}
proposal:
create a new kind of optional argument that's uninstantiable by
user code, only by the compiler. We could u
One of the rare features I miss in C/C++ is stringification macro
using "#x":
---
#include ...
#define DEBUG(x) disp_val(#x,x)
template
void disp_val(const char*name, const T& x) {std::cout << name <<
"=" << x;}
int main(){
DEBUG(1+2); //will print 1+2=3 (and we can add line, file and
func in
I'd like to suggest the following feature that extends UFCS to
output arguments, hence the name Output-UFCS.
in short:
1) given a function "void fun(A a, ref B b);" (0 or more
arguments before b)
2) The proposal is to always allow the following expression:
"auto b=fun(a);" which the compil
I'm wondering whether it would make sense to do compiler
bootstrapping to speedup further development and bugfixing?
This is inspired by a recent comment from Andrei
(https://github.com/D-Programming-Language/dmd/pull/1489) ("I
think we're getting closer to the point we could and should do
so
Can't we simply use map, so as not to introduce new syntax?
import std.algorithm:map;
import std.array:array;
// some imports here
void main() {
//BigInt[] data1 = [5, 6, 9];
auto data1 = [5, 6, 9].map!(a=>BigInt(a)).array;
Ranged!(int,5,10)[] data2 = [5, 6, 9];
auto data2 = [5,
Indeed, having version logic has been requested many times before.
For example:
http://www.digitalmars.com/d/archives/digitalmars/D/learn/Can_I_do_an_or_in_a_version_block_33426.html
http://www.digitalmars.com/d/archives/digitalmars/D/11946.html
quote from those:
"Walter would reject it. He has s
Ideally,
struct S { int a; int b; }
void foo(int p, int q);
S s;
foo(s);
should work (setting aside for the moment that they are
different types). Unfortunately, the variety of function
calling ABIs makes this impractical.
So tuples in a language like D that must conform to external
Is the plan to deprecate comma operator for chaining expressions?
I would love to see more syntactic sugar to support tuples, and
comma operator would be the best fit for that purpose.
eg:
import std.typecons;
auto fun(){
return tuple(1,"abc");
//1) ideally, we should be able to wr
Hi, It seems these links are unavailable now:
http://xammy.xammy.homelinux.net/~xammy/utils_keywordargs.html
http://xammy.xammy.homelinux.net/~xammy/keywordargs.d
In the longer run, I'd like this mixinRT to be able to achieve
something like cling, the C++ interactive interpreter:
http://root.cern.ch/drupal/content/what-cling
http://llvm.org/devmtg/2010-11/Naumann-Cling.pdf
void myAssert(int line = __LINE__, string file = __FILE__,
Args...)(lazy bool condition, lazy Args args) {
Won't that create "template code bloat" ? Ie everytime myAssert
is used a new function is created.
There was if I remember some discussion regarding not passing
__LINE__,__FILE__ in ass
thanks for the quick answer! I filed bug report
http://d.puremagic.com/issues/show_bug.cgi?id=8584
Is there a "best practices" page on this site to use as reference
for those FAQ, that AFAIK are not in the docs:
* when to use class vs struct
(eg
http://stackoverflow.com/questions/11058906/struct-vs-class-for-writing-d-wrappers-around-foreign-languages)
* what's the standard signature for o
is that a bug? should i file a bug report?
---
import std.range;
struct A{
int x;
//bool opEquals(const A a) {return a.x==x;} //comiles when this
is used
//bool opEquals(const A a)const{return a.x==x;} //will not
compile
bool opEquals(A a)const{return a.x==x;} //will not comp
Thanks,
The trace code is in druntime/rt/trace.d. There you can see
that the ticks/sec is just set to the shown constant value for
anything but Windows, but RDTSC is used to read the processor
cycles. So the values are probably off by a factor of 300 to
1000.
So I'm still not sure how to co
great! Is there a way to run it on a project build outside of
visualD? I use a makefile instead of relying on visualD's build
system. When I open the profiler window and open trace.log
inside nothing is shown. Ideally all it should do is demangle
symbols and convert to a table, so I'm assumin
I'm not sure how to interpret trace.log from running dmd with
-profile (on osx at least).
I inserted a stopwatch inside main, which gave 35.8 seconds.
1) How to convert times in trace.log to seconds? Eg, how to get
35.8 seconds using the numbers below?
here's the first last line for times:
==
I just stumbled upon http://sublimetext.userecho.com/ which hosts
a forum (integrating ideas, discussions, questions, news, feature
requests etc) for a text/code editor (sublimetext, which seems
nice btw, and supports D :-) ). It is powered by userecho.
(disclaimer: I am NOT affiliated in any
unfortunately OSX uses an older version of gdb and doesn't
support either python scripting nor -tui; and the macports
version of gdb (ggdb) doesn't work, even on the simplest
segfaulting C program, see
http://stackoverflow.com/questions/6092766/gdb-7-segfaulting.
Anyways I still think lldb is
Is anybody planning to support the D programming language in lldb?
Currently gdb on osx doesn't support D (name mangling issues on
osx even though it works on linux), and anyways lldb offers much
more than gdb with interactive debugging via python scripting
among other niceties. The gdb patch
mixin Instantiate!(foo,int);
Thanks for the syntax tip!
You could use cp instead of dmd -H.
That won't produce the same output (eg large functions tend to be
stripped currently), but I guess the current behavior is
relatively useless so it's fine.
want you are after. Such a thing could ac
There's a current pull request to improve di file generation
(https://github.com/D-Programming-Language/dmd/pull/945); I'd
like to suggest further ideas.
As far as I understand, di interface files try to achieve these
conflicting goals:
1) speed up compilation by avoiding having to reparse lar
questions:
A) as I understand it, the new di generation will systematically
strip out the implementation of non-auto-return, non-templated
functions, is that correct?
B) since there are some important differences with the current di
files (in terms of inlining optimization, etc), will there
What is the recommended approach when we have no control over
classes A or B (cf from 3rd party) to convert A to B?
It seems UFCS doesn't work in that case.
Could you please provide an example code?
Thanks!
(apologies for cross-posting here, I feel this is a better place
to ask than in my original post where I only received 1 answer
that seemed in favor of this:
http://d.puremagic.com/issues/show_bug.cgi?id=8008 which was 2
months ago).
Please see to the original post above to see the proposal fo
I was writing my own template code wrapper until I saw the
excellent SWIG for D tool; currently, given a C++ template
(class/function) "A" and a set of instantiations in interface
file (eg T=double), SWIG seems to only output non-template
classes/functions with user-defined mangled names, eg A_dou
I was writing my own template code wrapper until I saw the
excellent SWIG for D tool; currently, given a C++ template
(class/function) "A" and a set of instantiations in interface
file (eg T=double), SWIG seems to only output non-template
classes/functions with user-defined mangled names, eg A_
88 matches
Mail list logo
