bootable vibed
I found very interesting project https://github.com/hioa-cs/IncludeOS But by description it's target to C++ "IncludeOS is an includable, minimal unikernel operating system for C++ services running in the cloud". I think that would be a lot of people interesting to get same for D and vibed.
Re: @ctfeonly
On Friday, 8 December 2017 at 06:39:10 UTC, ketmar wrote: no compilation errors, runtime assert. that is, it is technically still executed in runtime. damnit!
Re: @ctfeonly
Mike Franklin wrote: // I couldn't figure out how to force `onlyCompileTime` to // execute at runtime. That's probably a good thing. string s = onlyCompileTime(); no compilation errors, runtime assert. that is, it is technically still executed in runtime.
Re: @ctfeonly
On Friday, 8 December 2017 at 01:30:13 UTC, Manu wrote:
I tried this, and was surprised it didn't work:
int ctfeOnly(int x)
{
static assert(__ctfe);
return x + 1;
}
This would probably solve the problem in a satisfying way
without an attribute?
Interestingly, if you put `__ctfe` in a function it does seem to
work (unless I'm missing something). Check this out.
import std.stdio;
bool isRunTime()
{
return !__ctfe;
}
bool isCompileTime()
{
static if (!isRunTime())
return __ctfe;
else
return false;
}
string onlyCompileTime()
{
static assert(isCompileTime(),
"This function can only be executed at compile time");
assert(isCompileTime(),
"This function can only be execute at compile time");
return "onlyCompileTime";
}
string onlyRunTime()
{
// This assert will actually throw an error at compile-time,
// if an attempt is made to execute it at compile time.
assert(isRunTime(), "This function can only be executed at
run time");
return "onlyRunTime";
}
void main(string[] args)
{
static assert(isCompileTime());
static assert (!isRunTime());
assert(!isCompileTime());
assert(isRunTime());
static assert(onlyCompileTime() == "onlyCompileTime");
// Compile-time Error: Good!
//static assert(onlyRunTime() == "onlyRunTime");
assert(onlyRunTime() == "onlyRunTime");
// Compile-time Error: Good!
// pragma(msg, onlyRunTime());
// I couldn't figure out how to force `onlyCompileTime` to
// execute at runtime. That's probably a good thing.
}
https://run.dlang.io/is/64fRRX
I guess this is due to the fact that wrapping `__ctfe` in a
function causes it to run at compile-time instead of
at...well...compile-time (i.e.
https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time)
Mike
Re: @ctfeonly
On Friday, 8 December 2017 at 03:41:05 UTC, Walter Bright wrote:
bar.d:
module bar;
string generateString(T)()
{
return T.stringof ~ " foo;";
}
enum s = generateString!int();
a.d:
@compute(CompileFor.deviceOnly) module a;
int baz()
{
import bar;
bar.s;
return foo;
}
That requires that I know what instantiations I will have a head
of time or I have to maintain a "header file" of named
instantiations. Both of which I consider subpar solutions. Also
while it may not bloat the GPU binary it will still bloat the
host binary.
Re: Adding Markdown to Ddoc
On 12/7/2017 2:21 AM, Jacob Carlborg wrote: On 2017-12-06 05:11, Walter Bright wrote: https://help.github.com/articles/basic-writing-and-formatting-syntax/ Anyone interested in picking up the flag? (I know this has come up before, and I've been opposed to it, but I've changed my mind.) Finally :), this is awesome. Should we implement standard markdown, GitHub markdown or some other extension? I dunno. Make a case. There's no backward compatibility necessary, so we do not have to worry about the two ways of doing lists, for example. Just '*' will do. Aside from what Ddoc already does, I'd just stick with: * Lists * Nested Lists * Headings * Bold * Italic * \ escaping * Quoted text and skip: * tables * links * emoji
Re: @ctfeonly
ketmar wrote: still, why `__ctfe` was designed as variable, and not as `enum ctfe = ;`? ah, sorry, i remembered. that was stupid question. the rationale is: `static if` and `static assert` are processed *before* CTFE phase. i.e. CTFE interpreter never sees them, and cannot do the choice. and on semantic analysis phase it is not known yet if the code is for CTFE or not. that is, to allow `static assert(__ctfe)` to work, the whole semantic phase must be redesigned.
Re: @ctfeonly
ketmar wrote: still, why `__ctfe` was designed as variable, and not as `enum ctfe = ;`? p.s.: i see only one reason for this rationale: to explicitly prevent people using `static if` to separate CTFE and non-CTFE code (that is, to lessen the chance than function heaves differently in runtime and in compile-time). but that doesn't work, as `if (__ctfe)` allows two completely different code pathes anyway.
Re: @ctfeonly
Walter Bright wrote:
On 12/7/2017 5:30 PM, Manu wrote:
I tried this, and was surprised it didn't work:
int ctfeOnly(int x)
{
static assert(__ctfe);
return x + 1;
}
The error is:
test2.d(3): Error: variable __ctfe cannot be read at compile time
test2.d(3):while evaluating: static assert(__ctfe)
because static asserts are evaluated when the function is semantically
analyzed, not when it is executed.
still, why `__ctfe` was designed as variable, and not as `enum ctfe = ;`?
Re: @ctfeonly
On 12/7/2017 5:30 PM, Manu wrote:
I tried this, and was surprised it didn't work:
int ctfeOnly(int x)
{
static assert(__ctfe);
return x + 1;
}
The error is:
test2.d(3): Error: variable __ctfe cannot be read at compile time
test2.d(3):while evaluating: static assert(__ctfe)
because static asserts are evaluated when the function is semantically analyzed,
not when it is executed.
Re: @ctfeonly
On 12/7/2017 5:20 PM, Manu wrote: Right, but that's what I'm saying; using your solution of putting a function in a module that's not compiled to inhibit code generation won't inhibit people from *attempting* to making runtime calls (and getting link errors)... whereas a compile error trying to runtime-call a function that shouldn't be runtime-called might be more desirable. That's exactly what happens if you put a declaration in a .h file, call the function, and don't link in the implementation. I don't see the difference.
Re: @ctfeonly
On 12/7/2017 3:41 PM, Nicholas Wilson wrote:
On Thursday, 7 December 2017 at 21:32:24 UTC, Walter Bright wrote:
On 12/7/2017 2:07 AM, Nicholas Wilson wrote:
Doesn't work for templates.
I don't know how your code is organized, but if the template is instantiated
in another file, it won't have code generated for it either.
As a trivial example:
bar.d:
module bar;
string generatesMixin(T)()
{
return T.stringof ~ " foo;";
}
a.d:
@compute(CompileFor.deviceOnly) module a;
int baz()
{
mixin(generatesMixin!int());
return foo;
}
a's symbol table contains `baz` and `generatesMixin!int`. generateMixin deals
with strings which are not allowed (global variables are unsupported). This
would fail compilation. If `generatesMixin` were to be marked `@ctfeonly`, this
would pass.
bar.d:
module bar;
string generateString(T)()
{
return T.stringof ~ " foo;";
}
enum s = generateString!int();
a.d:
@compute(CompileFor.deviceOnly) module a;
int baz()
{
import bar;
bar.s;
return foo;
}
Re: @ctfeonly
On Thu, Dec 07, 2017 at 07:20:57PM -0700, Jonathan M Davis via Digitalmars-d wrote: [...] > In spite of the fact that CTFE is done at compile time, __ctfe is a > runtime thing - it's just that it's runtime from the perspective of > CTFE. So, stuff like static if or static assert doesn't work. You have > to use if or a ternary operator or some other runtime conditional, > though it's a common misunderstanding that __ctfe is used with static > if, and people screw it up all the time. I don't know why it's a > runtime thing rather than a compile time thing though. There's > probably a good reason for it, but at first glance, it seems like a > rather weird choice. [...] Sigh: https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time T -- Everybody talks about it, but nobody does anything about it! -- Mark Twain
Re: @ctfeonly
On Thursday, December 07, 2017 17:30:13 Manu via Digitalmars-d wrote:
> On 7 December 2017 at 17:20, Manu wrote:
> > On 7 December 2017 at 13:35, Walter Bright via Digitalmars-d <
> >
> > digitalmars-d@puremagic.com> wrote:
> >> On 12/7/2017 11:41 AM, Manu wrote:
> >>> Misuse of the API; ie, a runtime call, will result in an unsuspecting
> >>> user getting a surprising link error, rather than a nice compile-time
> >>> error explaining what they did wrong...
> >>
> >> I think Nicholas is talking about functions for which code cannot be
> >> generated.
> >>
> >> In any case, in C/C++/D if you call functions in .h files (or imports)
> >> that are not linked in, you'll get a linker error.
> >
> > Right, but that's what I'm saying; using your solution of putting a
> > function in a module that's not compiled to inhibit code generation
> > won't
> > inhibit people from *attempting* to making runtime calls (and getting
> > link errors)... whereas a compile error trying to runtime-call a
> > function that shouldn't be runtime-called might be more desirable.
> > I'm not actually registering support for @ctfeonly, just that I think
> > it's a pattern that I have wanted and should be supported in some way,
> > and a compile-time error would be nicer than a link error.
>
> I tried this, and was surprised it didn't work:
>
> int ctfeOnly(int x)
> {
> static assert(__ctfe);
> return x + 1;
> }
>
> This would probably solve the problem in a satisfying way without an
> attribute?
In spite of the fact that CTFE is done at compile time, __ctfe is a runtime
thing - it's just that it's runtime from the perspective of CTFE. So, stuff
like static if or static assert doesn't work. You have to use if or a
ternary operator or some other runtime conditional, though it's a common
misunderstanding that __ctfe is used with static if, and people screw it up
all the time. I don't know why it's a runtime thing rather than a compile
time thing though. There's probably a good reason for it, but at first
glance, it seems like a rather weird choice.
- Jonathan M Davis
Re: -unittest doesn't work when linking against shared libraries
On Thursday, December 07, 2017 14:34:01 Timothee Cour via Digitalmars-d wrote: > 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? If you're trying to unit test a shared library, I'd suggest just turning it into a static library for the tests. Alternatively, you can write the unit tests in an application that links against the shared library, but that means separating the tests from the code, which isn't ideal. - Jonathan M Davis
Re: @ctfeonly
On Friday, 8 December 2017 at 01:30:13 UTC, Manu wrote:
I tried this, and was surprised it didn't work:
int ctfeOnly(int x)
{
static assert(__ctfe);
return x + 1;
}
This would probably solve the problem in a satisfying way
without an attribute?
I think that's because __ctfe, despite being magic, is actually a
regular variable.
While this looks not too inelegant for a user perspective, I dont
know how to handle this from a compiler perspective: filtering by
attribute is as easy as "does this function have a UDA ctfeonly?
If so, don't code generate it. Generating errors at codegen time
is also trivial: when generating a call check to see if the
callee is @ctfeonly, if it is give an error message
I don't know how to do that for a `static assert(__ctfe);`. That
would require changes and semantic analysis in the front end
which I am much less familiar with.
Re: Post about comparing C, C++ and D performance with a real world project
On 12/07/2017 03:07 PM, Iain Buclaw wrote:
On 7 December 2017 at 23:39, Daniel Kozak wrote:
The other slowdown is caused by concatenation. Because std::string += is
more simillar to std.array.(Ref)Appender
Correct. The semantics of ~= mean that the memory is copied around to
a new allocation every time (unless the array is marked
assumeSafeAppend).
You must have meant ~, not ~= because luckily, it is assumeSafeAppend
when there is just one slice. ~= is not that bad in that case:
import std.stdio;
void main() {
int[] a;
foreach (i; 0 .. 10) {
a ~= i;
writeln(a.ptr);
}
}
7F621818D020
7F621818D020
7F621818D020
7F621818C100
7F621818C100
7F621818C100
7F621818C100
7F621818B040
7F621818B040
7F621818B040
Ali
Re: @ctfeonly
On 7 December 2017 at 17:20, Manu wrote:
> On 7 December 2017 at 13:35, Walter Bright via Digitalmars-d <
> digitalmars-d@puremagic.com> wrote:
>
>> On 12/7/2017 11:41 AM, Manu wrote:
>>
>>> Misuse of the API; ie, a runtime call, will result in an unsuspecting
>>> user getting a surprising link error, rather than a nice compile-time error
>>> explaining what they did wrong...
>>>
>>
>> I think Nicholas is talking about functions for which code cannot be
>> generated.
>>
>> In any case, in C/C++/D if you call functions in .h files (or imports)
>> that are not linked in, you'll get a linker error.
>>
>
> Right, but that's what I'm saying; using your solution of putting a
> function in a module that's not compiled to inhibit code generation won't
> inhibit people from *attempting* to making runtime calls (and getting link
> errors)... whereas a compile error trying to runtime-call a function that
> shouldn't be runtime-called might be more desirable.
> I'm not actually registering support for @ctfeonly, just that I think it's
> a pattern that I have wanted and should be supported in some way, and a
> compile-time error would be nicer than a link error.
>
I tried this, and was surprised it didn't work:
int ctfeOnly(int x)
{
static assert(__ctfe);
return x + 1;
}
This would probably solve the problem in a satisfying way without an
attribute?
Re: @ctfeonly
On 7 December 2017 at 13:35, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On 12/7/2017 11:41 AM, Manu wrote: > >> Misuse of the API; ie, a runtime call, will result in an unsuspecting >> user getting a surprising link error, rather than a nice compile-time error >> explaining what they did wrong... >> > > I think Nicholas is talking about functions for which code cannot be > generated. > > In any case, in C/C++/D if you call functions in .h files (or imports) > that are not linked in, you'll get a linker error. > Right, but that's what I'm saying; using your solution of putting a function in a module that's not compiled to inhibit code generation won't inhibit people from *attempting* to making runtime calls (and getting link errors)... whereas a compile error trying to runtime-call a function that shouldn't be runtime-called might be more desirable. I'm not actually registering support for @ctfeonly, just that I think it's a pattern that I have wanted and should be supported in some way, and a compile-time error would be nicer than a link error.
Re: Post about comparing C, C++ and D performance with a real world project
On Thursday, 7 December 2017 at 22:39:44 UTC, Daniel Kozak wrote: The other slowdown is caused by concatenation. Because std::string += is more simillar to std.array.(Ref)Appender wait, i thought appenders performed better than concatenation. is that not true or did i just misunderstand your post?
Re: @ctfeonly
On Thursday, 7 December 2017 at 21:32:24 UTC, Walter Bright wrote:
On 12/7/2017 2:07 AM, Nicholas Wilson wrote:
Doesn't work for templates.
I don't know how your code is organized, but if the template is
instantiated in another file, it won't have code generated for
it either.
As a trivial example:
bar.d:
module bar;
string generatesMixin(T)()
{
return T.stringof ~ " foo;";
}
a.d:
@compute(CompileFor.deviceOnly) module a;
int baz()
{
mixin(generatesMixin!int());
return foo;
}
a's symbol table contains `baz` and `generatesMixin!int`.
generateMixin deals with strings which are not allowed (global
variables are unsupported). This would fail compilation. If
`generatesMixin` were to be marked `@ctfeonly`, this would pass.
Re: -unittest doesn't work when linking against shared libraries
On Thursday, 7 December 2017 at 22:34:01 UTC, Timothee Cour wrote: 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? There are a few test runners around that handle testing manually. You can try one of them or roll your own. That might fail, however. It would be worthwhile to see how it does -- is `foo` absent the runtime's list of all modules?
Re: Inheritance from multiple interfaces with the same method name
On Thursday, 7 December 2017 at 23:00:38 UTC, Mike Franklin wrote:
If you think D should support something like this, the first
thing to do is to file a bug report.
Sounds more like a DIP to me. There is no way to enable this
without some kind of nontrivial syntax. I'd go with the VB
approach and have something like
void foo1() alias I.foo { }
but that's up to the time discussing the DIP.
Re: Post about comparing C, C++ and D performance with a real world project
On 7 December 2017 at 23:39, Daniel Kozak wrote: > The other slowdown is caused by concatenation. Because std::string += is > more simillar to std.array.(Ref)Appender > Correct. The semantics of ~= mean that the memory is copied around to a new allocation every time (unless the array is marked assumeSafeAppend).
Re: Inheritance from multiple interfaces with the same method name
On Thursday, 7 December 2017 at 21:12:30 UTC, Q. Schroll wrote: This implies that I cannot implement two syntactically identical methods with different implementations, like if J had void f(); too, I cannot have different implementations for I.f() and J.f(). That would be relevant if they should behave differently e.g. if they have conflicting contracts. Yes, you are right. I think it would be nice if D supported a way to disambiguate the definitions like C# does, by fully qualifying the names. But, it's a very rare situation. If you think D should support something like this, the first thing to do is to file a bug report. Mike
Re: Post about comparing C, C++ and D performance with a real world project
The other slowdown is caused by concatenation. Because std::string += is more simillar to std.array.(Ref)Appender Dne 7. 12. 2017 11:33 odp. napsal uživatel "Daniel Kozak" : > Yes, it reuse the same pointer. But it still a little bit slower than > accessing stack memory > > Dne 7. 12. 2017 11:04 odp. napsal uživatel "Iain Buclaw via Digitalmars-d" > : > > On 7 December 2017 at 20:56, Steven Schveighoffer via Digitalmars-d > wrote: > > On 12/7/17 1:26 PM, Daniel Kozak wrote: > >> > >> This is not about write the best D code. It is about similar code to > >> perform same. However when I looked at the D code it is not good port of > >> C/C++. He made many mistakes which make it slower than C/C++ > counterpart. > >> One example is read_one_line function: > >> C++: https://github.com/jpakkane/pkg-config/blob/cpp/parse.cpp#L60 > >> D: https://github.com/jpakkane/pkg-config/blob/d/parse.d#L57 > > > > > > Wow, interesting that D uses less memory with that continue new char[1] > in > > there! > > > > I would have thought that it just reuses the same pointer to the GC on > each loop. > > >
-unittest doesn't work when linking against shared libraries
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?
Re: Post about comparing C, C++ and D performance with a real world project
Yes, it reuse the same pointer. But it still a little bit slower than accessing stack memory Dne 7. 12. 2017 11:04 odp. napsal uživatel "Iain Buclaw via Digitalmars-d" < digitalmars-d@puremagic.com>: On 7 December 2017 at 20:56, Steven Schveighoffer via Digitalmars-d wrote: > On 12/7/17 1:26 PM, Daniel Kozak wrote: >> >> This is not about write the best D code. It is about similar code to >> perform same. However when I looked at the D code it is not good port of >> C/C++. He made many mistakes which make it slower than C/C++ counterpart. >> One example is read_one_line function: >> C++: https://github.com/jpakkane/pkg-config/blob/cpp/parse.cpp#L60 >> D: https://github.com/jpakkane/pkg-config/blob/d/parse.d#L57 > > > Wow, interesting that D uses less memory with that continue new char[1] in > there! > I would have thought that it just reuses the same pointer to the GC on each loop.
Re: @ctfeonly
On 7 December 2017 at 03:09, lobo via Digitalmars-d wrote: > On Thursday, 7 December 2017 at 01:21:11 UTC, Nicholas Wilson wrote: >> >> I'd like to add an attribute to indicate that the annotated function is >> only available at compile time so that in cases where the operation is >> invalid at runtime (strings and concatenation on a GPU for instance) but the >> result is only used at compile time (for a mixin) the compiler is free to >> not codegen that function. >> >> I can add this to LDC pretty easily, but does anyone else have a use for >> this (e.g. shrinking binary sizes for mixin heavy codebases) and would >> benefit having this as a standard thing? > > > Shouldn't the linker do this already? > > Once the compiler has CTFE'd the function any call in the code should be > replaced with the function evaluation. The linker should then drop the code > out of the binary because it really is dead code. > It should be possible to add heuristics for this (mark a function as being instantiated and only used at compile-time). It just doesn't exist yet. As for normal functions, regardless of protection, they will always be compiled as a function visible outside the CU. You're either going to rely on LTO support in the compiler, kindly request that DIP45 be given another thought, or write a new DIP that considers another way to control symbol visibility. But I wouldn't hold my breath on anything happening soon.
Re: Post about comparing C, C++ and D performance with a real world project
On 7 December 2017 at 20:56, Steven Schveighoffer via Digitalmars-d wrote: > On 12/7/17 1:26 PM, Daniel Kozak wrote: >> >> This is not about write the best D code. It is about similar code to >> perform same. However when I looked at the D code it is not good port of >> C/C++. He made many mistakes which make it slower than C/C++ counterpart. >> One example is read_one_line function: >> C++: https://github.com/jpakkane/pkg-config/blob/cpp/parse.cpp#L60 >> D: https://github.com/jpakkane/pkg-config/blob/d/parse.d#L57 > > > Wow, interesting that D uses less memory with that continue new char[1] in > there! > I would have thought that it just reuses the same pointer to the GC on each loop.
Re: @ctfeonly
Am Thu, 7 Dec 2017 13:38:54 -0800 schrieb Walter Bright : > On 12/6/2017 11:41 PM, Mike Franklin wrote: > > On Thursday, 7 December 2017 at 04:45:15 UTC, Jonathan M Davis > > wrote: > >> The simplest way to do that is to write a unit test that uses a > >> static assertion. As I understand it, with the way CTFE works, it > >> pretty much can't know whether a function can be called at compile > >> time until it tries, but a unit test can catch it if the function > >> no longer works at compile time. > > > > Not bad, but that is swaying into the cumbersome category. If > > that's the best we can do, a @ctfeonly attribute starts looking > > pretty good. > > More and more attributes to do essentially trivial things is > cumbersomeness all on its own. I think this is more of an optimization UDA than a standard attribute. So it's similar to all the noinline, forceinline, weak, section etc. attributes: https://wiki.dlang.org/Using_GDC#Attributes -- Johannes
Re: @ctfeonly
Am Thu, 07 Dec 2017 01:32:35 -0700 schrieb Jonathan M Davis : > > In the vast majority of cases, when a function is used for CTFE, it's > also used during runtime. So, in most cases, you want to ensure that > a function works both with CTFE and without, and in those cases > something like @ctfeonly wouldn't make any sense. In my experience, > pretty much the only time that something like @ctfeonly would make > any sense would be with a function for generating a string mixin. Not only string mixins. When programming for microcontrollers you want to do as much in CTFE as possible, as space for executable code is severely limited. So you may for example want to use CTFE to generate some lookup tables and similar stuff. Basically the whole 'initialize a variable / constant using CTFE' idiom benefits a lot from such an attribute. -- Johannes
Re: @ctfeonly
Am Wed, 06 Dec 2017 20:18:57 -0700 schrieb Jonathan M Davis : > Folks have talked about all kinds of template code and stuff being > kept around in binaries even though it was only used at compile time > (e.g. stuff like isInputRange), but I don't know how much that's > actually true. You probably never call isInputRange at runtime, so the code is likely stripped. However, TypeInfo of structs used only at CTFE is still generated and not stripped. I remember we once had this problem with gcc.attribute, a module which shouldn't generate any code but generated useless TypeInfo. -- Johannes
Re: @ctfeonly
Am Thu, 7 Dec 2017 05:55:54 +0200
schrieb ketmar :
> ketmar wrote:
>
> > Nicholas Wilson wrote:
> >
> >> Also not generating the code in the first place means less I/O for
> >> the compiler and less work for the linker.
> > this is solvable without any additional flags, tho: compiler should
> > just skip codegen phase for any function that is not referenced by
> > another compiled function (except for library case).
>
> p.s.: actually, dmd already creates .a files suitable for
> smartlinking (otherwise any binary would include the whole
> libphobos2.a ;-). but for "dmd mycode.d" dmd doesn't do this ('cause
> it is quite compilcated for non-library case). the whole issue prolly
> can be solved by "generate smart object files for linking" flag
> (which will create .a files for everything, so linker can do it's
> smart work).
AFAIK there's a design flaw in D which prevents a compiler from
doing any such operations without additional user input:
Currently you can write code like this:
---
module mod;
private int thisIsNeverUsed()
{
return 42;
}
private int thisIsUsed(int a)
{
return 42 + a;
}
int someTemplate(T)(T t)
{
return t.thisIsUsed();
}
---
Whether thisIsUsed and thisIsNeverUsed actually have to appear in the
object file depends on how someTemplate is instantiated. Generally, when
compiling module mod you can never know whether thisIsUsed or
thisIsNeverUsed are actually required. You can not evaluate the
someTemplate template without specifying a concrete type for T.
This means neither the compiler nor the linker can remove seemingly
unused, private functions. For GDC this means we simply mark all
functions as TREE_PUBLIC in the GCC backend.
Note that this is also an issue for exporting templates from DLLs on
windows. I think the DLL DIP which requires to mark private functions
as 'export' if they are used outside outside of the module (even via
templates) will fix this problem and allow for some nice optimizations.
Until then, smart linking isn't really possible.
BTW: The private/export combination probably still wouldn't solve all
problems: Maybe you want to mark the whole module as @nogc. @nogc
checking is done in semantic phase, so it will still error about GC
usage in functions which later turn out to be only used in CTFE.
Detecting this in the linker or compiler backend is too late. So we'd
have to detect unexported, unused private functions in semantic. I'm
not sure if this is feasible or whether a simple @ctfeonly UDA isn't
much simpler to implement.
Additionally @ctfeonly documents intended usage and allows for nice
error messages when using a function at runtime. Relying on the linker
to remove private, unexported functions can break easily.
-- Johannes
Re: @ctfeonly
On 12/6/2017 11:41 PM, Mike Franklin wrote: On Thursday, 7 December 2017 at 04:45:15 UTC, Jonathan M Davis wrote: The simplest way to do that is to write a unit test that uses a static assertion. As I understand it, with the way CTFE works, it pretty much can't know whether a function can be called at compile time until it tries, but a unit test can catch it if the function no longer works at compile time. Not bad, but that is swaying into the cumbersome category. If that's the best we can do, a @ctfeonly attribute starts looking pretty good. More and more attributes to do essentially trivial things is cumbersomeness all on its own.
Re: Post about comparing C, C++ and D performance with a real world project
Yes using FILE* directly could be the way. But using file.rawRead is still possible. But it is better to use static array with length one. Other problem is with string. It would make sense make it out instead of ref and change it to empty string and use RefAppender. Dne 7. 12. 2017 9:00 odp. napsal uživatel "Steven Schveighoffer via Digitalmars-d" : > On 12/7/17 1:26 PM, Daniel Kozak wrote: > >> This is not about write the best D code. It is about similar code to >> perform same. However when I looked at the D code it is not good port of >> C/C++. He made many mistakes which make it slower than C/C++ counterpart. >> One example is read_one_line function: >> C++: https://github.com/jpakkane/pkg-config/blob/cpp/parse.cpp#L60 >> D: https://github.com/jpakkane/pkg-config/blob/d/parse.d#L57 >> > > Wow, interesting that D uses less memory with that continue new char[1] in > there! > > Kind of funny that he didn't just use FILE * directly, it's totally > available in D :) > > -Steve >
Re: @ctfeonly
On 12/7/2017 2:07 AM, Nicholas Wilson wrote: Doesn't work for templates. I don't know how your code is organized, but if the template is instantiated in another file, it won't have code generated for it either.
Re: @ctfeonly
On 12/7/2017 11:41 AM, Manu wrote: Misuse of the API; ie, a runtime call, will result in an unsuspecting user getting a surprising link error, rather than a nice compile-time error explaining what they did wrong... I think Nicholas is talking about functions for which code cannot be generated. In any case, in C/C++/D if you call functions in .h files (or imports) that are not linked in, you'll get a linker error.
Re: Inheritance from multiple interfaces with the same method name
On Thursday, 7 December 2017 at 15:14:48 UTC, Adam D. Ruppe wrote: On Thursday, 7 December 2017 at 00:45:21 UTC, Mike Franklin wrote: // Error: A.f called with argument types () matches both: A.f() and A.f() // Yeah, that error message could be better. //a.f(); (cast(I)a).f(); // prints "void f()" (cast(J)a).f(); // prints "int f()" D also allows you to simply write: a.I.f(); a.J.f(); also works for explicitly calling a base class implementation btw This implies that I cannot implement two syntactically identical methods with different implementations, like if J had void f(); too, I cannot have different implementations for I.f() and J.f(). That would be relevant if they should behave differently e.g. if they have conflicting contracts.
Re: Advanced code coverage analysis
On Wednesday, 6 December 2017 at 06:05:32 UTC, Basile B. wrote: Indeed, but there's still some room for a tool. I'd add this to my IDE since for now coverage is not indicated in the code editor but in the messages (a message for each line that's not covered). Anyway it's a two days project (at most), i've proposed it to D-Scanner: https://github.com/dlang-community/D-Scanner/issues/540 Having tooling support for advanced coverage analysis would make D more interesting to people in the industrial domain. Some other aspects would need attention as well (garbage collection). However I am looking forward to the DConf 2018 and I am curious about the future development of D and its ecosystem...
Re: Advanced code coverage analysis
On Tuesday, 5 December 2017 at 12:39:53 UTC, Johan Engelen wrote: LDC's PGO output can be used for that. See [1]. Except that LDC does not yet output full source mappings for the counters (`-fcoverage-mapping`). Because the DMD frontend rewrites code besides semantic analysis, it is problematic to create correct source mappings, and I have thusfar refrained from implementing that. (For folks interested in contributing to LDC: it'd be a nice project to work on, with nice incremental steps. It's quite possible that there is already enough info in the IR for IR-based (instead of current PGO instrumentation) instrumentation/mapping to work well) Advanced code coverage would have been a nice to have. Especially in the technical and/or embedded domain where DMD is in most cases no option anyway (LDC or GDC are the two choices here). Unfortunately other projects have higher priority for me right now.
Re: @ctfeonly
On 7 December 2017 at 01:34, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On 12/6/2017 5:21 PM, Nicholas Wilson wrote: > >> I'd like to add an attribute to indicate that the annotated function is >> only available at compile time so that in cases where the operation is >> invalid at runtime (strings and concatenation on a GPU for instance) but >> the result is only used at compile time (for a mixin) the compiler is free >> to not codegen that function. >> > > Put these functions into a separate import. Then import the file and use > the functions at compile time. They will not have code generated for them. > Misuse of the API; ie, a runtime call, will result in an unsuspecting user getting a surprising link error, rather than a nice compile-time error explaining what they did wrong...
Re: Post about comparing C, C++ and D performance with a real world project
On 12/7/17 1:26 PM, Daniel Kozak wrote: This is not about write the best D code. It is about similar code to perform same. However when I looked at the D code it is not good port of C/C++. He made many mistakes which make it slower than C/C++ counterpart. One example is read_one_line function: C++: https://github.com/jpakkane/pkg-config/blob/cpp/parse.cpp#L60 D: https://github.com/jpakkane/pkg-config/blob/d/parse.d#L57 Wow, interesting that D uses less memory with that continue new char[1] in there! Kind of funny that he didn't just use FILE * directly, it's totally available in D :) -Steve
Re: Post about comparing C, C++ and D performance with a real world project
This is not about write the best D code. It is about similar code to perform same. However when I looked at the D code it is not good port of C/C++. He made many mistakes which make it slower than C/C++ counterpart. One example is read_one_line function: C++: https://github.com/jpakkane/pkg-config/blob/cpp/parse.cpp#L60 D: https://github.com/jpakkane/pkg-config/blob/d/parse.d#L57 On Thu, Dec 7, 2017 at 3:37 PM, Russel Winder via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > So who is going to do the experiment and write the best D code to solve > the problem, write the rebuttal article, and post it? > > It is good to get emotion going on the email list, but without external > action D gets no positive marketing. > > -- > Russel. > === > Dr Russel Winder t: +44 20 7585 2200 > 41 Buckmaster Roadm: +44 7770 465 077 > London SW11 1EN, UK w: www.russel.org.uk >
Re: move an argument tuple
On Thursday, 7 December 2017 at 08:19:25 UTC, Shachar Shemesh
wrote:
Hi everybody,
I'm trying to have a templated function like so:
void func(alias F)(Parameters!F args) {
At some point in func, I want to call F with args:
F(args);
This does not work if one of args is a struct with copying
disabled. That's fine. What I'd like to do is to move it into F:
F( move(args) );
Except that only works if args.length==1. If args.length==2, it
thinks I'm calling the move overload that moves from the first
argument to the second, and then it complains that F cannot be
called with void argument.
Things that also don't work:
F( moveAll(args) );
That one accepts two ranges and expects to copy between them.
I guess I can put up a mixin that expands to:
F( move(args[0]), move(args[1]) );
I'd really like a cleaner solution if one is possible.
Thanks,
Shachar
import std.traits: Parameters;
import std.stdio: writeln;
import std.functional: forward;
struct Foo {
int i;
@disable this(this);
}
auto add(Foo f, Foo g) {
return f.i + g.i;
}
void main() {
func!add(Foo(1), Foo(2));
}
void func(alias F)(Parameters!F args) {
writeln(F(forward!args));
}
Re: Post about comparing C, C++ and D performance with a real world project
So who is going to do the experiment and write the best D code to solve the problem, write the rebuttal article, and post it? It is good to get emotion going on the email list, but without external action D gets no positive marketing. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Adding Markdown to Ddoc
On Wednesday, 6 December 2017 at 04:11:33 UTC, Walter Bright wrote: https://help.github.com/articles/basic-writing-and-formatting-syntax/ I think you'll find it is easier said than done to get sane output given existing ddoc pages. My adrdox does some of this special syntax and to maintain compatibility with Phobos, I had to do some recursive action inside macros and ddoc sections to keep the generated html from being totally bogus. Of course, if you're willing to do some cleanup work on the Phobos source code, this can be greatly simplified too (indeed, for adrdox, i did fork some of it, but keeping it up to date was actually harder as a fork than just adding another hack to my parser, so i went that way too). https://help.github.com/articles/basic-writing-and-formatting-syntax/#paragraphs-and-line-breaks this rule in particular takes quite a bit to make sane with ddoc hybrid stuff! PS of course yall could also just surrender to me and use my superior system. I'm not actually a fan of markdown syntax though so i don't quite follow it and do other custom extensions which has rustled some feathers in the past.
Re: minimal object.d implementation that allows classes
On 12/7/17 10:45 AM, Jean-Louis Leroy wrote: On Thursday, 7 December 2017 at 15:34:09 UTC, Steven Schveighoffer wrote: On 12/7/17 10:21 AM, Jean-Louis Leroy wrote: Bar.classinfo.vtbl.ptr[Bar.classinfo.vtbl.length] = cast(void*) 0x123456; This is a buffer overflow, why are you doing this specifically? -Steve It's not an overflow because of the call to `reserve`. It is part of an experiment related to supporting user-defined per-class metadata by extending the vtable. Ah, ok. Take care, I'm not sure that the classinfo instances are scanned by the GC. Might be better to use C malloc. -Steve
Re: Inheritance from multiple interfaces with the same method name
On Thursday, 7 December 2017 at 15:14:48 UTC, Adam D. Ruppe wrote:
D also allows you to simply write:
a.I.f();
a.J.f();
also works for explicitly calling a base class implementation
btw
It would be nice if you could do something like below (I know you
can do something similar with std.conv.to).
void main()
{
import std.stdio : writeln;
float x = 2.5;
writeln(cast(int)x);
writeln(x.cast(int));
writeln(x.int);
}
Re: minimal object.d implementation that allows classes
On Thursday, 7 December 2017 at 15:34:09 UTC, Steven Schveighoffer wrote: On 12/7/17 10:21 AM, Jean-Louis Leroy wrote: Bar.classinfo.vtbl.ptr[Bar.classinfo.vtbl.length] = cast(void*) 0x123456; This is a buffer overflow, why are you doing this specifically? -Steve It's not an overflow because of the call to `reserve`. It is part of an experiment related to supporting user-defined per-class metadata by extending the vtable.
Re: minimal object.d implementation that allows classes
On 12/7/17 10:21 AM, Jean-Louis Leroy wrote: Bar.classinfo.vtbl.ptr[Bar.classinfo.vtbl.length] = cast(void*) 0x123456; This is a buffer overflow, why are you doing this specifically? -Steve
Re: Adding Markdown to Ddoc
On Wednesday, 6 December 2017 at 04:11:33 UTC, Walter Bright wrote: https://help.github.com/articles/basic-writing-and-formatting-syntax/ Anyone interested in picking up the flag? (I know this has come up before, and I've been opposed to it, but I've changed my mind.) Great to hear this! :) [Pandoc](http://pandoc.org/) is an excellent widely-used markdown implementation to emulate (or use directly); they support thoughtful additional syntax for definition lists, tables, mathematics, and a few other niceties (including syntax highlighting for D code blocks).
Re: minimal object.d implementation that allows classes
On Thursday, 7 December 2017 at 15:09:45 UTC, Jean-Louis Leroy
wrote:
On Thursday, 7 December 2017 at 14:59:57 UTC, Steven
Schveighoffer wrote:
The object is constructed here: [...]
Thanks for the pointers, you've saved me a lot of time :)
On a side note however, you really shouldn't change data in a
ClassInfo at all, and probably the compiler shouldn't let you!
This experiment is related to an ongoing discussion with
Walter, Andrei and Ali on extending D with general mechanisms
to better support libraries like openmethods. I will post in
Studies soon.
Cool:
import std.stdio;
class Foo {
abstract void report();
}
class Bar : Foo {
override void report() { writeln("I'm fine!"); }
}
void main() {
auto oldPtr = Bar.classinfo.vtbl.ptr;
Bar.classinfo.vtbl.reserve(1000);
Bar.classinfo.vtbl.ptr[Bar.classinfo.vtbl.length] = cast(void*)
0x123456;
writeln(oldPtr != Bar.classinfo.vtbl.ptr); // true
*cast(void***) Bar.classinfo.m_init.ptr =
Bar.classinfo.vtbl.ptr;
Foo foo = new Bar();
writeln(oldPtr == *cast(void***)foo); // false
foo.report(); // I'm fine!
writeln((*cast(void***)foo)[Bar.classinfo.vtbl.length]); //
123456
}
Re: Inheritance from multiple interfaces with the same method name
On Thursday, 7 December 2017 at 00:45:21 UTC, Mike Franklin wrote: // Error: A.f called with argument types () matches both: A.f() and A.f() // Yeah, that error message could be better. //a.f(); (cast(I)a).f(); // prints "void f()" (cast(J)a).f(); // prints "int f()" D also allows you to simply write: a.I.f(); a.J.f(); also works for explicitly calling a base class implementation btw
Re: minimal object.d implementation that allows classes
On Thursday, 7 December 2017 at 14:59:57 UTC, Steven Schveighoffer wrote: The object is constructed here: [...] Thanks for the pointers, you've saved me a lot of time :) On a side note however, you really shouldn't change data in a ClassInfo at all, and probably the compiler shouldn't let you! This experiment is related to an ongoing discussion with Walter, Andrei and Ali on extending D with general mechanisms to better support libraries like openmethods. I will post in Studies soon.
Re: minimal object.d implementation that allows classes
On 12/7/17 9:45 AM, Jean-Louis Leroy wrote:
On Thursday, 7 December 2017 at 13:08:09 UTC, Luís Marques wrote:
On Thursday, 7 December 2017 at 08:59:08 UTC, Wild wrote:
You could modify the one I use for PowerNex[1]. It is a hacked
version of Adam D. Ruppes
minimal.zip. There are only a few imports for strlen,
mem{set,move,cpy}, etc.
This one seems to be the one for me. For instance, typeid(ClassName)
seems to work, which I need.
For completeness, I had looked into minlibd but it didn't seemed
compatible with LDC and difficult for me to fix, IIRC. Regarding
Mike's question of what my use case is, I wanted my program to run in
webassembly/asmjs. Since druntime/phobos haven't been ported to that
target, I was being careful with my design to not depend on the
runtime, but then I found out I love the openmethods package. So I
decided to check if I could implement just enough of druntime to allow
a forked version of openmethods to work. As far as I can tell that's
feasible.
I am currently trying to understand how the compiler and the runtime
interact. ClassInfo contains a vtbl array whose ptr property is the same
as the vptr found in an instance of that class. However, when I modify
that pointer (e.g. by reserving 1000 more entries) and create a new
instance, it still contains the old pointer. So it looks like the
compiler sets the vptr without consulting the ClassInfo but somehow
reflects it there. I'd appreciate if anybody can explain how it works,
or sends me links to relevant info.
Example:
import std.stdio;
class Foo {
void foo() {}
}
void main() {
auto oldPtr = Foo.classinfo.vtbl.ptr;
Foo.classinfo.vtbl.reserve(1000);
writeln(oldPtr != Foo.classinfo.vtbl.ptr); // true
Object foo = new Foo();
writeln(oldPtr == *cast(void***)foo); // true, alas
}
The object is constructed here:
https://github.com/dlang/druntime/blob/master/src/rt/lifetime.d#L71
specifically, the vtbl is set when you blit the initializer array
(another piece of the TypeInfo) into the class object here:
https://github.com/dlang/druntime/blob/master/src/rt/lifetime.d#L115
So basically, the reason why it happens is because the pointer you are
changing is not the piece that actually is used to intialize the block.
On a side note however, you really shouldn't change data in a ClassInfo
at all, and probably the compiler shouldn't let you! This is static
readonly data, and changing this is I think even disallowed on some OSes.
Relevant source of how vtbls in D work:
https://dlang.org/spec/abi.html#classes
-Steve
Re: minimal object.d implementation that allows classes
On Wednesday, 6 December 2017 at 18:32:11 UTC, Luís Marques wrote: On Wednesday, 6 December 2017 at 17:52:16 UTC, Eugene Wissner wrote: http://arsdnet.net/dcode/minimal.zip ? I tried that one, but I was having trouble getting it to work (it seems to have bit rotten), and it does much more than I need, which probably is adding to the work to fix it. Yeah, minimal.zip is getting a bit old, but most the changes should be fairly small - adjusting sizes mainly. I just haven't done that for a year or two. The basic process is compile and link, if something doesn't work, copy/paste enough in to make the error go away. Sizes can be gotten from real druntime with __traits(classInstanceSize) and such, then you put in a dummy buffer to pad to it (remembering the vptr and monitor already get tou part of the way there). minimal.zip does a bit more than the bare minimum, but polymorphic classes DO require a fair chunk of code - various typeinfo and cast functions, some kind of memory function - and some of that code requires other code like struct typeinfo too (ugh, but the compiler insists). minimal.zip also includes exceptions and some startup stuff but that's mostly just because such were easy after polymorphism worked so I did because I can. Of course, if targetting webassembly, you can prolly cut all that out and rely on the javascript plumbing instead (i think). Certainly the asm functions will need to be cut there.
Re: minimal object.d implementation that allows classes
On Thursday, 7 December 2017 at 13:08:09 UTC, Luís Marques wrote:
On Thursday, 7 December 2017 at 08:59:08 UTC, Wild wrote:
You could modify the one I use for PowerNex[1]. It is a hacked
version of Adam D. Ruppes
minimal.zip. There are only a few imports for strlen,
mem{set,move,cpy}, etc.
This one seems to be the one for me. For instance,
typeid(ClassName) seems to work, which I need.
For completeness, I had looked into minlibd but it didn't
seemed compatible with LDC and difficult for me to fix, IIRC.
Regarding Mike's question of what my use case is, I wanted my
program to run in webassembly/asmjs. Since druntime/phobos
haven't been ported to that target, I was being careful with my
design to not depend on the runtime, but then I found out I
love the openmethods package. So I decided to check if I could
implement just enough of druntime to allow a forked version of
openmethods to work. As far as I can tell that's feasible.
I am currently trying to understand how the compiler and the
runtime interact. ClassInfo contains a vtbl array whose ptr
property is the same as the vptr found in an instance of that
class. However, when I modify that pointer (e.g. by reserving
1000 more entries) and create a new instance, it still contains
the old pointer. So it looks like the compiler sets the vptr
without consulting the ClassInfo but somehow reflects it there.
I'd appreciate if anybody can explain how it works, or sends me
links to relevant info.
Example:
import std.stdio;
class Foo {
void foo() {}
}
void main() {
auto oldPtr = Foo.classinfo.vtbl.ptr;
Foo.classinfo.vtbl.reserve(1000);
writeln(oldPtr != Foo.classinfo.vtbl.ptr); // true
Object foo = new Foo();
writeln(oldPtr == *cast(void***)foo); // true, alas
}
...at least that's what I get with dmd.
Re: Post about comparing C, C++ and D performance with a real world project
On 12/7/17 6:46 AM, Daniel Kozak wrote: Not much helpful, still does not know which compiler flags have been used, or how I can reproduce this. It would be nice to have some shell script which will compile it and run it in a same manner as a original author https://github.com/jpakkane/pkg-config/blob/d/meson.build This should give an idea of the flags. Not sure exactly what it means, but I assume there's a way to increase verbosity and see exactly the flags being sent to gdc. -Steve
Re: minimal object.d implementation that allows classes
On Thursday, 7 December 2017 at 08:59:08 UTC, Wild wrote:
You could modify the one I use for PowerNex[1]. It is a hacked
version of Adam D. Ruppes
minimal.zip. There are only a few imports for strlen,
mem{set,move,cpy}, etc.
This one seems to be the one for me. For instance,
typeid(ClassName) seems to work, which I need.
For completeness, I had looked into minlibd but it didn't seemed
compatible with LDC and difficult for me to fix, IIRC. Regarding
Mike's question of what my use case is, I wanted my program to
run in webassembly/asmjs. Since druntime/phobos haven't been
ported to that target, I was being careful with my design to not
depend on the runtime, but then I found out I love the
openmethods package. So I decided to check if I could implement
just enough of druntime to allow a forked version of openmethods
to work. As far as I can tell that's feasible.
Re: Post about comparing C, C++ and D performance with a real world project
On Thursday, 7 December 2017 at 12:00:00 UTC, Jonathan M Davis wrote: On Thursday, December 07, 2017 09:55:56 Antonio Corbi via Digitalmars-d wrote: Hello all, Jussi Pakkanen (one of the meson build system creators) has written a post comparing C, C++ and D. Worth a read. http://nibblestew.blogspot.com.es/2017/12/comparing-c-c-and-d-performance-> with.html [...] I do wonder what the results would look like with clang and ldc though, particularly since the version of gdc in Ubuntu is going to be pretty old. Yes and the GDC version also explains the 7 leaks. These are quite certainly some old druntime bugs.
Re: Post about comparing C, C++ and D performance with a real world project
On my machine D is faster than his c++ version, so It does look good. I use his own repository so I do not know why his results are so different in my case: his c++ version with gcc: real 0m0,021s user 0m0,021s sys 0m0,000s his D version with DMD: real 0m0,018s user 0m0,015s sys 0m0,004s his D version with GDC: real 0m0,015s user 0m0,006s sys 0m0,010s his D version with LDC: real 0m0,030s user 0m0,025s sys 0m0,005s LDC is slower because on my system it use shared phobos library, so it takes some time to load it. all others (gcc,gdc and dmd use static libs) When I use shared phobos for dmd, I get real 0m0,032s user 0m0,024s sys 0m0,009s On Thu, Dec 7, 2017 at 1:00 PM, Jonathan M Davis via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Thursday, December 07, 2017 09:55:56 Antonio Corbi via Digitalmars-d > wrote: > > Hello all, > > > > Jussi Pakkanen (one of the meson build system creators) has > > written a post comparing C, C++ and D. Worth a read. > > > > http://nibblestew.blogspot.com.es/2017/12/comparing-c-c- > and-d-performance-> with.html > > Honestly, I find the results a bit depressing, but a lot of that probably > stems from the fact that it's not idiomatic D code, and any time you do > more > or less direct conversions, you run the risk of things not working as > efficiently due to differences in the languages involved. The author does > acknowledge that, but without refactoring the code to be more idiomatic, it > makes D look bad - though the fact that it does better with memory than C > or > C++ does make the GC look better than you'd necessarily expect. It's > certainly surprising that the GC is the _good_ part of the results. > > I do wonder what the results would look like with clang and ldc though, > particularly since the version of gdc in Ubuntu is going to be pretty old. > It might make no difference at all, or there could be a definite > improvement, depending on what his code is doing and what has changed since > the last gdc release. > > - Jonathan M Davis > >
Re: Post about comparing C, C++ and D performance with a real world project
Not much helpful, still does not know which compiler flags have been used, or how I can reproduce this. It would be nice to have some shell script which will compile it and run it in a same manner as a original author On Thu, Dec 7, 2017 at 12:35 PM, Antonio Corbi via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Thursday, 7 December 2017 at 10:33:59 UTC, Timothee Cour wrote: > >> 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 < >> digitalmars-d@puremagic.com> wrote: >> >>> Hello all, >>> >>> Jussi Pakkanen (one of the meson build system creators) has written a >>> post comparing C, C++ and D. Worth a read. >>> >>> http://nibblestew.blogspot.com.es/2017/12/comparing-c-c-and- >>> d-performance-with.html >>> >>> Antonio. >>> >> > The code is in the github repo mentioned there. It has several branches. > The application is built using meson (http://mesonbuild.com/). > > Antonio >
Re: Post about comparing C, C++ and D performance with a real world project
On Thursday, December 07, 2017 09:55:56 Antonio Corbi via Digitalmars-d wrote: > Hello all, > > Jussi Pakkanen (one of the meson build system creators) has > written a post comparing C, C++ and D. Worth a read. > > http://nibblestew.blogspot.com.es/2017/12/comparing-c-c-and-d-performance-> > with.html Honestly, I find the results a bit depressing, but a lot of that probably stems from the fact that it's not idiomatic D code, and any time you do more or less direct conversions, you run the risk of things not working as efficiently due to differences in the languages involved. The author does acknowledge that, but without refactoring the code to be more idiomatic, it makes D look bad - though the fact that it does better with memory than C or C++ does make the GC look better than you'd necessarily expect. It's certainly surprising that the GC is the _good_ part of the results. I do wonder what the results would look like with clang and ldc though, particularly since the version of gdc in Ubuntu is going to be pretty old. It might make no difference at all, or there could be a definite improvement, depending on what his code is doing and what has changed since the last gdc release. - Jonathan M Davis
Re: Post about comparing C, C++ and D performance with a real world project
On Thursday, 7 December 2017 at 10:33:59 UTC, Timothee Cour wrote: 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, C++ and D. Worth a read. http://nibblestew.blogspot.com.es/2017/12/comparing-c-c-and-d-performance-with.html Antonio. The code is in the github repo mentioned there. It has several branches. The application is built using meson (http://mesonbuild.com/). Antonio
Re: Post about comparing C, C++ and D performance with a real world project
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, C++ and D. Worth a read. > > http://nibblestew.blogspot.com.es/2017/12/comparing-c-c-and-d-performance-with.html > > Antonio.
Re: Adding Markdown to Ddoc
On 2017-12-06 05:11, Walter Bright wrote: https://help.github.com/articles/basic-writing-and-formatting-syntax/ Anyone interested in picking up the flag? (I know this has come up before, and I've been opposed to it, but I've changed my mind.) Finally :), this is awesome. Should we implement standard markdown, GitHub markdown or some other extension? -- /Jacob Carlborg
Re: @ctfeonly
On Thursday, 7 December 2017 at 09:34:51 UTC, Walter Bright wrote: On 12/6/2017 5:21 PM, Nicholas Wilson wrote: I'd like to add an attribute to indicate that the annotated function is only available at compile time so that in cases where the operation is invalid at runtime (strings and concatenation on a GPU for instance) but the result is only used at compile time (for a mixin) the compiler is free to not codegen that function. Put these functions into a separate import. Then import the file and use the functions at compile time. They will not have code generated for them. Doesn't work for templates.
Post about comparing C, C++ and D performance with a real world project
Hello all, Jussi Pakkanen (one of the meson build system creators) has written a post comparing C, C++ and D. Worth a read. http://nibblestew.blogspot.com.es/2017/12/comparing-c-c-and-d-performance-with.html Antonio.
Re: @ctfeonly
On Thursday, 7 December 2017 at 01:21:11 UTC, Nicholas Wilson wrote: I'd like to add an attribute to indicate that the annotated function is only available at compile time so that in cases where the operation is invalid at runtime (strings and concatenation on a GPU for instance) but the result is only used at compile time (for a mixin) the compiler is free to not codegen that function. I can add this to LDC pretty easily, but does anyone else have a use for this (e.g. shrinking binary sizes for mixin heavy codebases) and would benefit having this as a standard thing? I once tried to use dmd's -vgc option but it is not so useful when all CTFE funtions to generate D code trigger warnings about GC alcoations. I think such an attribute would silence this warnings, dmd -vgc would be much cleaner then.
Re: @ctfeonly
On 12/6/2017 5:21 PM, Nicholas Wilson wrote: I'd like to add an attribute to indicate that the annotated function is only available at compile time so that in cases where the operation is invalid at runtime (strings and concatenation on a GPU for instance) but the result is only used at compile time (for a mixin) the compiler is free to not codegen that function. Put these functions into a separate import. Then import the file and use the functions at compile time. They will not have code generated for them.
Re: minimal object.d implementation that allows classes
On Wednesday, 6 December 2017 at 17:17:40 UTC, Luís Marques wrote: Is there a small druntime/object.d implementation that allows basic support for classes, without bringing the whole druntime implementation with it? I can get away with just this (https://github.com/JinShil/stm32f42_discovery_demo/blob/master/source/runtime/object.d) in GDC. It will likely cause LDC to crash (See https://github.com/ldc-developers/ldc/issues/781, https://github.com/ldc-developers/ldc/issues/552). I haven't tested it with DMD. But, I'm not really using classes in the typical way. Instead, I'm more-or-less using them as namespaces with static polymorphism. For an example, see https://github.com/JinShil/stm32f42_discovery_demo/blob/master/source/stm32f42/pwr.d What you need in object.d will likely depend on how you intend to use your classes. What's your use case? Mike
Re: minimal object.d implementation that allows classes
On Wednesday, 6 December 2017 at 17:17:40 UTC, Luís Marques wrote:
Is there a small druntime/object.d implementation that allows
basic support for classes, without bringing the whole druntime
implementation with it?
You could modify the one I use for PowerNex[1]. It is a hacked
version of Adam D. Ruppes
minimal.zip. There are only a few imports for strlen,
mem{set,move,cpy}, etc.
You probably need to add some sort of entrypoint and maybe
implement a few more runtime functions.
- Dan
[1]
https://github.com/PowerNex/PowerNex/blob/master/loader/src/object.d
Re: move an argument tuple
On 07/12/17 10:46, Jonathan M Davis wrote: My first inclination is to suggest that you make the function accept all its arguments by ref and then call move internally, though that only makes sense if you're _always_ going to do a move. I believe that this will work though: That won't work for me because of a detail I've left out - I'm doing an interim move into a temporary buffer. In fact, I actually forbid ref arguments (though I could have converted them to a pointer on input and back to a reference on call, but it's actually a reasonable restriction for me to just forbid this outright). Shachar
Re: move an argument tuple
On Thursday, December 07, 2017 10:19:25 Shachar Shemesh via Digitalmars-d
wrote:
> Hi everybody,
>
> I'm trying to have a templated function like so:
>
> void func(alias F)(Parameters!F args) {
>
> At some point in func, I want to call F with args:
> F(args);
>
> This does not work if one of args is a struct with copying disabled.
> That's fine. What I'd like to do is to move it into F:
> F( move(args) );
>
> Except that only works if args.length==1. If args.length==2, it thinks
> I'm calling the move overload that moves from the first argument to the
> second, and then it complains that F cannot be called with void argument.
>
> Things that also don't work:
>F( moveAll(args) );
> That one accepts two ranges and expects to copy between them.
>
> I guess I can put up a mixin that expands to:
>F( move(args[0]), move(args[1]) );
>
> I'd really like a cleaner solution if one is possible.
My first inclination is to suggest that you make the function accept all its
arguments by ref and then call move internally, though that only makes sense
if you're _always_ going to do a move. I believe that this will work though:
void foo(alias func)(ref Parameters!func args)
And then you can do something like
foreach(arg; args)
{
// do move call on arg
}
inside. All of that gets nastier though if you're trying to make it so that
moves are only done in some cases, and ultimately, doing a mixin like you
were thinking of might be nicer.
The cleanest thing would probably be if you could just use ref and not
bother moving anything, but whether that makes sense or not depends on what
you're doing.
- Jonathan M Davis
Re: @ctfeonly
On Thursday, December 07, 2017 07:41:18 Mike Franklin via Digitalmars-d wrote: > On Thursday, 7 December 2017 at 04:45:15 UTC, Jonathan M Davis > > wrote: > > The simplest way to do that is to write a unit test that uses a > > static assertion. As I understand it, with the way CTFE works, > > it pretty much can't know whether a function can be called at > > compile time until it tries, but a unit test can catch it if > > the function no longer works at compile time. > > Not bad, but that is swaying into the cumbersome category. If > that's the best we can do, a @ctfeonly attribute starts looking > pretty good. In the vast majority of cases, when a function is used for CTFE, it's also used during runtime. So, in most cases, you want to ensure that a function works both with CTFE and without, and in those cases something like @ctfeonly wouldn't make any sense. In my experience, pretty much the only time that something like @ctfeonly would make any sense would be with a function for generating a string mixin. I'm sure that there are folks who have other uses for functions that would only be used during CTFE, but really, CTFE is designed with the idea that functions would be useable both at runtime and at compile time, and most functions that are used during CTFE were not designed just for CTFE. Certainly, trying to test or enforce that a function is only used at compile time is not going to be the common case. - Jonathan M Davis
move an argument tuple
Hi everybody,
I'm trying to have a templated function like so:
void func(alias F)(Parameters!F args) {
At some point in func, I want to call F with args:
F(args);
This does not work if one of args is a struct with copying disabled.
That's fine. What I'd like to do is to move it into F:
F( move(args) );
Except that only works if args.length==1. If args.length==2, it thinks
I'm calling the move overload that moves from the first argument to the
second, and then it complains that F cannot be called with void argument.
Things that also don't work:
F( moveAll(args) );
That one accepts two ranges and expects to copy between them.
I guess I can put up a mixin that expands to:
F( move(args[0]), move(args[1]) );
I'd really like a cleaner solution if one is possible.
Thanks,
Shachar
Re: function for inverse relative path?
relativePath works with un-normalized paths, and I'd want the same for
inverseRelativePath, eg: should work with:
`/a//b/./c/bar.d` and `c//bar.d` => `/a//b`
unfortunately buildNormalizedPath(rel) will prepend getcwd to `rel` so
it's a tad more complex than just calling buildNormalizedPath 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 `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"));
>> ```
>
> I've never heard of inverse relative paths, but it looks like all you're
> doing is looking for a substring match at the end and returning the parts at
> the front that don't match. If you're doing that, you could simply do
> something like
>
> enforce(lhs.length >= rhs.length, "some error message");
> if(lhs[rhs.length .. $] == rhs)
> return lhs[0 .. rhs.length];
> throw new Exception("some error message");
>
> though if you want /a instead of /a/ in your example, some extra code would
> have to be added for properly handling trailing slashes, and depending, you
> might want to normalize paths first (though typically, that sort of thing is
> left up to the caller). It might also need to be enforced that the left-hand
> argument is an absolute path.
>
> - Jonathan M Davis
>
