Re: Identifying 32 vs 64 bit OS?
On Mon, 11 Aug 2014 05:18:59 + Jeremy DeHaan via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: why do you need that info? D types has well-defined sizes (i.e uint is always 32 bits, and so on). you still can check pointer size -- (void *).sizeof. but i'm pretty sure that you don't really need to do that unless you want to store pointers in files (and this is almost completely useless anyway). signature.asc Description: PGP signature
Re: Identifying 32 vs 64 bit OS?
On 11/08/14 07:18, Jeremy DeHaan wrote: I am looking at these versions as described here: http://dlang.org/version.html There are X86 and X86_64 version identifiers, but these specifically mention that they are versions for the processor type. Can they also be used to determine if the OS is running in 32 vs 64 bits? Use D_LP64. This indicates pointers are 64 bits. -- /Jacob Carlborg
Re: Identifying 32 vs 64 bit OS?
On Monday, 11 August 2014 at 05:19:01 UTC, Jeremy DeHaan wrote: I am looking at these versions as described here: http://dlang.org/version.html There are X86 and X86_64 version identifiers, but these specifically mention that they are versions for the processor type. Can they also be used to determine if the OS is running in 32 vs 64 bits? They mean what the integer(or pointer) size for the executable code generated(change able with -m(32|64)) is when compiled. If you want to check if the target OS(not your code) is running 32 vs 64 bit you have to do system call for your target OS.
Re: Identifying 32 vs 64 bit OS?
On Monday, 11 August 2014 at 07:58:15 UTC, Freddy wrote: If you want to check if the target OS(not your code) is running 32 vs 64 bit you have to do system call for your target OS. Not the OS, but a special CPU instruction: isX86_64() in core.cpuid?
overloads and parents. __traits confusion
can someone talk me through the reasoning behind this:
import std.typetuple;
void foo(T)(T v){}
void foo(){}
version(ThisCompiles)
{
alias Parent = TypeTuple!(__traits(parent, foo))[0];
pragma(msg, __traits(getOverloads, Parent, foo));
// tuple()
}
else
{
alias Parent = TypeTuple!(__traits(parent, foo!float))[0];
pragma(msg, __traits(getOverloads, Parent, foo));
/*
/d54/f131.d(8): Error: foo (float v) is not callable using
argument types () /d54/f131.d(8): Error: (__error).foo cannot be
resolved
tuple()
*/
}
Separate Printing Mantissa and Exponent of a Floating Point
Is there a way to separately stringify/print the mantissa and exponent of a floating point? I want this in my pretty-printing module to produce something like 1.2 \cdot 10^3 instead of 1.2e3 I could of course always split on the e but that is kind of non-elegant, I believe.
Re: Using input ranges with std.regex?
On Wednesday, 25 April 2012 at 21:43:11 UTC, Dmitry Olshansky wrote: On 25.04.2012 23:08, H. S. Teoh wrote: Does std.regex support input ranges to match()? Or do I need to convert to string first? For now, yes you have to convert them. Any random access range of code units should do the trick but stringish template constraints might kill that. I plan to extend this eventually. The problematic point is that match internally is delimited by integer offsets (indices). Forward ranges technically can work (the match then will return something like take(..., n);) with a bunch of extra .save calls. Input ranges can't be used at all. Is there any progress on this thing?
Re: Separate Printing Mantissa and Exponent of a Floating Point
Here's my current try:
string toMathML(T)(T x) @trusted /** pure */ if
(isFloatingPoint!T)
{
import std.conv: to;
import std.algorithm: findSplit; //
immutable parts = to!string(x).findSplit(e);
if (parts[2].length == 0)
return parts[0];
else
return parts[0] ~ *10^ ~ parts[2];
}
Re: Separate Printing Mantissa and Exponent of a Floating Point
On Mon, 11 Aug 2014 13:47:13 +, Nordlöw wrote: Is there a way to separately stringify/print the mantissa and exponent of a floating point? I want this in my pretty-printing module to produce something like 1.2 \cdot 10^3 instead of 1.2e3 I could of course always split on the e but that is kind of non-elegant, I believe. If you're writing your own pretty-printer, you can extract those pieces using FloatRep[1] and print them however you like. 1. http://dlang.org/phobos/std_bitmanip.html#.FloatRep
Re: Separate Printing Mantissa and Exponent of a Floating Point
On Monday, 11 August 2014 at 14:15:05 UTC, Nordlöw wrote:
Here's my current try:
string toMathML(T)(T x) @trusted /** pure */ if
(isFloatingPoint!T)
{
import std.conv: to;
import std.algorithm: findSplit; //
immutable parts = to!string(x).findSplit(e);
if (parts[2].length == 0)
return parts[0];
else
return parts[0] ~ *10^ ~ parts[2];
}
Should be patrs[1], he?
I had the same problem, but not for printing, but to do some math
on them.
Unfortunately math.h uses this internal (e.g. in trunc()) but
doesn't give it to outside.
I think it would be a good abstaction between the
hardware-realated stuff and the interface - at the moment almost
the same code is repeated three times over math.h always with the
same version switches.
Re: Identifying 32 vs 64 bit OS?
On Mon, 11 Aug 2014 12:51:40 + via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Not the OS, but a special CPU instruction: isX86_64() in core.cpuid? but there is ARM64 coming. and gdc, for example, will has no problems to support it out of the box due to using gcc cogegen. yes, i know that runtime should be fixed to, but what i want to say is: please, stop thinking that there is Only One 64-bit CPU. signature.asc Description: PGP signature
Linked list as a bidirectional range? I have some questions...
Just for a bit a fun i've implemented a simple doubly linked list and trying out some range based stuff. Whilst doing so i have some questions which you guys might be able to answer. 1. In your opinion when accessing the elements of a linked list should they yield the data stored within the nodes or the entire nodes themselves? Different languages do this differently. For example, C# yields nodes[1], Java yields data[2]. 2. Suppose when accessing my linked list, it yields data and not nodes, how do iterate in reverse? I don't want to add unnecessary methods or properties. 3. How would you implement the 'save' method of a forward range in the context of a linked list? If my understanding is correct the 'saved' range is iterated and discard, so cannot use any references to the underlying range. This might also solve question 2. [1]: http://msdn.microsoft.com/en-us/library/he2s3bh7(v=vs.110).aspx [2]: http://docs.oracle.com/javase/7/docs/api/java/util/LinkedList.html
Re: Linked list as a bidirectional range? I have some questions...
On Mon, Aug 11, 2014 at 05:51:11PM +, Gary Willoughby via
Digitalmars-d-learn wrote:
Just for a bit a fun i've implemented a simple doubly linked list and
trying out some range based stuff. Whilst doing so i have some
questions which you guys might be able to answer.
1. In your opinion when accessing the elements of a linked list should
they yield the data stored within the nodes or the entire nodes
themselves? Different languages do this differently. For example, C#
yields nodes[1], Java yields data[2].
2. Suppose when accessing my linked list, it yields data and not
nodes, how do iterate in reverse? I don't want to add unnecessary
methods or properties.
3. How would you implement the 'save' method of a forward range in the
context of a linked list? If my understanding is correct the 'saved'
range is iterated and discard, so cannot use any references to the
underlying range. This might also solve question 2.
[...]
IMO, it's a bad idea to conflate the container with the range over its
contents. If you make your linked list container the same thing as a
range over it, then iterating over the range will empty the container as
well, which generally isn't what you want.
It's much better to separate the container itself from ranges over the
container. This then allows you to have separate container methods that
return ranges of different types, for example:
class LinkedList {
... // implementation here
auto byNode() {
return ... /* range over nodes */
}
auto byData() {
return ... /* range over data */
}
}
LinkedList l = ...;
foreach (node; l.byNode()) {
// you get nodes here
}
foreach (data; l.byData()) {
// you get data items here
}
Which answers your original question: you can have it both ways. :-)
Unfortunately, built-in arrays are a bad example for this, because it
conflates the container (the slice) with the range. This tends to
mislead people into thinking it's OK to conflate the container with a
range over its contents. In general, you *don't* want to do this.
Unless you're trying to simulate built-in arrays.
T
--
Recently, our IT department hired a bug-fix engineer. He used to work for
Volkswagen.
Destroy two assumptions: interface implementation generated by TMP
Hi, I try to get why the last way of generating an interface
implementation fails. I've put assumptions: is it right ?
---
module itfgen;
import std.stdio;
interface itf{
void a_int(int p);
void a_uint(uint p);
}
template genimpl(T){
char[] genimpl(){
char[] result;
result = void a_ ~ T.stringof ~ (~ T.stringof ~
p){}.dup;
return result;
}
}
class impl: itf{
mixin(genimpl!int);
mixin(genimpl!uint);
}
// OK because: mixin is at the source code level, begining of the
ana
class impl2: itf{
static char[] genimplint(T)(){
char[] result;
result = void a_ ~ T.stringof ~ (~ T.stringof ~
p){}.dup;
return result;
}
mixin(genimplint!int);
mixin(genimplint!uint);
}
// FAILS because: alias are probably generated after the itf check
class impl3: itf{
void tmp(T)(T p){};
alias a_int = tmp!int;
alias a_uint = tmp!uint;
}
void main(string args[]){
auto I1 = new impl;
auto I2 = new impl2;
auto I3 = new impl3;
}
---
I get
'Error: class itfgen.impl3 interface function 'void a_int(int p)'
is not implemented'.
Re: Linked list as a bidirectional range? I have some questions...
On Monday, 11 August 2014 at 18:20:51 UTC, H. S. Teoh via Digitalmars-d-learn wrote: If you make your linked list container the same thing as a range over it, then iterating over the range will empty the container as well, which generally isn't what you want. Yes but only if it's been implemented purely as an input range. I was wondering if it was implemented as a forward range. Forward ranges allow iteration without destroying the contents. I was wondering how the 'save' method of the forward range could be implemented with a linked list. If my understanding is correct this method yields a copy to iterate over and discard. It's much better to separate the container itself from ranges over the container. This then allows you to have separate container methods that return ranges of different types. That does answer it partially. This abstraction could return ranges over the nodes or items. but ultimately these have to expose the underlying data or provide a copy. (i.e. the 'save' method of forward ranges.) Also iterating in reverse (which should be possible with a doubly linked list) such ranges will have to be bidirectional ranges. These questions are all kind of inter-linked. I want to iterate forward and back through the list and if possible provide a nice public interface. It doesn't seem right to expose the nodes as that smells of a leaking abstraction. Hiding the nodes make it harder to iterate without a nice interface i.e. bidirectional range. Ranges are nice but the (forward range's) 'save' method needs careful consideration. opApply is nice but i can't see a way to overload it for reverse iteration.
Are Delimited strings and HereDoc strings just here to suck ?
I mean when writing a D lexer, you necessarly reach the moment when you think: Oh no! is this feature just here to suck ?
Re: Linked list as a bidirectional range? I have some questions...
On Mon, Aug 11, 2014 at 07:35:04PM +, Gary Willoughby via
Digitalmars-d-learn wrote:
On Monday, 11 August 2014 at 18:20:51 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
If you make your linked list container the same thing as a range over
it, then iterating over the range will empty the container as well,
which generally isn't what you want.
Yes but only if it's been implemented purely as an input range. I was
wondering if it was implemented as a forward range. Forward ranges
allow iteration without destroying the contents. I was wondering how
the 'save' method of the forward range could be implemented with a
linked list. If my understanding is correct this method yields a copy
to iterate over and discard.
Only if you explicitly call .save when you iterate over it. The
following code does NOT preserve the original range:
auto fwdRange = LinkedList(...);
foreach (e; fwdRange) {
...
}
while the following does:
auto fwdRange = LinkedList(...);
foreach (e; fwdRange.save) {
...
}
which is uglier.
It's much better to separate the container itself from ranges over
the container. This then allows you to have separate container
methods that return ranges of different types.
That does answer it partially. This abstraction could return ranges
over the nodes or items. but ultimately these have to expose the
underlying data or provide a copy. (i.e. the 'save' method of forward
ranges.)
I don't understand your objection here. You just implement your .front
method to return the appropriate type. The dirty details of how
iteration is implemented need not be exposed.
Also iterating in reverse (which should be possible with a doubly
linked list) such ranges will have to be bidirectional ranges.
You could do that, but it's not necessary. Nothing stops you from
implementing, say, a byDataReverse() method that returns a forward range
that just happens to return items from the original list in reverse
order.
These questions are all kind of inter-linked. I want to iterate
forward and back through the list and if possible provide a nice
public interface. It doesn't seem right to expose the nodes as that
smells of a leaking abstraction. Hiding the nodes make it harder to
iterate without a nice interface i.e. bidirectional range.
Your original question asked for a range that iterates over either data
items or nodes, so what's the problem with exposing the nodes? If you
didn't want the range to iterate over the nodes in the first place, then
don't implement byNodes(), that's all.
Ranges are nice but the (forward range's) 'save' method needs careful
consideration.
All you have to do in .save is to return a copy of the range, which is
*not* the same thing as a copy of the container. (Again, this shows that
it's a bad idea to conflate the container with a range over its
elements.)
opApply is nice but i can't see a way to overload it for reverse
iteration.
opApplyReverse.
Anyway, clearly we're not understanding each other, so let me present
some concrete code so that we aren't just talking past each other:
// This is the container. It is NOT a range of any sort.
class LinkedList(T) {
private class Node {
T data;
Node next, prev;
}
Node head, tail;
/**
* Returns: A range over the data in the container in
* forward order.
*/
auto byData() {
// This is the range that the user will use to
// iterate over the container's contents.
struct Result {
Node current;
@property ref T front() {
// N.B.: no Node object is
// exposed to the public, they
// only see the data.
return current.data;
}
@property bool empty() {
return current is null;
}
void popFront() {
current = current.next;
}
@property Result save() {
// N.B.: no copying of data
// needed; no container
// duplication needed.
return Result(current);
}
}
static assert(isForwardRange!Result);
return Result(head);
}
Re: Are Delimited strings and HereDoc strings just here to suck ?
On Mon, Aug 11, 2014 at 07:47:44PM +, Klaus via Digitalmars-d-learn wrote: I mean when writing a D lexer, you necessarly reach the moment when you think: Oh no! is this feature just here to suck ? I use heredocs every now and then when I need to embed long strings in my program. It's one of the things I *like* about D, in fact. Nobody wants to manually parenthesize every quoted line with '...\n' when the program need to incorporate several pages of built-in help text, for example. Delimited strings are useful when writing code/text generators when you need to be able to use ' and as literal characters without crazy leaning-toothpick syndrome \x\y\z\w\'s sprinkled everywhere. The crazy variety of ways to write string literals in D, OTOH, *is* a bit over the top, as I found out myself when I also tried writing a D lexer. :-P T -- LINUX = Lousy Interface for Nefarious Unix Xenophobes.
Re: Linked list as a bidirectional range? I have some questions...
On Monday, 11 August 2014 at 20:02:38 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
On Mon, Aug 11, 2014 at 07:35:04PM +, Gary Willoughby via
Digitalmars-d-learn wrote:
On Monday, 11 August 2014 at 18:20:51 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
If you make your linked list container the same thing as a
range over
it, then iterating over the range will empty the container as
well,
which generally isn't what you want.
Yes but only if it's been implemented purely as an input
range. I was
wondering if it was implemented as a forward range. Forward
ranges
allow iteration without destroying the contents. I was
wondering how
the 'save' method of the forward range could be implemented
with a
linked list. If my understanding is correct this method yields
a copy
to iterate over and discard.
Only if you explicitly call .save when you iterate over it. The
following code does NOT preserve the original range:
auto fwdRange = LinkedList(...);
foreach (e; fwdRange) {
...
}
while the following does:
auto fwdRange = LinkedList(...);
foreach (e; fwdRange.save) {
...
}
which is uglier.
It's much better to separate the container itself from ranges
over
the container. This then allows you to have separate container
methods that return ranges of different types.
That does answer it partially. This abstraction could return
ranges
over the nodes or items. but ultimately these have to expose
the
underlying data or provide a copy. (i.e. the 'save' method of
forward
ranges.)
I don't understand your objection here. You just implement your
.front
method to return the appropriate type. The dirty details of how
iteration is implemented need not be exposed.
Also iterating in reverse (which should be possible with a
doubly
linked list) such ranges will have to be bidirectional ranges.
You could do that, but it's not necessary. Nothing stops you
from
implementing, say, a byDataReverse() method that returns a
forward range
that just happens to return items from the original list in
reverse
order.
These questions are all kind of inter-linked. I want to iterate
forward and back through the list and if possible provide a
nice
public interface. It doesn't seem right to expose the nodes as
that
smells of a leaking abstraction. Hiding the nodes make it
harder to
iterate without a nice interface i.e. bidirectional range.
Your original question asked for a range that iterates over
either data
items or nodes, so what's the problem with exposing the
nodes? If you
didn't want the range to iterate over the nodes in the first
place, then
don't implement byNodes(), that's all.
Ranges are nice but the (forward range's) 'save' method needs
careful
consideration.
All you have to do in .save is to return a copy of the range,
which is
*not* the same thing as a copy of the container. (Again, this
shows that
it's a bad idea to conflate the container with a range over its
elements.)
opApply is nice but i can't see a way to overload it for
reverse
iteration.
opApplyReverse.
Anyway, clearly we're not understanding each other, so let me
present
some concrete code so that we aren't just talking past each
other:
// This is the container. It is NOT a range of any sort.
class LinkedList(T) {
private class Node {
T data;
Node next, prev;
}
Node head, tail;
/**
* Returns: A range over the data in the container in
* forward order.
*/
auto byData() {
// This is the range that the user will use to
// iterate over the container's contents.
struct Result {
Node current;
@property ref T front() {
// N.B.: no Node object is
// exposed to the public, they
// only see the data.
return current.data;
}
@property bool empty() {
return current is null;
}
void popFront() {
current = current.next;
}
@property Result save() {
// N.B.: no copying of data
// needed; no container
// duplication needed.
return Result(current);
}
}
static
Re: Linked list as a bidirectional range? I have some questions...
On Mon, Aug 11, 2014 at 08:22:11PM +, Gary Willoughby via Digitalmars-d-learn wrote: [...] That..is..awesome! and much more simpler than i thought. I get it now, thanks. Is this pattern repeated in phobos? This is essentially what byKey and byValue of the built-in associative arrays do. :-) IIRC, std.container also uses a similar setup (albeit using opSlice() instead of byXXX(), but it's the same idea). T -- EMACS = Extremely Massive And Cumbersome System
Re: Are Delimited strings and HereDoc strings just here to suck ?
On Mon, Aug 11, 2014 at 10:09 PM, H. S. Teoh via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Mon, Aug 11, 2014 at 07:47:44PM +, Klaus via Digitalmars-d-learn wrote: I mean when writing a D lexer, you necessarly reach the moment when you think: Oh no! is this feature just here to suck ? The crazy variety of ways to write string literals in D, OTOH, *is* a bit over the top, as I found out myself when I also tried writing a D lexer. :-P Out of curiosity, how does a lexer deal with heredocs? It's a sort of... user-defined token, right?
Re: Are Delimited strings and HereDoc strings just here to suck ?
On Mon, Aug 11, 2014 at 10:50:34PM +0200, Philippe Sigaud via Digitalmars-d-learn wrote: On Mon, Aug 11, 2014 at 10:09 PM, H. S. Teoh via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Mon, Aug 11, 2014 at 07:47:44PM +, Klaus via Digitalmars-d-learn wrote: I mean when writing a D lexer, you necessarly reach the moment when you think: Oh no! is this feature just here to suck ? The crazy variety of ways to write string literals in D, OTOH, *is* a bit over the top, as I found out myself when I also tried writing a D lexer. :-P Out of curiosity, how does a lexer deal with heredocs? It's a sort of... user-defined token, right? In Flex, one way you can implement heredocs is to have a separate mode where the lexer is scanning for the ending string. So basically you have a sub-lexer that treats the heredoc as three tokens, one that defines the ending string for the heredoc (which is never returned to the caller), one that contains the content of the heredoc, and the terminating token (also never returned to the caller). It's not that much different from any other string literal scanning (the lexer must switch into string literal mode where things like \n and \t have a different meaning than in the program code proper, and it exits that mode when it encounters the terminating ''), except that here, the terminating delimiter is variable. T -- Real men don't take backups. They put their source on a public FTP-server and let the world mirror it. -- Linus Torvalds
Re: Are Delimited strings and HereDoc strings just here to suck ?
On Monday, 11 August 2014 at 20:10:47 UTC, H. S. Teoh via Digitalmars-d-learn wrote: On Mon, Aug 11, 2014 at 07:47:44PM +, Klaus via Digitalmars-d-learn wrote: I mean when writing a D lexer, you necessarly reach the moment when you think: Oh no! is this feature just here to suck ? I use heredocs every now and then when I need to embed long strings in my program. It's one of the things I *like* about D, in fact. Nobody wants to manually parenthesize every quoted line with '...\n' when the program need to incorporate several pages of built-in help text, for example. Delimited strings are useful when writing code/text generators when you need to be able to use ' and as literal characters without crazy leaning-toothpick syndrome \x\y\z\w\'s sprinkled everywhere. The crazy variety of ways to write string literals in D, OTOH, *is* a bit over the top, as I found out myself when I also tried writing a D lexer. :-P T Yep I think you get what I mean: clearly over the top, particularly when each element of your arm is 50% over the top and then when you try to show the top with an over-sized arm then it's clearly an over-toped position.
Re: Are Delimited strings and HereDoc strings just here to suck ?
On Mon, Aug 11, 2014 at 10:58 PM, H. S. Teoh via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: In Flex, one way you can implement heredocs is to have a separate mode where the lexer is scanning for the ending string. So basically you have a sub-lexer that treats the heredoc as three tokens, one that defines the ending string for the heredoc (which is never returned to the caller), one that contains the content of the heredoc, and the terminating token (also never returned to the caller). Ah, a small, specialized sub-lexer. OK, I get it.
Re: Separate Printing Mantissa and Exponent of a Floating Point
On Monday, 11 August 2014 at 15:37:29 UTC, Dominikus Dittes Scherkl wrote: Should be patrs[1], he? No, parts[1] contains a slice to the e separating the mantissa from the exponent.
Re: Separate Printing Mantissa and Exponent of a Floating Point
On Monday, 11 August 2014 at 15:30:30 UTC, Justin Whear wrote: 1. http://dlang.org/phobos/std_bitmanip.html#.FloatRep Great! Thx.
Re: Separate Printing Mantissa and Exponent of a Floating Point
On Monday, 11 August 2014 at 15:30:30 UTC, Justin Whear wrote: 1. http://dlang.org/phobos/std_bitmanip.html#.FloatRep I'm lacking a use case. See http://dlang.org/library/std/bitmanip/FloatRep.html Is unsafe *(cast(FloatRep*)float_instance) the only way to use this?
Faster ways to redirect stdout of child process to file
I use auto pipes = pipeProcess( cmd, Redirect.stdout | Redirect.stderr ); to redirect stdout of the newly created subprocess via pipes to a file. The redirect itself happens in a newly created thread (because I need to wait for the subprocess to finish to take the exact elapsed time) doing basically: pipes.stdout.byChunk( 1024 * 1024 ).copy( cof.lockingTextWriter() ); This happens to use much of my CPU time (~25%). I wonder if there is no faster way to do this. I use this method because I want to be platform independent. Thomas
Re: Are Delimited strings and HereDoc strings just here to suck ?
On Monday, 11 August 2014 at 19:47:46 UTC, Klaus wrote: I mean when writing a D lexer, you necessarly reach the moment when you think: Oh no! is this feature just here to suck ? They are and they do.
Re: Are Delimited strings and HereDoc strings just here to suck ?
On Monday, 11 August 2014 at 22:20:54 UTC, Brian Schott wrote: On Monday, 11 August 2014 at 19:47:46 UTC, Klaus wrote: I mean when writing a D lexer, you necessarly reach the moment when you think: Oh no! is this feature just here to suck ? They are and they do. Also, use this: https://github.com/Hackerpilot/libdparse
Re: Are Delimited strings and HereDoc strings just here to suck ?
On Monday, 11 August 2014 at 22:24:28 UTC, Brian Schott wrote: On Monday, 11 August 2014 at 22:20:54 UTC, Brian Schott wrote: On Monday, 11 August 2014 at 19:47:46 UTC, Klaus wrote: I mean when writing a D lexer, you necessarly reach the moment when you think: Oh no! is this feature just here to suck ? They are and they do. Also, use this: https://github.com/Hackerpilot/libdparse Sorry...I've been stupid...how could I missed that...Sometime I hate myself.
Re: Are Delimited strings and HereDoc strings just here to suck ?
On Monday, 11 August 2014 at 22:56:27 UTC, Klaus wrote: On Monday, 11 August 2014 at 22:24:28 UTC, Brian Schott wrote: On Monday, 11 August 2014 at 22:20:54 UTC, Brian Schott wrote: On Monday, 11 August 2014 at 19:47:46 UTC, Klaus wrote: I mean when writing a D lexer, you necessarly reach the moment when you think: Oh no! is this feature just here to suck ? They are and they do. Also, use this: https://github.com/Hackerpilot/libdparse Sorry...I've been stupid...how could I missed that...Sometime I hate myself. https://github.com/search?l=Do=descq=stars%3A%3D0ref=advsearchs=updatedtype=Repositories
Re: overloads and parents. __traits confusion
On Monday, 11 August 2014 at 13:00:27 UTC, John Colvin wrote: alias Parent = TypeTuple!(__traits(parent, foo!float))[0]; Say hello to optional parens - you are trying to call foo!float() here and apply result to trait.
