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.
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!
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.
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 functi
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 req
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.)
Fina
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. an
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
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 asse
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 st
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
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
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
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 run
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 te
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 ma
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 allocatio
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 e
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
>> expla
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 p
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
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 ha
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
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
a
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 shou
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
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?
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,
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 ru
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 mistake
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, wit
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 @ctfeon
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 probabl
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
>
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 c
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. nap
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.
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.
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();
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
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
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
>
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:
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/
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 cop
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 Rus
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
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 speci
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.con
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 becaus
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
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! :)
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 d
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 al
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
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 impo
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 tha
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.
Th
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-con
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)
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.b
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
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
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
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 o
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
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
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
concate
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.
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
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
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_
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 Ada
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
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
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 p
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:
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
78 matches
Mail list logo
