I suggest adding a way to override a @nogc function for debugging purposes:
suppose we need to *temporarily* debug / instrument a function marked as
@nogc (myfun) by adding some piece of code that may allocate (quick and
dirty debugging). Unfortunately, in DIP60 we can't just temporarily remove
I filed a bug report: https://issues.dlang.org/show_bug.cgi?id=12923 : UTF
exception in stride even though passes validate
and then a proposed fix. The fix still passes unittests and also solves the
bug, however I'm not sure whether it is correct: is the behavior of
strideImpl correct or is the
I made a simple modification to std.regex to allow an option to prefix
match a regex.
Formally, if L(R) is the language recognized by a regex R, the language
recognized by prefix matching of R is:
L(p(R)) = prefix(L(R)) = {u : uv in L(R) for some v}
Trying to come up (by hand or
On Wed, Jun 18, 2014 at 12:37 PM, Dmitry Olshansky via Digitalmars-d
digitalmars-d@puremagic.com wrote:
18-Jun-2014 21:38, Timothee Cour via Digitalmars-d пишет:
I made a simple modification to std.regex to allow an option to prefix
match a regex.
Formally, if L(R) is the language
See email: 'with(Foo):' not allowed, why? in '
digitalmars-d-le...@puremagic.com' forum
There's already an implementation proposed.
On Sat, Aug 9, 2014 at 8:46 AM, Mehrdad via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Saturday, 9 August 2014 at 13:29:47 UTC, Anonymouse wrote:
There is no realloc, move, cpy ?
Not sure what you mean by move or copy (can't you just use regular
memmove/memcpy?) but no, there is
This used to work prior to 2.066 (rc):
Duration t;
auto tv=timeval(t.total!seconds,t.fracSec.usecs);
now it works but with:
Deprecation: function core.time.Duration.fracSec is deprecated - Please use
split instead.
I see there's a SysTime.toTimeVal but there's no Duration.toTimeVal.
Shouldn't
On Sun, Aug 10, 2014 at 7:21 PM, Timothee Cour thelastmamm...@gmail.com
wrote:
This used to work prior to 2.066 (rc):
Duration t;
auto tv=timeval(t.total!seconds,t.fracSec.usecs);
now it works but with:
Deprecation: function core.time.Duration.fracSec is deprecated - Please
use split
Thanks; shouldn't this be a function ?
we have SysTime.toTimeVal, why not Duration.toTimeVal?
On Sun, Aug 10, 2014 at 8:40 PM, Jonathan M Davis via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 11 August 2014 at 02:46:11 UTC, Timothee Cour via Digitalmars-d
wrote:
On Sun, Aug
The deprecation message in 2.066(rc): 'Deprecation: function
std.process.system is deprecated - Please use executeShell instead' is
often not what user wants.
The behavior of the deprecated std.process should most closely be:
int systemNew(in char[] args){
auto pipes = pipeShell(args,
There used to be a table; not anymore; the table seems flattened as text as
follows:
The following table compactly summarises the different process creation
functions and how they relate to each other: Runs program directly Runs
shell command Low-level process creation spawnProcess spawnShell
On Tue, Aug 12, 2014 at 3:41 PM, Vladimir Panteleev via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Tuesday, 12 August 2014 at 07:53:44 UTC, Timothee Cour via
Digitalmars-d wrote:
int systemNew(in char[] args){
auto pipes = pipeShell(args, cast(Redirect)0);
return wait(pipes.pid
On Tue, Aug 12, 2014 at 11:09 PM, Lars T. Kyllingstad via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Tuesday, 12 August 2014 at 07:53:44 UTC, Timothee Cour via
Digitalmars-d wrote:
The deprecation message in 2.066(rc): 'Deprecation: function
std.process.system is deprecated
Does the proposal handle multiple unittest blocks?
On Wed, Aug 13, 2014 at 9:02 PM, H. S. Teoh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Wed, Aug 13, 2014 at 06:10:54PM -0700, Andrei Alexandrescu via
Digitalmars-d wrote:
Destroy
import std.string;
auto a=std.string.split(as,df,,);//works
but split not in http://dlang.org/phobos/std_string.html
http://dlang.org/cpptod.html#raii mentions scope class and scope variables,
which seem deprecated (http://dlang.org/deprecate.html)
I've used it quite a bit for a number of bindings (opencv, sfml + many
other libs). It's much easier than the conventional approach of manual
bindings (eg deimos), especially to keep the port up to date with upstream
changes.
However the following should be worked on:
* support for newly
See also https://github.com/Hackerpilot/Dscanner/issues/224
It breaks tooling that expects the main convention.
On Thu, Mar 26, 2015 at 9:13 PM, deadalnix via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Friday, 27 March 2015 at 03:59:30 UTC, zhmt wrote:
The best way to do that is to separate the server modules into
independent processes. Then if one crashes, the others keep running without
How come we have both
http://dlang.org/library/std/process/pipeProcess.html
and
http://dlang.org/library/std/process/pipe_process.html
?
Also, http://dlang.org/library/std/process/pipeProcess.html seems outdated
(eg, no workDir shown).
I think people interested in D should take a closer look at nim and judge
for yourself ; http://nim-lang.org/tut1.html is a good starting point (docs
in general are very well written).
I went through their tutorials and here are some first impressions:
* nim is already bootstrapped
On Mon, Apr 13, 2015 at 10:28 AM, Timothee Cour thelastmamm...@gmail.com
wrote:
I think people interested in D should take a closer look at nim and judge
for yourself ; http://nim-lang.org/tut1.html is a good starting point
(docs in general are very well written).
I went through their
git clone git://github.com/D-Programming-Language/dmd.git
cd dmd
make -f posix.mak MODEL=64
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C src -f posix.mak
no cpu specified, assuming X86
dmd idgen.d
g++ -m64: No such file or directory
--- errorlevel 255
make[1]: *** [idgen] Error 255
NOTE: it's on a new laptop; not sure whether build rules implicitly assume
(maybe by error?) that something should be there beyond g++/clang/dmd but
the error message i get isn't helpful.
1) already have a version of dmd installed (relatively new requirement)
yes (via homebrew; on a new laptop):
On Mon, May 11, 2015 at 8:35 PM, Daniel Murphy via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Timothee Cour via Digitalmars-d digitalmars-d@puremagic.com wrote in
message news:mailman.875.1431359641.4581.digitalmar...@puremagic.com...
note, that this seems to be only happening
NOTE:
I had 'export CC=gcc' in my environment, leading to this behavior (ie
worked fine until 'Merge pull request #3970 from yebblies/idgend2', and
breaks after that pull request is merged).
If I 'unset CC' it works. But IMO it should work even when user has set CC
(or at least provide a better
note, that this seems to be only happening on master:
if I checkout another tag (git checkout v2.067.1-b1 or any other I've
tried) it builds fine.
So it must be a very recent regression
On Mon, May 11, 2015 at 5:55 AM, John Colvin via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday,
I found the culprit by bisection:
hash: 50b7697...
HEAD is now at 50b7697... Merge pull request #3970 from yebblies/idgend2
https://github.com/D-Programming-Language/dmd/commit/aa8a7b3dcf985c8332783961c1dd7bc598ec36c5
it builds fine right before this, and fails with this
On Mon, May 11, 2015
On Tue, May 12, 2015 at 4:45 AM, Daniel Murphy via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Timothee Cour via Digitalmars-d digitalmars-d@puremagic.com wrote in
message news:mailman.896.1431405519.4581.digitalmar...@puremagic.com...
I still think it is a regression.
I did have dmd
On Mon, May 11, 2015 at 11:20 PM, Ali Çehreli digitalmars-d@puremagic.com
wrote:
On 05/11/2015 10:23 AM, Timothee Cour via Digitalmars-d wrote:
I notice CC is set to 'g++' in posix.mak which is untypical (instead
of gcc for example)
That is required because although all implementation
dlopen() of a D shared library works when called from a C++ file, and that
a C++ file can call multiple D shared libraries simultaneously when using
RTLD_LAZY option.
Before waiting for a full solution with an integrated druntime, is there at
least a way to have a separate runtime in each shared
On Sun, Aug 9, 2015 at 12:33 AM, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 8/9/2015 12:18 AM, Iain Buclaw via Digitalmars-d wrote:
If the libraries were shared, this would reduce linking time, which in
various
benchmarks I've done is where most small projects
reposting https://issues.dlang.org/show_bug.cgi?id=14813 here as it seems
quite weird:
/+
dmd -c -o- main.d
how come this even compiles?
+/
main.d:
---
void fun()
{
alias A = void delegate(int);
//WTF?
A temp1 = (some_inexistant_field) { };
//WTF?
A temp2 =
sorry, not sure what i was thinking... happens when you post late... thanks!
On Mon, Jul 20, 2015 at 12:09 AM, Adrian Matoga via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 20 July 2015 at 07:01:34 UTC, Timothee Cour wrote:
reposting
that's only a partial fix:
I also would like to express:
iotaInclusive(1,256)
iotaInclusive(1,256,3)
etc
On Mon, Oct 12, 2015 at 12:31 PM, Nordlöw via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Monday, 12 October 2015 at 16:34:09 UTC, Andrei Alexandrescu wrote:
>
>> We can add
On Mon, Oct 12, 2015 at 1:41 PM, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On 10/12/15 10:55 PM, Timothee Cour via Digitalmars-d wrote:
>
>> that's only a partial fix:
>> I also would like to express:
>>
>> iotaInclu
also, workarounds involving:
iota(0,256).map!(a=>cast(ubyte)a)
are neither pleasant nor efficient
On Thu, Oct 8, 2015 at 7:41 PM, Timothee Cour
wrote:
> how to do iota(0,256) with ubytes ?
> and more generally:
> iota with 'end' parameter set to max range of a type.
>
how to do iota(0,256) with ubytes ?
and more generally:
iota with 'end' parameter set to max range of a type.
of course this doesn't work:
auto b=iota(ubyte(0), ubyte(256));
//cannot implicitly convert expression (256) of type int to ubyte
Could we have a function with iota_inclusive that has
some weird bugs can occur when, for example, an error or signal handler is
re-entrant.
Is there a way to detect this?
this works but is cumbersome to use [see below], is there a simpler way to
detect in calling code (i want to simplify SNIPPET in calling code)
---
module util.reentrance_check;
what's the rationale for:
Range length must be greater than or equal to the sum of shift and the
product of lengths
instead of:
Range length must be equal to the sum of shift and the product of lengths
?
It seems more lax and bug-prone.
I'm not sure I understand your argument.
My problem is that iota(5) has 5 elements which is more than 2*2, so I
would expect
iota(5).sliced(2,2)
or
iota(7).sliced(2,3).sliced(1,2)
to throw, as in pretty much any other tensor library:
*matlab:*
reshape(0:4, 2,2)
Error using reshape
To RESHAPE the
i wrote my own tensor library a while ago and it allows the more convenient
matlab/python+numpy like syntax:
a[ _, 9, R(2, $, -3)]
these are allowed:
R() or _: full range for an index
R(a,b): a..b
R(a,b,s): when s>0, iota(a,b,s)
R(a,b,s): when s<0, iota(a,b,-s).reverse
Could we have this in
On Fri, Jan 8, 2016 at 10:07 PM, Ilya via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Saturday, 9 January 2016 at 04:15:08 UTC, Timothee Cour wrote:
>
>> ok good, 'reshape' behaves as it should; but what's the rationale for not
>> throwing on 'iota(5).sliced(2,2) ' ?
>>
>> in light
After more thought (since you have freedom of redesigning from scratch),
how about this:
https://docs.google.com/document/d/1cEf8AynZEZxlTENJx1i4w1GTB481bbc4iUbUeJT00-U/edit#heading=h.uxrd8sd74w8r
On Fri, Jan 8, 2016 at 11:00 PM, Ilya Yaroshenko via Digitalmars-d <
digitalmars-d@puremagic.com>
for the 'dmd.conf should prepend instead of append?' aspect of the
question, I filed https://issues.dlang.org/show_bug.cgi?id=15531
On Mon, Dec 28, 2015 at 6:50 AM, Timothee Cour
wrote:
> I'd like to have a command line flag for dmd (and ldc,gdc) that would be
> the
ok good, 'reshape' behaves as it should; but what's the rationale for not
throwing on 'iota(5).sliced(2,2) ' ?
in light of what i wrote above, it's surprising behavior and will cause
bugs. What are the advantages of allowing it to not throw?
On Fri, Jan 8, 2016 at 6:09 PM, Ilya via
I'd like to have a command line flag for dmd (and ldc,gdc) that would be
the analog to:
llvm-config --ldflags --cflags
ie, would print the corresponding flags used by dmd after following the
internal logic (look for dmd.conf in a number of directories, look for
DFLAGS environment variable etc).
What's the rationale for to!string not being fully qualified? it breaks
reconstructing a struct from it's to!string representation whenever the
struct contains an enum somewhere.
What's a workaround?
filed as https://issues.dlang.org/show_bug.cgi?id=16190
Is there a better way than the example below to have an informative (ie
formatted with runtime values) error message inside a nogc function?
@nogc
void test(int a){
char[100]buf; //TODO:make sure big enough
//auto s=sformat(buf, "a = %s", a);/// not nogc even though it accepts a
buf
auto
just more fine-grained control ... but either way.
having an escape away from nogc would be needed.
On Sun, Jan 10, 2016 at 1:56 AM, rsw0x via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Sunday, 10 January 2016 at 09:17:20 UTC, Timothee Cour wrote:
>
>> this would make error
this would make error handling trivial and solve issues such as this:
FORUM:formatted assert error messages inside nogc functions
http://forum.dlang.org/thread/CANri+EyNyrhMWGCSqZHx_vXDJFSrwhOrV=j2katz6t9-upt...@mail.gmail.com
usage:
during development:
dmd -debug -ignore_nogc other_flags foo.d
update: with @nogc @trusted pure this becomes even uglier:
@nogc @trusted pure
void test(int a){
if(!(a==3)){
debug{
char[100]buf; //TODO:make sure big enough
// would like to use 'auto s=sformat(buf, "a = %s", a);' but not nogc:
https://issues.dlang.org/show_bug.cgi?id=13055
Is there any reason not to use git submodules to organize the various
common dlang repos?
see relevant discussion:
*
http://www.digitalmars.com/d/archives/digitalmars/D/The_annoying_D_build_system_181472.html
[from 2012]
* http://comments.gmane.org/gmane.comp.lang.d.general/172893
* [llvm-dev]
Is there a way to avoid decoding (as utf8) when calling regex' apis?
or a plan to do so?
use case: speed (no decoding) and avoiding throwing on invalid utf8 sequences
ideally this should allow:
---
auto s = cast(ubyte[]) "abcd"; //potentially not valid utf8 sequence
auto r = cast(ubyte[])
On Wed, Mar 16, 2016 at 10:25 PM, Piotrek via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Wednesday, 16 March 2016 at 18:36:48 UTC, Mark Isaacson wrote:
>
>> From experience, it turns out that having a restricted language to
>> specify your builds/dependencies is a very good thing.
can https://github.com/msoucy/dproto be used as a starting point?
On Fri, Mar 18, 2016 at 11:18 PM, Rajat Kumar via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> Hello.
> I am Rajat Kumar, a junior year university student from India. I have
> working experiences in languages like C,C++
On Mon, Mar 21, 2016 at 4:34 AM, Nick Treleaven via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On 14/03/2016 11:32, thedeemon wrote:
>
>>
>> filter_map : ('a -> 'b option) -> 'a t -> 'b t
>>
>> "filter_map f e returns an enumeration over all elements x such as f y
>> returns Some x,
given fun(put, a) a lambda that can call $put 0 or more times,
some_range.emit!fun computes a range formed of all the calls to $put
eg:
assert(9.iota.emit!(int,(put,a){if(a%2) put(a*a);}).equal([1, 9, 25, 49]));
in this case it can be done by combining map and filter but in other cases
emit is
one takeaway from the video in [EMAIL:In language tooling] that would be
doable in D with a compiler as a library:
we could provide hooks (via user defined function delegates) in the
compiler when some action happen, eg: opening a file to be compiled,
parsing an import, processing an expression
typo:
q{...} // comment (existing syntax)
=>
q{...} // string literal (existing syntax)
On Mon, Apr 4, 2016 at 10:39 PM, Timothee Cour wrote:
> what's D's answer for C++11's uniform initialization [1] which allows DRY
> code?
>
> Could we have this:
>
> struct A{
{} for tuples hasn't worked out since it was deemed ambiguous with
delegate syntax (was it for the case of empty statements/tuple?).
How about the following syntax instead:
{} // delegate (existing syntax)
q{...} // string literal (existing syntax)
t{...} // tuple(a,b) (proposed syntax)
what's D's answer for C++11's uniform initialization [1] which allows DRY code?
Could we have this:
struct A{
int a;
int b;
}
A fun(A a, int b) {
if(b==1) return i{0,1};
else if(b==2) return i{2,3};
else return fun(i{3,4}, 1);
}
As for which syntax to use, that's an
On Wednesday, 20 July 2016 at 18:21:46 UTC, ketmar wrote:
p.s. the sole improvement in symbol lookup mechanics can speed
up the things by several factors, and without breaking the
language. current dmdfe symbol/template lookup mechanics is not
really fast.
If this example weren't enough,
this simple example shows this feature would provide a 16X
speedup.
time dmd -c -o- -version=A -I$code main.d
0.16s
time dmd -c -o- -version=B -I$code main.d
0.01s
---main.d:
module tests.private_import.main;
import tests.private_import.fun;
void test(){}
---
---fun.d:
module
currently, top-level imports in a module A are visible by other modules B
importing A, and are visited (recursively) during compilation of A, slowing
down compilation and increasing dependencies (eg with separate compilation
model, a single file change will trigger a lot of recompilations).
I
typo:
s/dmd -c -o- -deps A.d/dmd -c -o- -deps B.d
On Wed, Jul 20, 2016 at 12:45 AM, Timothee Cour
wrote:
> currently, top-level imports in a module A are visible by other modules B
> importing A, and are visited (recursively) during compilation of A, slowing
> down
also: catch D exceptions from C++ vs catching C++ exceptions from D; IIRC
only one direction is supported
On Mon, Jan 30, 2017 at 11:42 AM, kinke via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> I was wondering whether C++ interop is already considered sufficiently
> working enough, as
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 -extra_flags=-pie foo.d
```
where -extra_flags=flag1,flag2 can takes comma separated options
> Doesn't add indentation:
>
> with (module_!"std.stdio, std.traits")
> void fun(T)(File input, T value)
> if (isIntegral!T);
* what is the implementation of `module_` ? `from` defined earlier
doesn't allow for multiple modules as in from!"std.stdio,
std.traits"`. But let's assume it can be done
> Just use shell expansions?
> dmd -Wl,-{lbar,Ldir,-export-dynamic,pie}
This doesn't work : unrecognized switch '-Wl...'
On Sun, Dec 11, 2016 at 3:36 PM, Guillaume Boucher via Digitalmars-d
wrote:
> On Sunday, 11 December 2016 at 21:39:26 UTC, Timothee Cour wrote:
Could we have a `dmd -v=json` ?
Related:
would be nice to also show (in json output) fields including dflags
and lflags to avoid having to do the work that the compiler already
did:
`dmd | grep 'Config file'`
Config file: path/to/etc/dmd.conf
followed py parsing the contents of `dmd.conf`
relying on the shell (especially involving arrays) seems like a bad
idea: not portable, easy to mess up:
`dmd -L{-lbar,-Ldir,--export-dynamic}` works but what if it's stored in $lflags:
lflags="-lbar,-Ldir,--export-dynamic"
the function to convert $lflags to a dmd-appropriate flag is not so
Try dscanner --sloc although IMO --tokenCount should be the most relevant
metric (only caveat is mixin strings with which one could cheat to make
token count smaller).
TokenCount formatting invariant
On Feb 25, 2017 11:36 AM, "Andrei Alexandrescu via Digitalmars-d" <
digitalmars-d@puremagic.com>
> Am I reading it correctly that D is the second most popular general purpose
> language (let's exclude GLSL form general purpose programming)?? And that the
> volume of weekday commits, at least in GitHub, is dominated by niche and
> legacy languages, plus Matlab?
You're reading it wrong:
> You can pass multiple -L flags:
>
> dmd -L-lbar -L-Ldir -L--export-dynamic
I know, but that's inconvenient.
Would make things a lot easier if we had something like what i suggested:
`-Wl=comma_separated_linker_flags`
advantages: could seemlessly use `comma_separated_linker_flags` with
either
* std.stdio.tempfile creates an (unnamed) File. How do I create a temporary
fifo instead?
my workaround is to use tempnam but docs says it's not recommended (
http://man7.org/linux/man-pages/man3/tempnam.3.html)
* could we allow specifying a directory name for tmpfile?
What about allowing syntax sugar as an alternative to relying on the new
`from/Module` inline import idiom:
```
void fun(T)(std.stdio::File input, T value) if (std.traits::isIntegral!T)
{...}
```
instead of:
```
void fun(T)(Module!"std.stdio".File input, T value) if
> The only thing from has going for it is that it doesn't require a
language change. Yours does, so it should be compared to the proposals in
DIP1005 and not just from.
indeed. But just because something can be done in library code doesn't mean
it should. Same exact rationale for:
`lazy`, `=>`,
as for language change, I believe the proposed syntax (`::`) can be reduced
to a minimum if we we make `fullyqualifiedName` `::` a reduction to the
from/Module inline import idiom. No complex corner case or new bug
introduced, it could be done as a pure AST transformation
On Mon, Feb 13, 2017 at
`#std.stdio.File` doesn't work, we don't know where is the module
separator:
that could mean `module std` with a class stdio with a field File.
so the syntax would have be:
`std.stdio SYMBOL File`
frankly I don't care which symbol, so long it looks like that. And as I
said, `std.stdio::File` is
How do I define pragma(mangle,"name") for a type?
Use case:
I'd like to avoid the complications involved in
https://github.com/dlang/druntime/pull/1316/files [Addition of C++
std::string, std::vector to D #1316]
by directly defining the desired mangle for a c++ std::string (+ other
similar use
I should've said 'related', not actually a dup. Walter, could you please
shed some light on this other thread?
Any workaround in the meantime would be highly appreciated
http://forum.dlang.org/thread/mailman.445.1487070970.31550.digitalmar...@puremagic.com
pragma(mangle,"name") for a type?
looks like a dup of this:
http://forum.dlang.org/thread/mailman.445.1487070970.31550.digitalmar...@puremagic.com
pragma(mangle,"name") for a type?
On Tue, Feb 14, 2017 at 7:40 PM, Mike Parker via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> ```
> module mang;
> extern(C):
>
https://issues.dlang.org/show_bug.cgi?id=17178
dmd -c -o- bar.d
Error: namespace bar.std conflicts with import bar.std at bar.d(2)
```
module bar;
import std.exception;
extern (C++, std) { struct Foo1 { } }
```
this seems like a serious blocker to interface with C++ ; what's a
workaround?
This thread completely diverged from the original post, which was propsing
`::` instead of `from!`:
```
void fun(T)(std.stdio::File input, T value) if (std.traits::isIntegral!T)
{...}
```
instead of:
```
void fun(T)(Module!"std.stdio".File input, T value) if
(Module!"std.traits".isIntegral!T)
> I believe the recommended function for this is mkstemp. [1]
Mkstemp creates a regular file, not a fifo
>> * could we allow specifying a directory name for tmpfile?
> Yes, using mkdtemp. [2]
I meant adding a D api to add a temp file rooted under a specified
directory; the C api's allow that
Would it make sense to have `dmd -v=json` to avoid custom parsing of -v ?
benefit:
* avoid having to maintain parsers for -v output (eg used in rdmd)
* current parser not forward/backward compatible with different dmd
releases (eg each time something is added, it can break the parser, eg
2.073
Not that it's hard to do, but would be nice to have this in std.datetime,
just ran into some data that was using AM/PM.
eg:
if(AMPM == "PM" && hours<12) hours = hours+12;
if(AMPM == "AM" && hours==12) hours = hours-12;
is there a way to do this efficiently with associative arrays:
aa[key]=value;
auto ptr=key in aa;
without suffering the cost of the 2nd search (compiler should know ptr
during aa[key]=value but it's not exposed it seems)
instead of having multiple binaries polluting global namespace what about
combining them into:
dtools --catdoc
dtools --changed
etc
with maybe exception of a few such as rdmd
advantages:
less pollution of global namespace, smaller overall size (binaries
duplicate code), more opportunities for
oftentimes when compiling a program one gets errors such as:
Error: module vibe is in file 'vibe/vibe.d' which cannot be read
it can be hard to trace where is the offending file that imports said
missing module.
Could we also print the import chain in error message. eg:
foo.bar => foo2.bar2 =>
I'd like to be able to customize rendering of files (eg in error messages)
output by dmd, eg:
dmd XXX
foo/bar.d: Warning: statement is unreachable
dmd --fileprefix=mydir/ XXX
mydir/foo/bar.d: Warning: statement is unreachable
this makes it easy to allow user to see where errors came from even
maybe remove the corresponding DIP from
https://github.com/libmir/mir/wiki/Compiler-and-druntime-bugs#dips ?
On Thu, Sep 29, 2016 at 2:19 PM, Ilya Yaroshenko via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Thursday, 29 September 2016 at 21:06:13 UTC, Timothee Cour wrote:
>
>> this
this works:
void foo(T, size_t n)(T[n] a ...) {...}
However, see this: https://github.com/libmir/mir/issues/337
On Thu, Sep 29, 2016 at 1:57 PM, Ilya Yaroshenko via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Thursday, 29 September 2016 at 20:54:12 UTC, Ilya Yaroshenko wrote:
>
>> It should just be implied by -unittest!
+1
On Wed, Oct 26, 2016 at 7:49 AM, Nick Sabalausky via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On 10/26/2016 09:25 AM, Adam D. Ruppe wrote:
>
>> On Wednesday, 26 October 2016 at 08:15:44 UTC, Basile B. wrote:
>>
>>> What would be
rdmd seems completely broken:
see https://issues.dlang.org/show_bug.cgi?id=16962
Some more details on my proposa based on UDA:
// applies to next decl
@deps!({import std.algorithm;})
void test1(){}
// applies to a set of decls
@deps!({import std.stdio;}){
void test2(){}
void test3(){}
}
// applies to all following decls (':')
@deps!({import std.array;}):
// can specify
wrote:
>
>> On 12/15/2016 02:22 PM, Timothee Cour via Digitalmars-d wrote:
>>
>>> Some more details on my proposa based on UDA:
>>>
>>> ...
>>>
>>> I now understand the idea, thank you.
>>
>> My question is, doesn't this take t
What about simply this:
```
module foo;
{
import std.stdio;
void fun(File foo){}
}
{
import sd.range;
void foo(T) if(isInputRange!T){}
}
```
On Wed, Dec 14, 2016 at 9:50 AM, ketmar via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Wednesday, 14 December 2016 at 17:32:10 UTC, H.
how about this:
variant 1 // currently legal D; just need to attach semantics
```
// applies to all below
@deps!({import std.stdio; pragma(lib, "curl"); }):
// applies to 1 below
@deps!({import std.range})
void fun(T)(isInputRange!T){} // depends on both deps
void fun2(File file){} // depends
1 - 100 of 317 matches
Mail list logo