@Manu, @Jonathan M Davis
> GNU's std::string implementation stores an interior pointer! >_<
it's not just GNU's std::string ; it can crop up in other places, see
https://github.com/Syniurge/Calypso/issues/70 in opencv (cv:: MatStep)
On Wed, Oct 3, 2018 at 8:10 PM Shachar Shemesh via Digitalmars
when fun(2)==2: echo "ok2"
```
prints ok1
On Fri, May 4, 2018 at 9:40 AM Mark via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Thursday, 3 May 2018 at 23:09:34 UTC, Timothee Cour wrote:
> > nim supports static if (`when`) + CTFE. A simple google search
>
nim supports static if (`when`) + CTFE. A simple google search or searching
would've revealed that.
On Thu, May 3, 2018 at 3:20 PM Mark via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Thursday, 3 May 2018 at 20:57:16 UTC, Dennis wrote:
> > On Thursday, 3 May 2018 at 19:11:05 UTC, Mar
2:20 UTC, Timothee Cour wrote:
>>
>> Nim looks very promising.
>> Is there any comprehensive comparison against D somewhere (if possible
>> recent) ?
>
>
> Nim is way more expressive than D afaik. Consider the following imaginary
> function:
>
> proc fn[A : int |
day, 27 March 2018 at 01:19:44 UTC, timotheecour wrote:
>>
>> On Wednesday, 22 April 2015 at 06:03:07 UTC, Timothee Cour wrote:
>>>
>>> On Mon, Apr 13, 2015 at 10:28 AM, Timothee Cour
>>> wrote:
>>>
>>>
>>> I would like to refocus this
https://wiki.dlang.org/Contributing_to_Phobos mentions:
> Smaller additions like individual functions can be merged directly after
> @andralex approves
The arguments for having all changes go through one person have been
presented here [1].
However this is how I see things:
* if phobos is supp
Marques via Digitalmars-d
wrote:
> On Tuesday, 13 March 2018 at 14:00:39 UTC, Luís Marques wrote:
>>
>> On Monday, 12 March 2018 at 23:03:33 UTC, Timothee Cour wrote:
>> Yeah, that works. I'll be trying it more thoroughly and report any issues.
>
>
> Even with DMD 2.079 the frame locals don't show up... LDC FTW!
s Marques wrote:
>>
>> On Monday, 12 March 2018 at 23:03:33 UTC, Timothee Cour wrote:
>> Yeah, that works. I'll be trying it more thoroughly and report any issues.
>
>
> Even with DMD 2.079 the frame locals don't show up... LDC FTW!
I originally proposed it here:
https://forum.dlang.org/post/mailman.3166.1517969180.9493.digitalmar...@puremagic.com
but it was buried under another thread
On Wed, Mar 14, 2018 at 3:04 PM, Adam D. Ruppe via Digitalmars-d
wrote:
> On Wednesday, 14 March 2018 at 21:22:01 UTC, Timothee Cour wr
would a PR for `dmd -unittest= (same syntax as -i)` be welcome?
wouldn't that avoid all the complicatiosn with version(StdUnittest) ?
eg use case:
# compile with unittests just for package foo (excluding subpackage foo.bar)
dmd -unittest=foo -unittest=-foo.bar -i main.d
Mar 12, 2018 at 7:21 AM, Luís Marques via Digitalmars-d
wrote:
> On Monday, 12 March 2018 at 14:19:03 UTC, Luís Marques wrote:
>>
>> On Tuesday, 27 February 2018 at 05:28:41 UTC, Timothee Cour wrote:
>>>
>>> https://github.com/llvm-mirror/lldb/pull/3
>>> +
updated build instructions, see
https://github.com/timotheecour/dtools/commit/8597923dd4ed7691f717b5e1bdbbf2ee66961ef5
On Fri, Mar 9, 2018 at 9:33 AM, Luís Marques via Digitalmars-d
wrote:
> On Tuesday, 27 February 2018 at 05:28:41 UTC, Timothee Cour wrote:
>>
>> https://github.c
I'm sure he meant:
```
--- foo.d
module foo;
module foo.bar{
void fun(){}
}
--- foo2.d
import foo.bar;
```
On Fri, Mar 9, 2018 at 10:51 AM, Manu via Digitalmars-d
wrote:
> On 9 March 2018 at 10:44, Jonathan via Digitalmars-d
> wrote:
>> D kinda lacks a way of creating a module/namespace ins
> I'm pretty sure Timothee based his patch onto LLDB/LLVM trunk.
indeed, see instructions here:
https://github.com/timotheecour/dtools/blob/master/dtools/lldbdplugin.d
> Seems like they prefer a shared library and not rewriting it in C++ [1].
indeed, I would not support something that requires r
There are lots of articles on this topic, eg:
https://blog.carbonfive.com/2017/08/28/always-squash-and-rebase-your-git-commits/
(note that squashing down to 1 commit shouldn't be necessary but at
least rebasing should be done)
github UI also allows to rebase (instead of merge)
would really simpli
theecour wrote:
>>
>> 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
>>>
>>&g
> Hm... borrowing from Timothee's suggestion:
> This would be fine and @safe, but may not be useful for all purposes.
> However, it would fix your issue.
how about this: https://github.com/dlang/phobos/pull/6231
On Tue, Feb 27, 2018 at 12:09 PM, Steven Schveighoffer via
Digitalmars-d wrote:
>
this would be more bearable if there was a standard @trusted method to
get array `.ptr`, eg:
in `object.d` (so that it's indeed standard)
```
@trusted @nogc pure nothrow
auto pointer(T)(T a){
return a.ptr;
}
```
again, the deprecation message is misleading because `&a[0]` isn't
equivalent to `a
see rationale in https://issues.dlang.org/show_bug.cgi?id=18529
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 (triggered inside
core.demangle.demangle);
Help is welcome to improve t
in example below, how do I propagate RET (or even `typeof(a)`) to the
result value of `inferType`?
does this need a language change to allow this?
```
template inference(alias emitter) {
auto inference(){
auto inferType(){
emitter!((a){
enum RET=typeof(a).stringof; // type is
orithm/package.d
```
when user browses to https://dlang.org/phobos/std_algorithm.html, he
would see the DDOC contents from all direct submodules of
std/aglorithm/ right there in that ddoc page.
On Thu, Feb 22, 2018 at 12:04 AM, Timothee Cour
wrote:
>> it actually does reduce compilation t
eb 21, 2018 at 11:57 PM, Jonathan M Davis via Digitalmars-d
wrote:
> On Wednesday, February 21, 2018 23:48:32 Timothee Cour via Digitalmars-d
> wrote:
>> ```
>> import std.algorithm.searching : find;
>>
>> not
>>
>> import std.algorithm : find;
>> ```
rse
effect.
On Wed, Feb 21, 2018 at 11:44 PM, Timothee Cour
wrote:
>> it's harder to find symbols
>
> i don't understand this argument.
>
> ```
> dscanner --declaration startsWith
> ./std/algorithm/searching.d(4105:6)
> ./std/algorithm/searching.d(4195:6
PM, Jonathan M Davis via Digitalmars-d
wrote:
> On Wednesday, February 21, 2018 23:13:33 Timothee Cour via Digitalmars-d
> wrote:
>> from my perspective it makes sense to split a module M into submodules
>> A, B when:
>> * M is large
>> * there's little interactio
note that we'd need to implement
https://github.com/dlang-community/dfmt/issues/159 (
option to format only diff-ed lines (like git clang-format))
in order to run dfmt on only the part of source code that was modified in a PR.
this is to avoid concern that it affects git history / git blame
(alt
from my perspective it makes sense to split a module M into submodules
A, B when:
* M is large
* there's little interaction between A and B (eg only few symbols from
A are needed in B and vice versa)
* A and B are logically grouped (that is domain specific)
* it doesn't turn into an extreme (1 func
https://github.com/Syniurge/Calypso now allows catch C++ exceptions
from D handlers (on OSX and linux at least)
On Tue, Feb 20, 2018 at 1:04 PM, H. S. Teoh via Digitalmars-d
wrote:
> I'm piecewise migrating one of my old C++ projects to D, and one of the
> major issues right now is exception han
see https://forum.dlang.org/post/p3bdp1$2b4e$1...@digitalmars.com [Tuple DIP]
On Tue, Feb 20, 2018 at 11:01 AM, valmat via Digitalmars-d
wrote:
> Hi there!
> I just started learn D.
> First it is greatful language.
> But unfortunatly it doesn't have variable destructuring syntax.
> Like this:
> `
On Mon, Feb 19, 2018 at 4:05 PM, Timon Gehr via Digitalmars-d
wrote:
> On 20.02.2018 00:53, Timothee Cour wrote:
>>
> Sure! Also, this:
>
> void main(string[] args){
> enforce(args.length==5, "Invalid args");
> auto (infile, colname,
great! maybe worth adding to DIP? (even though `unpack` would be
(IIUC) a pure library solution on top of this DIP)
and that would work too I guess?
```
string[4] args=...;
auto (infile, colname, repl, outfile) = args.unpack;
```
On Mon, Feb 19, 2018 at 3:47 PM, Timon Gehr via Digitalmars-d
wro
On Sun, Feb 18, 2018 at 4:46 PM, Sönke Ludwig via Digitalmars-d
wrote:
> Am 14.02.2018 um 19:33 schrieb Jonathan Marler:
>>
>> @timotheecour and I came up with a solution to a common problem:
>>
>> How to represent multiple files in a forum post?
>>
>
> Why not multipart/mixed? Since this is NNTP
is there a way to get typeid of extern(C++) classes (eg for ones in
dmd/astbase.d but not limited to that) ?
C++ exposes it via typeid so in theory all the info is there ;
I would need it at least for debugging (eg if RTTI is not enabled for
all compilers or in release mode that's fine so long ther
verage (I would even
venture it's less complex and less costly).
On Sun, Feb 11, 2018 at 2:32 PM, Walter Bright via Digitalmars-d
wrote:
> On 2/11/2018 1:55 PM, Timothee Cour wrote:
>>
>> I think you're missing my main point: it's explained here
>>
>> https
18 at 1:32 PM, Walter Bright via Digitalmars-d
wrote:
> On 2/5/2018 11:32 AM, Timothee Cour wrote:
>>
>> just filed https://issues.dlang.org/show_bug.cgi?id=18377:
>>
>> `dmd -cov -run main.d` shows 100% coverage; this is misleading since a
>> branch is not t
ars-d
wrote:
> On Saturday, February 10, 2018 15:03:08 Walter Bright via Digitalmars-d
> wrote:
>> On 2/8/2018 7:06 PM, Timothee Cour wrote:
>> > /"EOC
>> > This is a multi-line
>> > heredoc comment allowing
>> > /+ documented unittests con
version(none) { FOO } doesn't work if FOO doesn't parse.
Again, what I proposed is the only 100% reliable way to comment out something
On Fri, Feb 9, 2018 at 12:52 AM, Kagamin via Digitalmars-d
wrote:
> On Friday, 9 February 2018 at 08:44:31 UTC, Nick Sabalausky (Abscissa)
> wrote:
>>
>> On 02/0
summary:
* `/* */` should never be used
* properly nested `/+ +/` indeed don't cause issues
* urls cause issues and I've ran into this issue multiple times
* unrestricted code (eg foreign code or unfinished D code commented
out) also cause issues
* hreredoc comments fixes these issues when neeeddd
just filed https://issues.dlang.org/show_bug.cgi?id=18407
Issue 18407 - debug should escape nothrow, @nogc, @safe (not just pure)
On Thu, Feb 8, 2018 at 5:38 AM, Steven Schveighoffer via Digitalmars-d
wrote:
> On 2/8/18 8:32 AM, Steven Schveighoffer wrote:
>>
>> On 2/7/18 10:32 PM
NOTE:
the analog of documenting comments (/++ ...+/ and /** */) could be:
/""EOC
multiline comment
EOC"/
(ie allow both `/""` and `/"` before reading in the heredoc token)
On Thu, Feb 8, 2018 at 7:06 PM, Timothee Cour wrote:
> same exact idea as motivati
same exact idea as motivation for delimited strings
(https://dlang.org/spec/lex.html#delimited_strings)
```
auto heredoc = q"EOS
This is a multi-line
heredoc string
EOS"
;
/"EOC
This is a multi-line
heredoc comment allowing
/+ documented unittests containing nesting comments +/
and weird urls li
same question with how to wrap a gc function inside a nogc shell, if
not, allowing a flag -ignore_nogc that'd enable this (again, for
debugging purposes)
On Wed, Feb 7, 2018 at 7:29 PM, Timothee Cour wrote:
> while hacking into druntime and adding temporary debug information (eg
>
while hacking into druntime and adding temporary debug information (eg
with custom logging etc) I had a hard time making things compile
because lots of functions are pure nothrow safe, resulting in compile
errors when my custom debugging functions are not pure nothrow safe.
How about adding flags
understood, but that's responsibility of tester to make sure they're
not too flaky (eg using msg.canFind("FOO") (or, if regex weren't slow,
regex)
On Wed, Feb 7, 2018 at 1:13 PM, Nicholas Wilson via Digitalmars-d
wrote:
> On Wednesday, 7 February 2018 at 20:29
is there any way to get error from speculative execution (`__traits(
compiles, ...)`)? would be useful in tests; If not currently how hard
would that be to implement? eg:
```
struct Status{bool ok; string msg;}
Status status = __traits(compilesReportError, {string b=10;})
assert(!status.ok);
ass
how about using same syntax (and reusing logic) as newly introduced`
-i=+foo.bar,+baz-baz.bad`:
`dmd -unittest=+foo.bar,+baz,-baz.bad rest_of_arguments`
which would only enable unittests as specified? It's flexible and
intuitive, and would solve a common woe with unittests (eg
https://forum.dlang
how about using same syntax (and reusing logic) as newly introduced:
` -i=+foo.bar,+baz-baz.bad`
`dmd -unittest=+foo.bar,+baz,-baz.bad rest_of_arguments`
which would only enable unittests as specified? It's flexible and intuitive
On Tue, Feb 6, 2018 at 5:56 PM, Jonathan M Davis via Digitalmars-d
ugh... dynamicCast is private...
On Tue, Feb 6, 2018 at 5:13 PM, Seb via Digitalmars-d
wrote:
> On Tuesday, 6 February 2018 at 23:32:49 UTC, Timothee Cour wrote:
>>
>> but yes, API would look similar:
>>
>> auto Cast(T)(T a) if(...) {}
>> auto Cast(string dsl)(
but yes, API would look similar:
auto Cast(T)(T a) if(...) {}
auto Cast(string dsl)(T a) {}
On Tue, Feb 6, 2018 at 3:31 PM, Timothee Cour wrote:
> assumeUnique has a very specific use case; i was describing a more
> general way to handle various types of cast (and be explicit about
&
assumeUnique has a very specific use case; i was describing a more
general way to handle various types of cast (and be explicit about
whats allowed) as mentioned above
On Tue, Feb 6, 2018 at 3:18 PM, Seb via Digitalmars-d
wrote:
> On Tuesday, 6 February 2018 at 23:15:07 UTC, Timothee Cour wr
> Like assumeUnique?
https://dlang.org/library/std/exception/assume_unique.html
what do you mean? u mean adding "unique" to the DSL list ? maybe!
* for cast on extern C++ classes, why not use the same logic as what
C++ uses for dynamic_cast? (simplified because we don't support
multople inherita
well even old threads are useful to update when there's new
information ; because they show up in search results so good to keep
answers up to date (and provide link to newer info)
On Tue, Feb 6, 2018 at 1:44 PM, jmh530 via Digitalmars-d
wrote:
> On Tuesday, 6 February 2018 at 21:41:14 UTC, Jona
another weird gotcha:
auto s="foo".isEmail;
writeln(s.toString); // ok
writeln(s); // compile error
On Tue, Feb 6, 2018 at 12:30 PM, Steven Schveighoffer via
Digitalmars-d wrote:
> On 2/6/18 3:11 PM, Walter Bright wrote:
>>
>> On 2/5/2018 9:35 PM, Dmitry Olshansky wrote:
>>>
>>> That’s rea
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 the cast syntax suggests
type safety; especially a problem if we make
I had filed that last week:
https://issues.dlang.org/show_bug.cgi?id=18346
Issue 18346 - implicit conversion from int to char in `"foo" ~ 255`
should be illegal
we should deprecate it.
On Mon, Feb 5, 2018 at 7:14 PM, Nick Sabalausky (Abscissa) via
Digitalmars-d wrote:
> On 02/05/2018 09:30 PM,
just filed https://issues.dlang.org/show_bug.cgi?id=18377:
`dmd -cov -run main.d` shows 100% coverage; this is misleading since a
branch is not taken:
```
void main(){
int a;
if(false) a+=10;
}
```
how about adding a `-covmode=[loc|branch]` that would allow either
reporting LOC coverage or b
why is `a.init` even legal? (instead of typeof(a).init)
likewise the following compiles, but IMO should not:
class A{ void fun(this a){}}
(instead we should have typeof(this)
How about deprecating these lax syntaxes?
they serve no purpose (we should use typeof(...)) and can cause harm
in generic c
* This has nothing to do with name mangling.
Yes and no, these things are coupled. We can improve the situation by
forcing the size of mangled and demangled symbols to be < threshold,
eg `ldc -hash-threshold` would be 1 option.
example:
current mangled:
_D8analysis3run__T9shouldRunVAyaa20_666c6f
but this should be handled at the compiler level, with no change in
standard library getopt, eg using a hashing scheme (cf `ldc
-hashthres`)
On Sat, Jan 27, 2018 at 2:38 PM, Kagamin via Digitalmars-d
wrote:
> IIRC several years ago somebody created a dub package with DbI getopt. I
> think it woul
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(){
for grpc, we should add to dproto (which is pretty good protobuf
library for D but lacks grpc) instead of starting from scratch, see
https://github.com/msoucy/dproto/issues/113 [your advice/opinions on
integrating with grpc?]
On Mon, Jan 22, 2018 at 12:24 PM, Adrian Matoga via Digitalmars-d
wrot
could a solution like proposed below be adapted to automatically
reduce size of long symbol names?
It allows final object files to be smaller; eg see the problem this causes:
* String Switch Lowering:
http://forum.dlang.org/thread/p4d777$1vij$1...@digitalmars.com
caution: NSFW! contains huge mang
On Wed, Jan 24, 2018 at 5:50 PM, rikki cattermole via Digitalmars-d
wrote:
> On 24/01/2018 7:18 PM, Timothee Cour wrote:
>>
>> __TIMESTAMP__ is pretty useless:
>> `string literal of the date and time of compilation "www mmm dd hh:mm:ss
>> "`
>> eg:W
__TIMESTAMP__ is pretty useless:
`string literal of the date and time of compilation "www mmm dd hh:mm:ss "`
eg:Wed Jan 24 11:03:56 2018
which is a weird non-standard format not understood by std.datetime.
__DATE__ and __TIME__ are also pretty useless.
Could we have __TIMESTAMP_UNIXEPOCH__ (or
> Do we even have protobuf package?
https://github.com/msoucy/dproto
it could receive some attention, there are pending issues
for RPC I've been using msgpackrpc since no gRPC was available. But
would be nice to have gRPC.
NOTE: capnproto is a very interesting newer alternative to protobuf;
http
this is very related to ICF (identical code folding), which some linkers do.
in summary: gold and lld have options to do that, and it can be unsafe
to do if code relies on each function having distinct address;
> gold's --icf=safe option only enables ICF for functions that can be proven
> not to
> Not sure I understand this feature. Is it something like:
>
> auto foo = 3;
> auto bar = 4;
> log(foo, bar);
>
> Would print?
>
> main.d:3 foo=3
> main.d:3 bar=4
main.d:3 foo=3, bar=4 (or whatever formatting is applied given
supplied stringiified arguments, that's irrelevant as it can be
customi
>> But in any case, the idea that comments affect the file you are compiling
>> *right now*, and not some other tool-generated file makes me very nervous.
>> Comments are supposed to not affect the code. Consider that with this
>> feature, the documentation now becomes part of the API.
That's alre
I wrote something like that to mimic C's `#arg` preprocessor
(stringify argument) for debugging functions, eg:
```
// simplified here:
void log(string file=__FILE__, int line=__LINE__, T) (T a){
enum arg_stringified=import(file)[line]; // more complex in practice
writeln(arg_stringified, ":",
On Sun, Jan 14, 2018 at 10:17 AM, Timon Gehr via Digitalmars-d
wrote:
> On 14.01.2018 19:14, Timothee Cour wrote:
>>
>> actually I just learned that indeed sizeof(typeof(tuple()))=1, but why
>> is that? (at least for std.typecons.tuple)
>> maybe worth mentioning that
actually I just learned that indeed sizeof(typeof(tuple()))=1, but why
is that? (at least for std.typecons.tuple)
maybe worth mentioning that in the DIP (with rationale)
On Sun, Jan 14, 2018 at 8:18 AM, Timon Gehr via Digitalmars-d
wrote:
> On 14.01.2018 15:55, Q. Schroll wrote:
>>
>> On Friday,
eg:
how to instrument dmd compiler to dump all references to a given symbol?
eg: for `A.a` it should output the locations marked with HERE
any help/starting points would be appreciated!
```
Struct A{
int a;
void fun(){
a++; // HERE
alias b=a;
b++; // HERE
}
}
void fun(){
int a; // NOT HE
some people have suggested using `{a, b}` instead of `(a,b)` ; this
would not work because of ambiguity, eg:
`auto fun(){ return {}; }`
already has a meaning, so the empty tuple would not work.
so `()` is indeed better.
On Fri, Jan 12, 2018 at 2:44 PM, Timon Gehr via Digitalmars-d
wrote:
> As pro
the DIP says this replace std.typecons.TypeTuple however no mention is
made of named arguments, so I don't see how they could be a
replacement (nor how would that allow for a migration path) without
mentioning a word on this, eg:
what would be the equivalent of this ?
` writeln(tuple!("x", "y", "z
it would also solve a long-standing issue of passing runtime optional
arguments along with variadic templates, eg:
current:
```
# current: bad, causes template bloat (1 template per call site)
void log(string file=__FILE__, int line=__LINE__, T...)(T a);
# usage:
log(1, "foo");
# with this DIP
vo
https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md#proposal-6-placeholder-name-_
> Symbols with the name _ should not be inserted into the symbol table.
why not use `?` instead of `_` ?
no breaking change and should be unambiguous with (expr ? expr : expr) syntax
On Fri, Jan 12
https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md#proposal-4-unpacking-assignments
```
(a, b) = t;
// shouldn't it be:
auto (a, b) = t;
```
?
On Sat, Jan 13, 2018 at 9:52 AM, Mengu via Digitalmars-d
wrote:
> On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote:
>>
>> A
e !in _handleToDSO) in setDSOForHandle)
* https://github.com/Syniurge/Calypso/issues/63
error: The module 'ℂcpp.std.type_info' is already defined in
libcalypso-ldc-shared.dylib #63
again, this would make C++ interop much easier and more powerful than
alternatives
On Wed, Dec 13, 2017 at 9:12 PM
Has anyone used https://github.com/Syniurge/Calypso on OSX? I'm
running into a basic issue :
https://github.com/Syniurge/Calypso/issues/60 which makes any binary
crash immediately
Making Calypso work would make integration with C++ libraries much
easier, so it's rather important for dlang.
Supporting shared libraries seems like a pretty important issue, IMO
more important than many things being worked on. I can't think of
other languages not supporting them; it renders many use cases
impossible, preventing more widespread adoption.
Is it on the roadmap? It's been a very long standin
ue. Certain
use cases are impossible without using shared libraries.
On Fri, Dec 8, 2017 at 3:55 PM, Jonathan M Davis via Digitalmars-d
wrote:
> On Friday, December 08, 2017 10:45:29 Steven Schveighoffer via Digitalmars-d
> wrote:
>> On 12/7/17 9:15 PM, Jonathan M Davis wrote:
this is obviously a serious error and is a blocker for running unittests.
also filed: https://issues.dlang.org/show_bug.cgi?id=18049
managed to reduce it to a short example code with zero dependencies:
dmd -lib -oflibfun.a fun.d
dmd -main -unittest main.d libfun.a
Undefined symbols for architect
I have a simple test case to reproduce in
https://issues.dlang.org/show_bug.cgi?id=18046
this seems like a serious bug; what would be a workaround when dealing
with shared libraries?
is there a link to source code (C++,C,D) nor compile / runtime commands used?
hard to reach any conclusion without this
On Thu, Dec 7, 2017 at 1:55 AM, Antonio Corbi via Digitalmars-d
wrote:
> Hello all,
>
> Jussi Pakkanen (one of the meson build system creators) has written a post
> comparing C
alizedPath on both
arguments; which is way would be nice to have in std.path
On Wed, Dec 6, 2017 at 8:55 PM, Jonathan M Davis via Digitalmars-d
wrote:
> On Wednesday, December 06, 2017 17:36:04 Timothee Cour via Digitalmars-d
> wrote:
>> what would be a robust way to do this `inverseRel
on;
auto a="/a/b/c.d";
auto b="b/c.d";
assert(inverseRelativePath(a, b) == "/a");
assertThrown(inverseRelativePath(a, "c2.d"));
}
```
On Wed, Dec 6, 2017 at 5:36 PM, Timothee Cour wrote:
> what would be a robust way to do this `inverseRelativePath
what would be a robust way to do this `inverseRelativePath`, and
should that be in std.path?
```
auto a="/a/b/c.d";
auto b="b/c.d";
assert(inverseRelativePath(a, b) == "/a");
assertThrown(inverseRelativePath(a, "c2.d"));
```
on OSX 10.13.1 if that matters; IIRC it was working on previous OSX version.
On Thu, Nov 30, 2017 at 4:46 PM, Timothee Cour wrote:
> I get: core.sync.exception.SyncError@(0): Unable to lock mutex.
> when calling listenHTTP via a library. It works when compiling
> everything in
I get: core.sync.exception.SyncError@(0): Unable to lock mutex.
when calling listenHTTP via a library. It works when compiling
everything in a single application without using intermediate library.
details:
using: dmd:2.077
dub build
dmd -ofmain -L-Ldir -L-ltest1 -Isource import/main.d
./main
On Wed, Aug 23, 2017 at 10:38 PM, lobo via Digitalmars-d
wrote:
> On Thursday, 24 August 2017 at 01:51:25 UTC, Timothee Cour wrote:
>>>
>>> [...]
>>
>>
>> nim:
>> it supports both targetting C++ (as well as C or javascript) and also
>> calling C
> Do you know another language or tool that can call C++ natively?
nim:
it supports both targetting C++ (as well as C or javascript) and also
calling C++ via foreign function interface, eg here are some links:
https://github.com/nim-lang/Nim/wiki/Playing-with-CPP--VTABLE-from-Nim
https://stackover
chunkBy can't backtrack on an inputrange (but ok with a forward range,
eg by uncommenting a .array below). This can be fixed using the
mapCache defined below. Is there another way without introducing
mapCache ?
main.d:
```
/+
D20170705T174411
$ echo 'abc' | dmd -version=with_mapCache -run main.
How would I disable the following?
```
auto a1=A(1);
auto a2=A(1, "b");
struct A{
int a;
string b;
// @disable default constructors with N(N>=1) arguments
}
```
I'd like to force the user to set fields explicitly, so as to make it
more safe to add / move fields
How would I use a dynamic shared libraries compiled with
-defaultlib=libphobos2.so? Is that supported?
I'm running into https://issues.dlang.org/show_bug.cgi?id=17591
Is there a construct similar to Nullable that would auto-allocate upon
access (set/get) if isNull is true?
Use case: https://github.com/msoucy/dproto/issues/117 [getters and
setters should work without calling `init` on Nullable fields, as in
C++ #117]
copied inline for easy reference:
```
in C+
Proposal: support reading multiple files (with fake file names) from stdin.
This is a natural extension of
https://issues.dlang.org/show_bug.cgi?id=9287 (Issue 9287 - DMD should
read from stdin when an input file is "-")
Example use case:
* simplify writing bug reports and trying out other people
> Msgpack rpc with vibe.d works. We used it.
you mean with msgpackrpc-d? If so, it works, until you run into
https://github.com/msgpack-rpc/msgpack-rpc-d/issues/16 (when server
sends >= 4090 bytes, client hangs forever).
> we switched towards http + asdf
not sure what asdf is?
On Wed, Jun 1
eg:
Error: no property 'IF_gray' for type 'ImageFormat'
=>
Error: no property 'IF_gray' for type 'foo.bar.ImageFormat'
and also, why not show where the symbol is defined?
would PR's for that be accepted? is that hard to implement?
2:38 UTC, Timothee Cour wrote:
>>
>> any help on this would be most welcome:
>> https://github.com/msgpack-rpc/msgpack-rpc-d/issues/16
>>
>> Unfortunately I find the RPC support in D lacking. Having a good RPC
>> integration for D is key for production use of D where o
any help on this would be most welcome:
https://github.com/msgpack-rpc/msgpack-rpc-d/issues/16
Unfortunately I find the RPC support in D lacking. Having a good RPC
integration for D is key for production use of D where one wants to
integrate with other existing services (that could be written in o
1 - 100 of 453 matches
Mail list logo
