Re: std.allocator ready for some abuse
On Saturday, 12 September 2015 at 06:30:42 UTC, bitwise wrote: On Saturday, 12 September 2015 at 00:31:27 UTC, Andrei Alexandrescu wrote: [...] This sounds like the default setup I'll be using. The containers will use a Mallocator by default, so I will have to add the ranges when the contained type is found to have indirections. [...] Alternatively, GC.addRange() could return a value indicating whether or not the range had actually been added(for the first time) and should be removed. Bit
Re: std.allocator ready for some abuse
On Saturday, 12 September 2015 at 00:31:27 UTC, Andrei Alexandrescu wrote: On 09/11/2015 07:46 PM, bitwise wrote: [...] Say you have a container that uses its own allocator inside, yet offers the user to store objects with indirections that use the GC. Then indeed the container would need to call addRange and removeRange on its own internal structures. This sounds like the default setup I'll be using. The containers will use a Mallocator by default, so I will have to add the ranges when the contained type is found to have indirections. If, on the contrary, the container imposes that its own held objects use the container's allocator as well (a rare but not implausible design), it wouldn't need to do that. I don't understand exactly what you mean, but here is a more verbose version of my concern: Lets say someone's allocator calls GC.addRange on the memory it allocates before a container gets it. The container would call GC.addRange when it gets it, but then call GC.removeRange before calling allocator.deallocate(). The allocator which think's the block has already been registered with the GC could possibly reuse it, thinking it's registered with the GC alreadybut that allocator may pass the memory to a container which chooses not to call GC.addRange, because it thinks it's using an allocator that does that for it. That second container may now store types with indirections, which would be unreachable, and get freed, and..chaos. I suppose that as a general rule, a container could always add ranges it gets from an allocator to the GC, which would prevent the above problem...but only for containers that abide by the rule. It sounds like you're saying that although it may not be needed sometimes, that no harm would be done. I think a better solution though would be for the GC to have something like GC.hasRange(). The container could check the state of the memory it receives and take appropriate action. I don't see anything in the current GC docs which would allow you to tell if a range had already been added to the GC. Bit
Re: A collection of DIPs
On Friday, 11 September 2015 at 19:30:56 UTC, ponce wrote: Some of us use and need @nogc all the time. The other parts of an application can use the GC: best of both worlds. Is there even a compiler switch to disable GC altogether so the program doesn't have a GC thread? No, I can't see it...
Re: Better lambdas!!!!!!!!!!
On Friday, 11 September 2015 at 23:15:58 UTC, Jonathan M Davis wrote: style lambdas in D. However, given the complexity of C++ templates, as I understand it, there are no plans to ever support them in C++ interop (since it would pretty much mean putting a C++ compiler in the D compiler), in which case, there's no need to worry about C++ lambdas anyway, because they all involve templates. No, you have to generate c++ sourcecode. No need to build in the compiler.
Re: module std.stream is deprecated - Will be removed by phobos version 2.070
On Saturday, 12 September 2015 at 04:50:06 UTC, Jonathan M Davis wrote: On Friday, 11 September 2015 at 23:06:16 UTC, Jonathan M Davis wrote: So, I intend to open a PR to fix the targeted removal time (probably this evening) so that it's not quite so quick Here's the PR: https://github.com/D-Programming-Language/phobos/pull/3647 And it's now been merged by Walter. So, std.stream and friends will be around as deprecated but undocumented until about October of next year. And they're now in undeaD as well, so anyone who wants to continue to use them can just pull in undeaD instead and adjust their imports. So, std.stream is finally on the way out as planned but not quite so abruptly. - Jonathan M Davis
Re: module std.stream is deprecated - Will be removed by phobos version 2.070
On Friday, 11 September 2015 at 23:06:16 UTC, Jonathan M Davis wrote: So, I intend to open a PR to fix the targeted removal time (probably this evening) so that it's not quite so quick Here's the PR: https://github.com/D-Programming-Language/phobos/pull/3647 - Jonathan M Davis
Re: Reasons to use D
On Saturday, 12 September 2015 at 03:52:11 UTC, skoppe wrote: That is not the only way it behaves differently. jQuery's html() will actually execute inline script, whereas innerHTML won't. I'm pretty sure it is the other way around...
Re: Reasons to use D
On Friday, 11 September 2015 at 19:54:55 UTC, Adam D. Ruppe wrote: On Friday, 11 September 2015 at 15:30:05 UTC, Sebastiaan Koppe wrote: Does it have to do with char encodings? Not the issue I hit. Ah, forget about my suggestion, I misread something on the link you send. So when it said "This method uses the browser's innerHTML property", I wasn't expecting it to behave significantly differently! That is not the only way it behaves differently. jQuery's html() will actually execute inline script, whereas innerHTML won't. Coming back to the thread's title, jQuery is a perfectly valid reason to use D. Sad that there is no proper way to do modern web development in D.
Re: Better lambdas!!!!!!!!!!
On Saturday, 12 September 2015 at 02:13:11 UTC, Pierre Krafft
wrote:
On Saturday, 12 September 2015 at 01:03:54 UTC, Prudence wrote:
On Thursday, 10 September 2015 at 18:02:36 UTC, Ali Çehreli
wrote:
On 09/10/2015 10:55 AM, Prudence wrote:
> How bout this:
>
> void myfunc(double delegate(int i, int z, float f)) {}
>
>
> myfunc((int i, int z, float f) { return i*z*f; } }
>
> vs
>
> myfunc({ return i*z*f; }) // Names of parameters are
inferred from
> signature.
Considering other features of the language, that's pretty
much impossible in D. What if there is another i in scope:
int i;
myfunc({ return i*z*f; });
Now, should it call another overload of myfunc that takes
(int z, int f) because i is something else?
Should the compiler analyze the body of the code and decide
which symbols could be parameters? And then go through all
overloads of myfunc? etc.?
Ali
As I said, it could throw a warning or error. It, in some
sense, is already a a problem with nested blocks that hide
outside variables, is it not?
The compiler doesn't need to scan anything. It knows the which
parameters from the definition!
-> void myfunc(double delegate(int i, int z, float f)) <-
Compiler knows to use the names here as the default names in
for the parameters when.
when used:
myfunc({ return i*z*f; }); <- Oh, there are the names, we know
what they are because the signature is tells us. The compiler
does the following:
1. Sees we have a block without any parameters defined. i.e.,
a lambda.
2. It looks up the signature of myfunc to find out what the
names are
3. It sees that they are i z and f
4. Now it knows and it effectively rewrites the code as
myfunc((i,z,f) { return i*z*f; });
Surely this is not difficult, 4 steps?
You're making your code more brittle for a small gain. The
suggestion makes parameter usage order important and the
compiler can't warn about my typos.
Consider:
myfunc({return "x:"~x~"y:"-y;}) getting changed to
myfunc({return "y:"~y~"x:"~x;});
Or the typo in
myfunc({return i*z+f*j;});
Lambdas are already very concise. This proposal doesn't give
any benefits outside of very simple lambdas. Such lambdas are
already so simple that they could use some standard functions
instead (like sum, to!T, and bind).
What does this have to do with my proposal? Those issues exist
regardless of the simplification.
myfunc({return "x:"~x~"y:"-y;}) getting changed to
myfunc({return "y:"~y~"x:"~x;});
huh? What do you mean the suggestion makes parameter usage order
important? They are important, it has nothing to do with the
suggestion? Are you saying that you want to reserve the right to
do something like
myfunc(string delegate(string x, string y));
and
myfunc((y,x){ "y:"~y~"x:"~x; })
? If so, or unless I'm missing something, that's bad no matter
what. Changing the order and reversing the names is more than
just confusing, it's hard to read and most people will gloss over
that fact. Be consistent with your parameters and maybe you'll
have less bugs?
Or the typo in
myfunc({return i*z+f*j;});
Again, what does this have to do with anything? A typo is a typo
and is always a mistake. The above example has the same effect
regardless if the parameters are explicit or deduced.
myfunc((i,z,f) {return i*z+f*j;});
j is still a problem. If j is defined outside the lambda then
regardless of specific or implicit parameter names, it will not
cause any problems.
In either case, the compiler can see that j is either referenced
outside the scope or undefined. It has nothing to do with the
parameters used.
Of course maybe I'm missing something, but essentially are not
almost all uses of lambda's simply copying the parameter
signature of the delegate. It already infers types... you could
say that leads to typo's too...
Re: Better lambdas!!!!!!!!!!
On Saturday, 12 September 2015 at 01:03:54 UTC, Prudence wrote:
On Thursday, 10 September 2015 at 18:02:36 UTC, Ali Çehreli
wrote:
On 09/10/2015 10:55 AM, Prudence wrote:
> How bout this:
>
> void myfunc(double delegate(int i, int z, float f)) {}
>
>
> myfunc((int i, int z, float f) { return i*z*f; } }
>
> vs
>
> myfunc({ return i*z*f; }) // Names of parameters are
inferred from
> signature.
Considering other features of the language, that's pretty much
impossible in D. What if there is another i in scope:
int i;
myfunc({ return i*z*f; });
Now, should it call another overload of myfunc that takes (int
z, int f) because i is something else?
Should the compiler analyze the body of the code and decide
which symbols could be parameters? And then go through all
overloads of myfunc? etc.?
Ali
As I said, it could throw a warning or error. It, in some
sense, is already a a problem with nested blocks that hide
outside variables, is it not?
The compiler doesn't need to scan anything. It knows the which
parameters from the definition!
-> void myfunc(double delegate(int i, int z, float f)) <-
Compiler knows to use the names here as the default names in
for the parameters when.
when used:
myfunc({ return i*z*f; }); <- Oh, there are the names, we know
what they are because the signature is tells us. The compiler
does the following:
1. Sees we have a block without any parameters defined. i.e., a
lambda.
2. It looks up the signature of myfunc to find out what the
names are
3. It sees that they are i z and f
4. Now it knows and it effectively rewrites the code as
myfunc((i,z,f) { return i*z*f; });
Surely this is not difficult, 4 steps?
You're making your code more brittle for a small gain. The
suggestion makes parameter usage order important and the compiler
can't warn about my typos.
Consider:
myfunc({return "x:"~x~"y:"-y;}) getting changed to myfunc({return
"y:"~y~"x:"~x;});
Or the typo in
myfunc({return i*z+f*j;});
Lambdas are already very concise. This proposal doesn't give any
benefits outside of very simple lambdas. Such lambdas are already
so simple that they could use some standard functions instead
(like sum, to!T, and bind).
Re: module std.stream is deprecated - Will be removed by phobos version 2.070
On Friday, 11 September 2015 at 23:32:01 UTC, Andrei Alexandrescu wrote: Undead is a great idea at least because it's a good place to park documentation for legacy code. In fact we should move undead to the dlang repo (now it's in digitalmars). Makes sense. Let's let std.stream lay low for a while more, it's really not preventing anything from happening. Given that it's not in the docs, I do think that it should be deprecated (like it is now), but I definitely think that it should stick around longer than just 2.070. I don't like the idea of leaving deprecated code around long term, but we definitely want to give folks time to transition their code and reduce the risk of them missing the deprecation messages entirely because they waited half a year to update their compiler. Though, now that I think about it, we should probably also put it in undead now (assuming that undead doesn't use std, which I assume it doesn't) - but still leave it in Phobos for the moment as well. Then folks that want to keep using it can just switch to the undead repo and not see the deprecation messages anymore if they don't intend to actually change their code so that it doesn't use std.stream, and those that haven't updated their code or switched to using undead would still see the deprecation messages. - Jonathan M Davis
Re: Better lambdas!!!!!!!!!!
On Thursday, 10 September 2015 at 18:02:36 UTC, Ali Çehreli wrote:
On 09/10/2015 10:55 AM, Prudence wrote:
> How bout this:
>
> void myfunc(double delegate(int i, int z, float f)) {}
>
>
> myfunc((int i, int z, float f) { return i*z*f; } }
>
> vs
>
> myfunc({ return i*z*f; }) // Names of parameters are
inferred from
> signature.
Considering other features of the language, that's pretty much
impossible in D. What if there is another i in scope:
int i;
myfunc({ return i*z*f; });
Now, should it call another overload of myfunc that takes (int
z, int f) because i is something else?
Should the compiler analyze the body of the code and decide
which symbols could be parameters? And then go through all
overloads of myfunc? etc.?
Ali
As I said, it could throw a warning or error. It, in some sense,
is already a a problem with nested blocks that hide outside
variables, is it not?
The compiler doesn't need to scan anything. It knows the which
parameters from the definition!
-> void myfunc(double delegate(int i, int z, float f)) <-
Compiler knows to use the names here as the default names in for
the parameters when.
when used:
myfunc({ return i*z*f; }); <- Oh, there are the names, we know
what they are because the signature is tells us. The compiler
does the following:
1. Sees we have a block without any parameters defined. i.e., a
lambda.
2. It looks up the signature of myfunc to find out what the names
are
3. It sees that they are i z and f
4. Now it knows and it effectively rewrites the code as
myfunc((i,z,f) { return i*z*f; });
Surely this is not difficult, 4 steps?
Re: Operator overloading or alternatives to expression templates
On Saturday, 12 September 2015 at 00:27:45 UTC, Andrei Alexandrescu wrote: On 09/11/2015 08:03 PM, H. S. Teoh via Digitalmars-d wrote: Needless to say, I did not have the patience (nor persistence!) to decipher those error messages; most of my efforts lay in copying textbook examples from the documentation and modifying them piece by piece, checking their compilability at every step, until they matched what I ultimately wanted. Writing anything complex directly was an invitation to be faced with an incomprehensible screen-filling error message (often more than one), and endless hours of randomly modifying random bits of syntax in hopes that the error will somehow, magically, go away. All the more ironic considering Blitz++ was intended for scientists who were not supposed to be programmer experts. -- Andrei I do think it says more about C++ than it does about expression templates.
Re: std.allocator ready for some abuse
On 09/11/2015 07:46 PM, bitwise wrote:
On Friday, 11 September 2015 at 23:13:16 UTC, Andrei Alexandrescu wrote:
On 09/11/2015 06:32 PM, bitwise wrote:
On Friday, 25 October 2013 at 00:00:36 UTC, Andrei Alexandrescu wrote:
On 10/24/13 2:38 PM, Namespace wrote:
On Thursday, 24 October 2013 at 21:31:42 UTC, Namespace wrote:
Awesome! Will Appender get an option to use a suitable allocator?
A dream of me, that will probably never come true, would be also
something like this:
with (Mallocator) {
int[] arr;
arr ~= 42; /// will use Mallocator.it.allocate internal
}
Oddly enough this can be actually done.
with (setAllocator!Mallocator)
{
...
}
setAllcator returns an rvalue that changes the global allocator to the
Mallocator in the constructor, and restores it to whatever it was in
the destructor.
Andrei
Doesn't this race because the allocator instance is shared?
I couldn't find 'setAllocator' in the source code.
Yah, that was a rumination, not something already implemented. -- Andrei
Ok, thanks. I thought that may be the case.
One more question:
I'd like to integrate these into the containers I'm building, but I'm
not clear about how to determine if GC.addRange() should be called.
I've thought through this, and I'm pretty sure that I can call
GC.addRange and GC.removeRange indiscriminately on any memory my
container gets from an allocator, as long as the container finds that
(hasIndirections!T == true).
My reasoning is that if an allocator calls GC.addRange on it's own
memory, then it should also reinitialize that memory when it gets
deallocated, which would include calling GC.addRange again if it had to.
Also, calling GC.addRange or GC.removeRange on GC allocated memory
should have no effect.
Does this sound right, or am I crazy?
Say you have a container that uses its own allocator inside, yet offers
the user to store objects with indirections that use the GC. Then indeed
the container would need to call addRange and removeRange on its own
internal structures.
If, on the contrary, the container imposes that its own held objects use
the container's allocator as well (a rare but not implausible design),
it wouldn't need to do that.
Andrei
Re: Operator overloading or alternatives to expression templates
On 09/11/2015 08:03 PM, H. S. Teoh via Digitalmars-d wrote: Needless to say, I did not have the patience (nor persistence!) to decipher those error messages; most of my efforts lay in copying textbook examples from the documentation and modifying them piece by piece, checking their compilability at every step, until they matched what I ultimately wanted. Writing anything complex directly was an invitation to be faced with an incomprehensible screen-filling error message (often more than one), and endless hours of randomly modifying random bits of syntax in hopes that the error will somehow, magically, go away. All the more ironic considering Blitz++ was intended for scientists who were not supposed to be programmer experts. -- Andrei
Re: Operator overloading or alternatives to expression templates
On Fri, Sep 11, 2015 at 07:47:42PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: > On 09/11/2015 03:40 PM, Martin Nowak wrote: > >I find the reasons for turining down my ER a bit moot. > > > >[Issue 14593 – operator overloading can't be used with expression > >templates](https://issues.dlang.org/show_bug.cgi?id=14593) > > > >AFAIK expression templates are the primary choice tom implement SIMD > >and matrix libraries. > >And I still have [this idea](http://dpaste.dzfl.pl/cd375ac594cf) of > >implementing a nice query language for ORMs. > > Expression templates are interesting, but from experience with them in > C++ they're more trouble than they're worth. They haven't made much > inroads in C++ outside exotic libraries because (a) they have odd and > random limitations and corner cases and (b) they have really byzantine > failure modes. Just look at any non-toy-example C++ use of ETs - it's > completely bizarre. A number of years ago I wrote a computational application using Blitz++, an ET-based matrix / multidimensional array C++ library, and I have to say that the experience was mostly pleasant. However, it did push the limits of operator overloading abuse, such as: Array<2,int> matrix = Array<2,int>(4, 4); matrix = 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1; It also had unexpected reference/copying semantics (operator=() copies by reference, but `=` in a variable declarationi copies by value), as well as the occasional wrinkle when assigning the result of an expression template to a variable (sometimes you have to explicitly call a function to turn it into something storable in a variable). The error messages however, were completely inscrutable, just as you said. They generally begin anywhere from 15-16 lines of compiler output per error, and only grows from there. Needless to say, I did not have the patience (nor persistence!) to decipher those error messages; most of my efforts lay in copying textbook examples from the documentation and modifying them piece by piece, checking their compilability at every step, until they matched what I ultimately wanted. Writing anything complex directly was an invitation to be faced with an incomprehensible screen-filling error message (often more than one), and endless hours of randomly modifying random bits of syntax in hopes that the error will somehow, magically, go away. > I'd say if a language wants to support expression templates properly, > there's a lot of careful design to get into it, way beyond > intercepting operators. Like e.g. C#/LINQ. I don't think D is prepared > for that. Pluggable syntax modules seem like an attractive idea, though. But probably outside the scope of D2 at present. [...] > >Does anyone have a different idea how to make a nice query language? > >db.get!Person.where!(p => p.age > 21 && p.name == "Peter") > > There's two canonical ways to do that. > > 1. Use lambdas, which seem to already do what you want: > > db.get!Person.filter!(p => p.age > 21 && p.name == "Peter") > > The way this'd go, the db.get!Person() call returns an input range of > Person. Presumably introspection is being used to bind fields in the > query such as "age" and "name" to static field names in struct Person. > Then good old std.algorithm.filter takes care of the rest. > > 2. If you want to embed real SQL into D, use string-based DSLs. [...] Yeah, string-based DSLs make more sense in D: avoid complicating the core language, thorny issues surrounding operator overloading (and the abuse thereof), and also allow fully-free syntax of your choice. With CTFE, you can parse just about any DSL with any syntax at compile-time, thus incur none of the performance issues that runtime string-based DSLs would have. T -- The only difference between male factor and malefactor is just a little emptiness inside.
Re: std.allocator ready for some abuse
On Friday, 11 September 2015 at 23:13:16 UTC, Andrei Alexandrescu
wrote:
On 09/11/2015 06:32 PM, bitwise wrote:
On Friday, 25 October 2013 at 00:00:36 UTC, Andrei
Alexandrescu wrote:
On 10/24/13 2:38 PM, Namespace wrote:
On Thursday, 24 October 2013 at 21:31:42 UTC, Namespace
wrote:
Awesome! Will Appender get an option to use a suitable
allocator?
A dream of me, that will probably never come true, would be
also
something like this:
with (Mallocator) {
int[] arr;
arr ~= 42; /// will use Mallocator.it.allocate internal
}
Oddly enough this can be actually done.
with (setAllocator!Mallocator)
{
...
}
setAllcator returns an rvalue that changes the global
allocator to the
Mallocator in the constructor, and restores it to whatever it
was in
the destructor.
Andrei
Doesn't this race because the allocator instance is shared?
I couldn't find 'setAllocator' in the source code.
Yah, that was a rumination, not something already implemented.
-- Andrei
Ok, thanks. I thought that may be the case.
One more question:
I'd like to integrate these into the containers I'm building, but
I'm not clear about how to determine if GC.addRange() should be
called.
I've thought through this, and I'm pretty sure that I can call
GC.addRange and GC.removeRange indiscriminately on any memory my
container gets from an allocator, as long as the container finds
that (hasIndirections!T == true).
My reasoning is that if an allocator calls GC.addRange on it's
own memory, then it should also reinitialize that memory when it
gets deallocated, which would include calling GC.addRange again
if it had to. Also, calling GC.addRange or GC.removeRange on GC
allocated memory should have no effect.
Does this sound right, or am I crazy?
Bit
Re: Operator overloading or alternatives to expression templates
On 09/11/2015 03:40 PM, Martin Nowak wrote: I find the reasons for turining down my ER a bit moot. [Issue 14593 – operator overloading can't be used with expression templates](https://issues.dlang.org/show_bug.cgi?id=14593) AFAIK expression templates are the primary choice tom implement SIMD and matrix libraries. And I still have [this idea](http://dpaste.dzfl.pl/cd375ac594cf) of implementing a nice query language for ORMs. Expression templates are interesting, but from experience with them in C++ they're more trouble than they're worth. They haven't made much inroads in C++ outside exotic libraries because (a) they have odd and random limitations and corner cases and (b) they have really byzantine failure modes. Just look at any non-toy-example C++ use of ETs - it's completely bizarre. I'd say if a language wants to support expression templates properly, there's a lot of careful design to get into it, way beyond intercepting operators. Like e.g. C#/LINQ. I don't think D is prepared for that. D currently doesn't allow to override some operators like < <= > >= && || !=. At least the comparison operators are really limiting, e.g. it's not possible to efficiently implement logical indexing. vec[vec < 15], vec[vec == 15], vec[(vec != 15) & (vec > 10)] Also opCmp is less efficient to implement than opBinary!"<" for many types. Generally any good implementation of an algorithm should only require a less operator, not a full ordering opCmp. The short circuit operators && and || have a special semantic and can't be easily, but there is & and | so it's not really required. Now expression templates make an awful DSL when being used to create a HTML formatter, but when the original semantic of the operators is preserved they are really powerful b/c the compiler already handles typechecking, operator precedence, and captures variables. Does anyone have a different idea how to make a nice query language? db.get!Person.where!(p => p.age > 21 && p.name == "Peter") There's two canonical ways to do that. 1. Use lambdas, which seem to already do what you want: db.get!Person.filter!(p => p.age > 21 && p.name == "Peter") The way this'd go, the db.get!Person() call returns an input range of Person. Presumably introspection is being used to bind fields in the query such as "age" and "name" to static field names in struct Person. Then good old std.algorithm.filter takes care of the rest. 2. If you want to embed real SQL into D, use string-based DSLs. Andrei
Re: module std.stream is deprecated - Will be removed by phobos version 2.070
On 09/11/2015 07:06 PM, Jonathan M Davis wrote: On Friday, 11 September 2015 at 20:29:56 UTC, Vladimir Panteleev wrote: https://github.com/D-Programming-Language/phobos/pull/3631 Apparently it was decided at DConf 2015 to remove std.stream and friends from Phobos. But these modules have been left untouched (i.e. they're "stable") for a long time, and there's a lot of D code using them. This decision seems to go in an opposite direction to other recent decisions (i.e. that we stop breaking code). Is everyone (incl. Walter AND Andrei) on board with this? Walter and Andrei publicly agreed at dconf that it should be removed. That's right. I remember I said something like "it deserves a burial". It was on the spur of the moment; after that I figured I should have better said "Does it prevent anyone from writing good code? It's not in the documentation, so no new code will use it. Leave it be for now, no reason to do anything for a while". After that, as Martin points out, it should go in undead where folks can continue to use it if they really want to. But I don't think that code should simply stop compiling within a sixth month period. I'm all for deprecating and removing stuff that we want to get rid of and really don't like keeping it around long term, but we need a deprecation cycle that gives folks time to fix their code, and sadly, a note in the documentation really doesn't seem to be enough of a warning. Undead is a great idea at least because it's a good place to park documentation for legacy code. In fact we should move undead to the dlang repo (now it's in digitalmars). Let's let std.stream lay low for a while more, it's really not preventing anything from happening. Andrei
Re: Operator overloading or alternatives to expression templates
On Friday, 11 September 2015 at 19:41:41 UTC, Martin Nowak wrote: Does anyone have a different idea how to make a nice query language? db.get!Person.where!(p => p.age > 21 && p.name == "Peter") Don't the suggestions for DSLs generally revolve around using string mixins to use whatever syntax you want? - Jonathan M Davis
Re: Better lambdas!!!!!!!!!!
On Friday, 11 September 2015 at 20:25:19 UTC, Ola Fosheim Grøstad wrote: On Friday, 11 September 2015 at 11:44:13 UTC, Russel Winder wrote: For example https://issues.dlang.org/show_bug.cgi?id=5710 If C++ interop is still important, maybe it would be a good idea to adopt C++ style lambdas. How would that help with interop? Even if we supported passing a lambda to C++ code, the syntax wouldn't need to match, just the semantics, and that could be done without adopting C++ style lambdas in D. However, given the complexity of C++ templates, as I understand it, there are no plans to ever support them in C++ interop (since it would pretty much mean putting a C++ compiler in the D compiler), in which case, there's no need to worry about C++ lambdas anyway, because they all involve templates. So, while C++ interop is important, and it's gotten some major improvements in the process of switching to D for the compiler front-end (and will likely continue to get improvements), there are still some pretty severe limits on what we're going to be able to do if we don't want to put a full C++ compiler inside of the D compiler, and we really don't want to be doing that. - Jonathan M Davis
Re: Operator overloading or alternatives to expression templates
On 09/11/2015 09:40 PM, Martin Nowak wrote: I find the reasons for turining down my ER a bit moot. ... +1. [Issue 14593 – operator overloading can't be used with expression templates](https://issues.dlang.org/show_bug.cgi?id=14593) AFAIK expression templates are the primary choice tom implement SIMD and matrix libraries. OTOH, they are a hack. And I still have [this idea](http://dpaste.dzfl.pl/cd375ac594cf) of implementing a nice query language for ORMs. D currently doesn't allow to override some operators like < <= > >= && || !=. At least the comparison operators are really limiting, e.g. it's not possible to efficiently implement logical indexing. vec[vec < 15], vec[vec == 15], vec[(vec != 15) & (vec > 10)] Also opCmp is less efficient to implement than opBinary!"<" for many types. Generally any good implementation of an algorithm should only require a less operator, not a full ordering opCmp. ... The rewrite a < b => a.opCmp(b)<0 is usually wasteful, but both methods can be the most efficient choice depending on the application. Two calls to opBinary!"<" will usually not be more efficient than one call to "opCmp". I.e. the precedence should be the other way: try a.opBinary!"<"(b) first and then fall back to a.opCmp(b)<0. (Maybe it would also make sense to automatically provide opCmp if missing when opBinary!"<" has been implemented, such that generic code can use opCmp for all comparable types. Built-in comparable types should also provide opCmp.) The short circuit operators && and || have a special semantic and can't be easily, but there is & and | so it's not really required. ... There's the 'lazy' keyword. ... Does anyone have a different idea how to make a nice query language? db.get!Person.where!(p => p.age > 21 && p.name == "Peter") You could give up on operator syntax.
Re: Better lambdas!!!!!!!!!!
On Friday, 11 September 2015 at 20:16:42 UTC, Timon Gehr wrote: On 09/10/2015 08:23 PM, Jonathan M Davis wrote: That's one of the main reasons that I hate the idea of named arguments. It's more stuff that's part of the API, more public stuff that you have to name correctly and risk bikeshedding arguments over, and more stuff that can you can't change without breaking existing code. - Jonathan M Davis Note that parameter names can already be determined by user code using reflection. True, but as soon as you're doing much with reflection, all bets are off anyway, because it often becomes trivial to break code by making small changes. And I think that it's pretty clear at this point that you can't expect parameter names to not change, since they're not part of the function signature (even if compile-time reflection does let you get at them), which would not be the case if we had named arguments. - Jonathan M Davis
Re: std.allocator ready for some abuse
On 09/11/2015 06:32 PM, bitwise wrote:
On Friday, 25 October 2013 at 00:00:36 UTC, Andrei Alexandrescu wrote:
On 10/24/13 2:38 PM, Namespace wrote:
On Thursday, 24 October 2013 at 21:31:42 UTC, Namespace wrote:
Awesome! Will Appender get an option to use a suitable allocator?
A dream of me, that will probably never come true, would be also
something like this:
with (Mallocator) {
int[] arr;
arr ~= 42; /// will use Mallocator.it.allocate internal
}
Oddly enough this can be actually done.
with (setAllocator!Mallocator)
{
...
}
setAllcator returns an rvalue that changes the global allocator to the
Mallocator in the constructor, and restores it to whatever it was in
the destructor.
Andrei
Doesn't this race because the allocator instance is shared?
I couldn't find 'setAllocator' in the source code.
Yah, that was a rumination, not something already implemented. -- Andrei
Re: module std.stream is deprecated - Will be removed by phobos version 2.070
On Friday, 11 September 2015 at 20:29:56 UTC, Vladimir Panteleev wrote: https://github.com/D-Programming-Language/phobos/pull/3631 Apparently it was decided at DConf 2015 to remove std.stream and friends from Phobos. But these modules have been left untouched (i.e. they're "stable") for a long time, and there's a lot of D code using them. This decision seems to go in an opposite direction to other recent decisions (i.e. that we stop breaking code). Is everyone (incl. Walter AND Andrei) on board with this? Walter and Andrei publicly agreed at dconf that it should be removed. As I understand it, it was removed from the documentation with 2.068 (but not yet deprecated), and now it's been deprecated. Now, that being said, I think 2.070 is too soon to remove it, because at the rate of releases that Martin is targeting, that's maybe 6 months as deprecated, which makes it far too easy IMHO for code to go from working to not compiling without any warnings in between for someone who's not updating their compiler frequently. Normally, the deprecation cycle has been approximately one year as deprecated but documented and approximately one year as deprecated but undocumented (and then the symbol would be removed), so code would continue to work as-is for about 2 years once something has been deprecated, which is about 4x longer than what std.stream is currently marked for. Now, granted, std.stream has essentially been marked as scheduled for deprecation for some time now (embarassingly long really), so in theory, it's not heavily used, but it's also pretty clear based on newsgroup posts and SO and whatnot that it _is_ being used on some level in spite of the fact that it's documentation says that it's going away. So, I intend to open a PR to fix the targeted removal time (probably this evening) so that it's not quite so quick, but it'll still be a year at most, I think, given that it's been marked as scheduled for deprecation for so long and is no longer in the docs. After that, as Martin points out, it should go in undead where folks can continue to use it if they really want to. But I don't think that code should simply stop compiling within a sixth month period. I'm all for deprecating and removing stuff that we want to get rid of and really don't like keeping it around long term, but we need a deprecation cycle that gives folks time to fix their code, and sadly, a note in the documentation really doesn't seem to be enough of a warning. - Jonathan M Davis
Re: module std.stream is deprecated - Will be removed by phobos version 2.070
On 09/11/2015 11:47 PM, Daniel N wrote: > maybe if it was moved to DUB, it wouldn't be that disruptive? Yes, please add it to http://code.dlang.org/packages/undead at least.
Re: std.allocator ready for some abuse
On Friday, 25 October 2013 at 00:00:36 UTC, Andrei Alexandrescu
wrote:
On 10/24/13 2:38 PM, Namespace wrote:
On Thursday, 24 October 2013 at 21:31:42 UTC, Namespace wrote:
Awesome! Will Appender get an option to use a suitable
allocator?
A dream of me, that will probably never come true, would be
also
something like this:
with (Mallocator) {
int[] arr;
arr ~= 42; /// will use Mallocator.it.allocate internal
}
Oddly enough this can be actually done.
with (setAllocator!Mallocator)
{
...
}
setAllcator returns an rvalue that changes the global allocator
to the Mallocator in the constructor, and restores it to
whatever it was in the destructor.
Andrei
Doesn't this race because the allocator instance is shared?
I couldn't find 'setAllocator' in the source code.
Bit
Re: module std.stream is deprecated - Will be removed by phobos version 2.070
On Friday, 11 September 2015 at 20:29:56 UTC, Vladimir Panteleev wrote: https://github.com/D-Programming-Language/phobos/pull/3631 Apparently it was decided at DConf 2015 to remove std.stream and friends from Phobos. But these modules have been left untouched (i.e. they're "stable") for a long time, and there's a lot of D code using them. This decision seems to go in an opposite direction to other recent decisions (i.e. that we stop breaking code). Is everyone (incl. Walter AND Andrei) on board with this? maybe if it was moved to DUB, it wouldn't be that disruptive?
Re: module std.stream is deprecated - Will be removed by phobos version 2.070
On Fri, Sep 11, 2015 at 09:16:05PM +, Brian Schott via Digitalmars-d wrote: > On Friday, 11 September 2015 at 20:29:56 UTC, Vladimir Panteleev wrote: > >Apparently it was decided at DConf 2015 to remove std.stream and > >friends from Phobos. > > Kill it with fire. +1. T -- Guns don't kill people. Bullets do.
Re: module std.stream is deprecated - Will be removed by phobos version 2.070
On Friday, 11 September 2015 at 20:29:56 UTC, Vladimir Panteleev wrote: Apparently it was decided at DConf 2015 to remove std.stream and friends from Phobos. Kill it with fire.
module std.stream is deprecated - Will be removed by phobos version 2.070
https://github.com/D-Programming-Language/phobos/pull/3631 Apparently it was decided at DConf 2015 to remove std.stream and friends from Phobos. But these modules have been left untouched (i.e. they're "stable") for a long time, and there's a lot of D code using them. This decision seems to go in an opposite direction to other recent decisions (i.e. that we stop breaking code). Is everyone (incl. Walter AND Andrei) on board with this?
Re: Better lambdas!!!!!!!!!!
On Friday, 11 September 2015 at 11:44:13 UTC, Russel Winder wrote: For example https://issues.dlang.org/show_bug.cgi?id=5710 If C++ interop is still important, maybe it would be a good idea to adopt C++ style lambdas.
Re: Better lambdas!!!!!!!!!!
On 09/10/2015 08:23 PM, Jonathan M Davis wrote: That's one of the main reasons that I hate the idea of named arguments. It's more stuff that's part of the API, more public stuff that you have to name correctly and risk bikeshedding arguments over, and more stuff that can you can't change without breaking existing code. - Jonathan M Davis Note that parameter names can already be determined by user code using reflection.
Re: Compile all-of-dub?
On 09/11/2015 01:37 PM, ZombineDev wrote: > On Wednesday, 9 September 2015 at 08:26:59 UTC, qznc wrote: >> ... > > https://github.com/MartinNowak/project_tester Right, please contribute.
Re: Compile all-of-dub?
On 09/09/2015 10:26 AM, qznc wrote: > The Rust people have this Crater [0,1] tool, which essentially builds > all Rust libraries with two compiler versions and compares for regressions. I recently created a Jenkins project so that I can easily test many projects with a particular DPL version or against PRs. https://github.com/MartinNowak/project_tester It's still much better when the actual author of a library tests the latest beta, and beta are always available via Travis-CI.
Re: Reasons to use D
On Friday, 11 September 2015 at 15:30:05 UTC, Sebastiaan Koppe wrote: Does it have to do with char encodings? Not the issue I hit: it has to do with the script tags being ripped out. It says "To set the content of a element, which does not contain HTML, use the .text() method and not .html().", but it doesn't say all script in the middle of the html will be ripped out too.The way I read that was $("script").html() is wrong and you should use $("script").text(). OK, script tags are implicitly cdata so indeed it might be different.. but if you do "div".innerHTML = "