On Wednesday, 7 September 2016 at 06:49:09 UTC, Rory McGuire
wrote:
Seriously Stefan, you make my day!
My libraries will be so much easier to write!
I am glad the time was not wasted.
Let's hope it gets merged :)
On Thursday, 8 September 2016 at 06:34:58 UTC, Sebastien Alaiwan
wrote:
On Thursday, 8 September 2016 at 05:02:38 UTC, Stefan Koch
wrote:
(Don't do this preemptively, ONLY when you know that this
template is a problem!)
How would you measure such things?
Is there such a thing like a "compilati
On Thursday, 8 September 2016 at 05:02:38 UTC, Stefan Koch wrote:
(Don't do this preemptively, ONLY when you know that this
template is a problem!)
How would you measure such things?
Is there such a thing like a "compilation time profiler" ?
(Running oprofile on a dmd with debug info comes fir
Hi Guys,
I have just hit a barrier trying to optimize the compile-time in
binderoo.
Roughly 90% of the compile-time is spent instantiating templates.
The 10% for CTFE are small in comparison.
I will write an article about why templates are slow.
The gist will be however : "Templates being sl
On Wednesday, 7 September 2016 at 16:04:05 UTC, Nick Treleaven
wrote:
On Wednesday, 7 September 2016 at 15:15:03 UTC, John Colvin
wrote:
python3 uses / for floating point division and // for integer.
I really like the distinction, although I would prefer if /
was disallowed on integer operands
On Wed, 07 Sep 2016 15:22:01 +, Jack Stouffer wrote:
> On Wednesday, 7 September 2016 at 05:58:37 UTC, Brian wrote:
>> Standard library thin! The lack of a lot of commonly used functions!
>> For example, HTTP client, database abstraction layer, mail delivery,
>> Mathematical calculation standa
Just as a random jumpin.
Couldn't this be worked around with something like this:
struct Foo {
@disable this();
private this(int x) { /* init */ }
}
auto foo() {
return Foo(0);
}
You basicly just hides the weird int x constructor and still
disallows default construction. I guess would no
On Wed, 07 Sep 2016 12:21:40 -0700, Ali Çehreli wrote:
> Protection attributes are for protecting programmers from implementation
> changes. If I reach for allMembers or getMember, it's an explicit way of
> saying "I don't care about the consequences."
If it's just about implementation changes, al
On 9/6/2016 6:44 AM, Ethan Watson wrote:
Suggestions?
Provide a "default" constructor that has a dummy (i.e. unused) parameter.
struct _Unused { }
alias Unused = immutable(_Unused);
Unused unused;
...
struct S {
this(Unused) { ... }
...
}
...
On 9/7/2016 4:05 PM, deadalnix wrote:
And with a default constructor, there's all that code added to deal with the
constructor failing and throwing.
One needs to construct anyway.
For constructor failures, one has little choice but to throw an exception.
Despite all the great work at making e
On 9/7/2016 4:05 PM, deadalnix wrote:
Consider reference counting for instance.
Andrei's scheme for RC doesn't have that issue.
On 9/7/2016 4:17 PM, Joseph Rushton Wakeling wrote:
Potentially naive question, but is there any reason why, if a default
constructor exists, S.init shouldn't just be the same as the result of calling
the default constructor?
So every instance of Mutex shares the same mutex?
On Wednesday, 7 September 2016 at 22:31:17 UTC, Walter Bright
wrote:
On 9/7/2016 3:24 PM, John Colvin wrote:
What, precisely, does "valid" mean in the above?
S is initialized to a valid state, meaning the fields are not
filled with garbage, and are in a state expected by the member
functions
On Wednesday, 7 September 2016 at 22:52:04 UTC, Walter Bright
wrote:
On 9/7/2016 2:08 PM, deadalnix wrote:
It is clear at this point that structures with obligatory
initialization are
necessary. For C++ but not only.
If not interfacing to C++, why?
I stated why.
Is:
if (resource !=
On Wednesday, 7 September 2016 at 15:08:17 UTC, Johan Engelen
wrote:
Note that the spec tells us:
"The .tupleof property returns an ExpressionTuple of all the
fields in the class, __excluding__ the hidden fields and __the
fields in the base class__." (emphasis mine)
So then you have to do __tr
On 9/7/2016 2:08 PM, deadalnix wrote:
It is clear at this point that structures with obligatory initialization are
necessary. For C++ but not only.
If not interfacing to C++, why?
Right now, all dtors need to make sure that the
.init state is valid, which can be a performance problem (you nee
On 9/7/2016 3:24 PM, John Colvin wrote:
What, precisely, does "valid" mean in the above?
S is initialized to a valid state, meaning the fields are not filled with
garbage, and are in a state expected by the member functions.
But if there's a default constructor,
S s = S.init;
S s;
On Wednesday, 7 September 2016 at 21:05:32 UTC, Walter Bright
wrote:
The reasons D structs don't have a default constructor:
1. So S.init is a valid initializer
2. So all instances of S can be guaranteed to contain a valid
instance
3. So default initialization is guaranteed to succeed
4. So an
On 06.09.2016 22:44, Johan Engelen wrote:
On Tuesday, 6 September 2016 at 17:58:44 UTC, Timon Gehr wrote:
I don't think so (although your case could be made to work easily
enough). This seems to be accepts-invalid.
What do you think of the original example [1] in the bug report that uses
`mix
On 07.09.2016 14:19, Marc Schütz wrote:
On Tuesday, 6 September 2016 at 17:01:28 UTC, Timon Gehr wrote:
There can be no field (or variables) of type 'void'. (void,void,T) has
two fields of type 'void'.
Just fixing the limitations is also not really possible, as e.g. void*
and void[] exploit tha
On Wednesday, 7 September 2016 at 20:55:52 UTC, Walter Bright
wrote:
On 9/7/2016 5:07 AM, Ethan Watson wrote:
But ignoring that. My first member is offset by 8 bytes, even
in an extern( C++
) class. I assume it's just blindly sticking a vtable in there
regardless of if
I actually define virtua
The reasons D structs don't have a default constructor:
1. So S.init is a valid initializer
2. So all instances of S can be guaranteed to contain a valid instance
3. So default initialization is guaranteed to succeed
4. So any struct constructor starts with a valid state
5. In my not-so-humble op
On Wednesday, 7 September 2016 at 11:42:40 UTC, Dicebot wrote:
If it is so, I'd call it a major extern(c++) bug.
It is not surprising. Making it work require flow analysis much
more powerful than what DMD has now.
On 9/7/2016 5:10 AM, Ethan Watson wrote:
"Scope classes have been recommended for deprecation."
That decision will be revisited.
On 9/7/2016 5:07 AM, Ethan Watson wrote:
But ignoring that. My first member is offset by 8 bytes, even in an extern( C++
) class. I assume it's just blindly sticking a vtable in there regardless of if
I actually define virtual functions or not.
This came up before with Manu's desire to match co
On 9/7/2016 8:46 AM, Jack Stouffer wrote:
Yeah, this problem ultimately comes down to healthy use of DRY in Phobos in
regards to string handling code. This was always the tradeoff with DRY: with
small pieces of reused code being put into functions, it makes maintenance and
optimization easier, bu
On 09/03/2016 09:37 AM, Martin Nowak wrote:
> On Wednesday, 31 August 2016 at 21:12:54 UTC, Ali Çehreli wrote:
>> The recommended solution of mixing in every template instance is not a
>> viable solution because that would effectively remove IFTI from D.
>> What a huge loss that would be. We can'
On Wednesday, 6 April 2016 at 13:15:48 UTC, Andrei Alexandrescu
wrote:
I just got word about Sparrow (from its creator no less):
presentation_offline_Sparrow.pdf - https://db.tt/m2WwpxIY
Speak.mp4 - https://db.tt/RDmrlEu7
ThesisLucTeo.pdf - https://db.tt/1ylGHuc1
An interesting language that sh
On 09/03/2016 03:13 PM, Ethan Watson wrote:
> On Saturday, 3 September 2016 at 21:54:24 UTC, Jacob Carlborg wrote:
> allMembers not returning all members makes introspection
> entirely useless when it comes to Binderoo.
Same problem with Weka's code base...
> getMember itself, well, I'd honestl
On Wednesday, 7 September 2016 at 15:22:01 UTC, Jack Stouffer
wrote:
2. Everything but the math library is extremely prone to change
within a couple of years and is therefore not really a good
candidate for standardization. There's a reason that there are
three different ways to connect to a
On Tuesday, 6 September 2016 at 07:26:37 UTC, Andrea Fontana
wrote:
Integer division and modulo are not bugs.
Quoted for emphasis
If you want floating point math, then declare your variables as
floats.
On Wednesday, 7 September 2016 at 14:46:46 UTC, Sai wrote:
I suspected the same, most of the CPUs support fast floating
point operations anyway (with FPUs), shouldn't take a lot more
time than doing integer arithmetic. Unless we are targeting
8bit avr or something similar.
No. Floating poin
An easy way around this would be to disallow taking the address
of a property at all. Sure it introduces a disparity between
properties and real member variables, but that's surely worth all
the confusion that might be caused otherwise. Is it even that
common to take the address of a member var
On Wednesday, 7 September 2016 at 15:15:03 UTC, John Colvin wrote:
python3 uses / for floating point division and // for integer.
I really like the distinction, although I would prefer if / was
disallowed on integer operands entirely, i.e. 3/2.0 is ok but
3/2 is not, that would be an error and
On Wednesday, September 07, 2016 15:22:01 Jack Stouffer via Digitalmars-d
wrote:
> On Wednesday, 7 September 2016 at 05:58:37 UTC, Brian wrote:
> > Standard library thin! The lack of a lot of commonly used
> > functions! For example, HTTP client, database abstraction
> > layer, mail delivery, Math
On Tuesday, 6 September 2016 at 10:04:06 UTC, Andrei Alexandrescu
wrote:
The drawback of this is taking this in as a reader and
maintainer. We have the 'text' template which calls the
'textImpl' template which calls the 'to' template which calls
the 'toImpl' template which calls the 'parse' tem
On Wednesday, 7 September 2016 at 05:58:37 UTC, Brian wrote:
Standard library thin! The lack of a lot of commonly used
functions! For example, HTTP client, database abstraction
layer, mail delivery, Mathematical calculation standard library.
We can refer to the implementation of some of the st
I suspected the same, most of the CPUs support fast floating
point operations anyway (with FPUs), shouldn't take a lot more
time than doing integer arithmetic. Unless we are targeting 8bit
avr or something similar.
And precision argument doesn't seem strong either, since, which
is more precis
On Wednesday, 7 September 2016 at 15:09:42 UTC, Lodovico Giaretta
wrote:
I think the current state of affairs is fairly good. Adding
implicit conversions would make it worst. What would probably
make it better (but can't be changed now) is having two
distinct operators, one for integer division
On Wednesday, 7 September 2016 at 15:09:42 UTC, Lodovico Giaretta
wrote:
x == x/k + x%k
Of course that was:
x == (x/k)*k + x%k
But ok, you got the idea: going back and forth is lossless, just
remember to add the modulus.
On Wednesday, 7 September 2016 at 14:46:46 UTC, Sai wrote:
I suspected the same, most of the CPUs support fast floating
point operations anyway (with FPUs), shouldn't take a lot more
time than doing integer arithmetic. Unless we are targeting
8bit avr or something similar.
And precision argum
On Sunday, 4 September 2016 at 12:36:43 UTC, Andrei Alexandrescu
wrote:
Yah, .tupleof is great to have. I think that should be enough
for most introspection needs. Only the field names are missing,
can those be accessed somehow? -- Andrei
Note that the spec tells us:
"The .tupleof property r
On Wednesday, 7 September 2016 at 00:18:59 UTC, Manu wrote:
On 7 September 2016 at 01:54, Wyatt via Digitalmars-d
wrote:
Thanks, that's really interesting, I'll check it out.
Here's some work on static rank polymorphism that might also be
applicable?:
http://www.ccs.neu.edu/home/pete/pub/e
On Wednesday, 7 September 2016 at 05:58:37 UTC, Brian wrote:
Standard library thin! The lack of a lot of commonly used
functions! For example, HTTP client, database abstraction
layer, mail delivery, Mathematical calculation standard library.
We can refer to the implementation of some of the st
On Wednesday, 7 September 2016 at 12:07:56 UTC, Ethan Watson
wrote:
The documentation seems to be correct. I can't extern( C++,
class ) or extern( C++, struct ) on an object, even in DMD
2.071.2-beta3.
`extern( C++, class/struct )` is supported by DMD master and LDC
1.1.0-beta*.
Afaik, ther
Dne 7.9.2016 v 14:07 Ethan Watson via Digitalmars-d napsal(a):
On Wednesday, 7 September 2016 at 11:42:40 UTC, Dicebot wrote:
If it is so, I'd call it a major extern(c++) bug.
The documentation seems to be correct. I can't extern( C++, class ) or
extern( C++, struct ) on an object, even in D
On Wednesday, 7 September 2016 at 12:14:46 UTC, rikki cattermole
wrote:
http://dlang.org/phobos/std_typecons.html#.scoped
This is the kind of hackaround I'd need to do if it were a
class... And it would require more hacking around than the
standard library supports. And it's a spiraling-out-o
On Wednesday, 7 September 2016 at 12:26:25 UTC, Johan Engelen
wrote:
On Wednesday, 7 September 2016 at 12:07:56 UTC, Ethan Watson
wrote:
The documentation seems to be correct. I can't extern( C++,
class ) or extern( C++, struct ) on an object, even in DMD
2.071.2-beta3.
`extern( C++, class/
On Wednesday, 7 September 2016 at 11:53:00 UTC, Marc Schütz wrote:
Would a `vectorize` range adapter be feasible that prepares the
input to make it SIMD compatible? That is, force alignment,
process left-over elements at the end, etc.? As far as I
understand, the problems with auto vectorizatio
On Tuesday, 6 September 2016 at 17:01:28 UTC, Timon Gehr wrote:
There can be no field (or variables) of type 'void'.
(void,void,T) has two fields of type 'void'.
Just fixing the limitations is also not really possible, as
e.g. void* and void[] exploit that 'void' is special and have a
non-com
On 08/09/2016 12:10 AM, Ethan Watson wrote:
On Wednesday, 7 September 2016 at 12:09:21 UTC, Ethan Watson wrote:
This might actually get me what I want. I'll have to play around with
it and see.
"Scope classes have been recommended for deprecation."
"A scope class reference can only appear as
On Wednesday, 7 September 2016 at 12:09:21 UTC, Ethan Watson
wrote:
This might actually get me what I want. I'll have to play
around with it and see.
"Scope classes have been recommended for deprecation."
"A scope class reference can only appear as a function local
variable."
So that's two
On Wednesday, 7 September 2016 at 11:19:46 UTC, Dicebot wrote:
Is using svope class out of the question?
This might actually get me what I want. I'll have to play around
with it and see.
On Wednesday, 7 September 2016 at 11:42:40 UTC, Dicebot wrote:
If it is so, I'd call it a major extern(c++) bug.
The documentation seems to be correct. I can't extern( C++, class
) or extern( C++, struct ) on an object, even in DMD
2.071.2-beta3.
But ignoring that. My first member is offset
On Wednesday, 7 September 2016 at 05:58:37 UTC, Brian wrote:
Standard library thin! The lack of a lot of commonly used
functions! For example, HTTP client, database abstraction
layer, mail delivery, Mathematical calculation standard library.
Your opinion is largely shared with the leadership
On Wednesday, 7 September 2016 at 05:58:37 UTC, Brian wrote:
Standard library thin! The lack of a lot of commonly used
functions! For example, HTTP client, database abstraction
layer, mail delivery, Mathematical calculation standard library.
We can refer to the implementation of some of the st
On Wednesday, 7 September 2016 at 10:31:13 UTC, finalpatch wrote:
I think the problem here is two fold.
First question, how do we combine pipeline stages with minimal
overhead
I think the key to this problem is reliable *forceinline*
for example, a pipeline like this
input.map!(x=>x.f1().f2
On Wednesday, 7 September 2016 at 11:35:45 UTC, Daniel Kozak
wrote:
Dne 7.9.2016 v 13:16 Ethan Watson via Digitalmars-d napsal(a):
On Tuesday, 6 September 2016 at 14:49:20 UTC, Ethan Watson
wrote:
this( void* pArg = null );
Also doesn't work: this( Args... )( Args args ) if(
Args.length ==
static opCall() seems to be the only way to do this then. I can
autogenerate it for any C++ bound class. But it's inadequate.
It leaves room for user error when instantiating any C++ object
in D. It's also another thing that C++ programmers need to be
thoroughly educated about as Type() in C++1
Dne 7.9.2016 v 13:16 Ethan Watson via Digitalmars-d napsal(a):
On Tuesday, 6 September 2016 at 14:49:20 UTC, Ethan Watson wrote:
this( void* pArg = null );
Also doesn't work: this( Args... )( Args args ) if( Args.length == 0 )
Just for funsies I tried making my Mutex a class for the purpose
On Wednesday, 7 September 2016 at 06:51:40 UTC, Daniel Kozak
wrote:
Dne 7.9.2016 v 07:58 Brian via Digitalmars-d napsal(a):
Standard library thin! The lack of a lot of commonly used
functions! For example, HTTP client, database abstraction
layer, mail delivery, Mathematical calculation standar
On Wednesday, 7 September 2016 at 11:16:20 UTC, Ethan Watson
wrote:
On Tuesday, 6 September 2016 at 14:49:20 UTC, Ethan Watson
wrote:
this( void* pArg = null );
Also doesn't work: this( Args... )( Args args ) if( Args.length
== 0 )
Just for funsies I tried making my Mutex a class for the
p
Is using svope class out of the question?
On Tuesday, 6 September 2016 at 14:49:20 UTC, Ethan Watson wrote:
this( void* pArg = null );
Also doesn't work: this( Args... )( Args args ) if( Args.length
== 0 )
Just for funsies I tried making my Mutex a class for the purpose
of embedding it manually in a struct. But thanks to all classe
On Wednesday, 7 September 2016 at 02:09:17 UTC, Manu wrote:
The lesson I learned from this is that you need the user code
to provide a lot of extra information about the algorithm at
compile time for the templates to work out a way to fuse
pipeline stages together efficiently.
I believe it is
On Wednesday, 7 September 2016 at 09:34:12 UTC, Jonathan M Davis
wrote:
There are certainly some operations that we could better
emulate with @property functions that currently don't work
without returning by ref (like ++ or -=), but something like
taking the address of the @property function s
On Wednesday, September 07, 2016 08:15:43 Kagamin via Digitalmars-d wrote:
> On Tuesday, 6 September 2016 at 19:37:26 UTC, Jonathan M Davis
>
> wrote:
> > but an @property function which returns by ref isn't worth
> > much, since you're then giving direct access to the member
> > variable which is
On Tuesday, 6 September 2016 at 19:37:26 UTC, Jonathan M Davis
wrote:
but an @property function which returns by ref isn't worth
much, since you're then giving direct access to the member
variable which is what an @property function is usually meant
to avoid. If you wanted to do that, you could
On Tuesday, 6 September 2016 at 19:18:11 UTC, John wrote:
It would be nice to get this behavior fixed.
Disagree. I've used properties before in C# to transform to and
from data sets required for network multiplayer. It works
functionally the same way in D. Behaviour is as I would expect
for
On Wednesday, 7 September 2016 at 06:51:40 UTC, Daniel Kozak
wrote:
... I think should be part of standard library is some form of
async IO
hello, we can write it as a separate lib as there are no things
like JCP and JSR, standartization committee
On Tuesday, 6 September 2016 at 15:00:48 UTC, Sai wrote:
Thanks for the replies.
I tend to use a lot of float math (robotics and automation) so
I almost always want float output in case of division. And once
in a while I bump into this issue.
I am wondering what are the best ways to work aro
Dne 7.9.2016 v 09:21 R via Digitalmars-d napsal(a):
On Tuesday, 6 September 2016 at 04:32:52 UTC, Daniel Kozak wrote:
Dne 6.9.2016 v 06:14 mogu via Digitalmars-d napsal(a):
On Tuesday, 6 September 2016 at 01:17:00 UTC, Timothee Cour wrote:
is there a way to do this efficiently with associati
On Tuesday, 6 September 2016 at 04:32:52 UTC, Daniel Kozak wrote:
Dne 6.9.2016 v 06:14 mogu via Digitalmars-d napsal(a):
On Tuesday, 6 September 2016 at 01:17:00 UTC, Timothee Cour
wrote:
is there a way to do this efficiently with associative arrays:
aa[key]=value;
auto ptr=key in aa;
withou
On Tuesday, 6 September 2016 at 14:21:26 UTC, Steven
Schveighoffer wrote:
On 9/5/16 5:59 AM, Andrea Fontana wrote:
I asked this some time (years?) ago. Time for a second try :)
Consider this:
---
T simple(T)() { return T.init; }
void main()
{
int test = simple!int(); // it compiles
On Mon, Sep 5, 2016 at 11:59 AM, Andrea Fontana via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> I asked this some time (years?) ago. Time for a second try :)
>
> Consider this:
>
> ---
>
> T simple(T)() { return T.init; }
>
>
> void main()
> {
> int test = simple!int(); // it com
75 matches
Mail list logo
