See: http://d-programming-language.org/lex.html
It says:
q{ @ } // error, @ is not a valid D token
but...
http://d-programming-language.org/lex.html#Token
This clearly shows that @ is a token.
So, which is it?
On 25/09/11 4:49 PM, Peter Alexander wrote:
See: http://d-programming-language.org/lex.html
It says:
q{ @ } // error, @ is not a valid D token
but...
http://d-programming-language.org/lex.html#Token
This clearly shows that @ is a token.
So, which is it?
btw...
import std.stdio;
void
On 09/25/2011 05:49 PM, Peter Alexander wrote:
See: http://d-programming-language.org/lex.html
It says:
q{ @ } // error, @ is not a valid D token
but...
http://d-programming-language.org/lex.html#Token
This clearly shows that @ is a token.
So, which is it?
@ is a token. The documentation
On Sun, 25 Sep 2011 18:10:53 +0200, Timon Gehr wrote:
> @ is a token. The documentation was probably written when it was not.
Yep, so Peter's stumbled on a bug. Bugzilla that shit, Peter! :D
On 26/09/11 2:47 AM, Bernard Helyer wrote:
On Sun, 25 Sep 2011 18:10:53 +0200, Timon Gehr wrote:
@ is a token. The documentation was probably written when it was not.
Yep, so Peter's stumbled on a bug. Bugzilla that shit, Peter! :D
Well, if outdated documentation is a bug, then I suppose so.
On Monday, September 26, 2011 12:09 Peter Alexander wrote:
> On 26/09/11 2:47 AM, Bernard Helyer wrote:
> > On Sun, 25 Sep 2011 18:10:53 +0200, Timon Gehr wrote:
> >> @ is a token. The documentation was probably written when it was not.
> >
> > Yep, so Peter's stumbled on a bug. Bugzilla that shit
On 26/09/11 8:30 PM, Jonathan M Davis wrote:
On Monday, September 26, 2011 12:09 Peter Alexander wrote:
On 26/09/11 2:47 AM, Bernard Helyer wrote:
On Sun, 25 Sep 2011 18:10:53 +0200, Timon Gehr wrote:
@ is a token. The documentation was probably written when it was not.
Yep, so Peter's stumb
On Tuesday, September 27, 2011 11:05 Peter Alexander wrote:
> On 26/09/11 8:30 PM, Jonathan M Davis wrote:
> > On Monday, September 26, 2011 12:09 Peter Alexander wrote:
> >> On 26/09/11 2:47 AM, Bernard Helyer wrote:
> >>> On Sun, 25 Sep 2011 18:10:53 +0200, Timon Gehr wrote:
> @ is a token.
On 27/09/11 9:02 PM, Jonathan M Davis wrote:
On Tuesday, September 27, 2011 11:05 Peter Alexander wrote:
On 26/09/11 8:30 PM, Jonathan M Davis wrote:
On Monday, September 26, 2011 12:09 Peter Alexander wrote:
On 26/09/11 2:47 AM, Bernard Helyer wrote:
On Sun, 25 Sep 2011 18:10:53 +0200, Timon
Hello!
The code in the header leads to assertion!
But the user inputed data don't must leads to any assertions!
Sorry, fixed in the newest DMD also as the other bug in regex...
On Monday, 17 July 2017 at 20:43:29 UTC, unDEFER wrote:
Sorry, fixed in the newest DMD also as the other bug in regex...
Oh, no. Not fixed. Fixed only other bug.
On Monday, 17 July 2017 at 17:00:10 UTC, unDEFER wrote:
Hello!
The code in the header leads to assertion!
But the user inputed data don't must leads to any assertions!
This regular expression is invalid.
[bar] - Matches 'b' or 'a' or 'r'
[^bar] - Matches everything but 'b' or 'a' or 'r'.
So, [
On Tuesday, 18 July 2017 at 08:56:12 UTC, Anton Fediushin wrote:
Not a bug, but I think that `regex()` should fail with a nice
exception, not silently fail.
Yes, exception, not assert.
On Tuesday, 18 July 2017 at 16:34:39 UTC, unDEFER wrote:
On Tuesday, 18 July 2017 at 08:56:12 UTC, Anton Fediushin wrote:
Not a bug, but I think that `regex()` should fail with a nice
exception, not silently fail.
Yes, exception, not assert.
The forum is not a bugtracker
On Monday, 17 July 2017 at 17:00:10 UTC, unDEFER wrote:
Hello!
The code in the header leads to assertion!
But the user inputed data don't must leads to any assertions!
Please file at:
issues.dlang.org
Thanks!
---
Dmitry Olshansky
On Wednesday, 19 July 2017 at 16:59:24 UTC, Dmitry Olshansky
wrote:
On Monday, 17 July 2017 at 17:00:10 UTC, unDEFER wrote:
Please file at:
issues.dlang.org
Thanks!
---
Dmitry Olshansky
Thank you,
https://issues.dlang.org/show_bug.cgi?id=17668
https://issues.dlang.org/show_bug.cgi?id=17667
Q: Will D likely ever be picked up by a major compiler manufacturer?
The language looks really good, but without a major compiler manufacturer
promoting & supporting the language, it seems major projects will never be
undertaken by large corporations.
This is what I am hearing from the firm
On Sat, 04 Jun 2011 07:01:31 +0300, William Bolish
wrote:
Q: Will D likely ever be picked up by a major compiler manufacturer?
The language looks really good, but without a major compiler manufacturer
promoting & supporting the language, it seems major projects will never
be
undert
William Bolish Wrote:
> Q: Will D likely ever be picked up by a major compiler manufacturer?
>
> The language looks really good, but without a major compiler manufacturer
> promoting & supporting the language, it seems major projects will never be
> undertaken by large corpora
On 6/3/2011 9:01 PM, William Bolish wrote:
> Q: Will D likely ever be picked up by a major compiler manufacturer?
>
> The language looks really good, but without a major compiler manufacturer
> promoting & supporting the language, it seems major projects will never be
>
Am 04.06.2011 06:01, schrieb William Bolish:
Q: Will D likely ever be picked up by a major compiler manufacturer?
The language looks really good, but without a major compiler manufacturer
promoting& supporting the language, it seems major projects will never be
undertaken by large corporat
On Fri, Jun 3, 2011 at 11:08 PM, Vladimir Panteleev
wrote:
> On Sat, 04 Jun 2011 07:01:31 +0300, William Bolish
> wrote:
>
>> Q: Will D likely ever be picked up by a major compiler manufacturer?
>>
>> The language looks really good, but without a major compile
On Sat, Jun 4, 2011 at 3:10 AM, Daniel Gibson wrote:
> Am 04.06.2011 06:01, schrieb William Bolish:
>>
>> Q: Will D likely ever be picked up by a major compiler manufacturer?
>>
>> The language looks really good, but without a major compiler manufacturer
>> promot
On 06/03/2011 11:01 PM, William Bolish wrote:
Q: Will D likely ever be picked up by a major compiler manufacturer?
The language looks really good, but without a major compiler manufacturer
promoting& supporting the language, it seems major projects will never be
undertaken by l
Brad gave a sensible response. If I were asked, I'd point out that we
are making serious headways with the GNU compiler suite integration; I
hope we'll have some news soon about that.
Looking forward to that!
Beyond that, a company looking for a safe bet would find it difficult to
choose
Am 04.06.2011 21:33, schrieb Trass3r:
>> Brad gave a sensible response. If I were asked, I'd point out that we
>> are making serious headways with the GNU compiler suite integration; I
>> hope we'll have some news soon about that.
>
> Looking forward to that!
>
>
>> Beyond that, a company lookin
Am 04.06.2011 21:50, schrieb Trass3r:
>> Two? I only know of that company in Berlin that does something related
>> to stalking people on the Internet to deliver personalized ads or
>> something like that. What's the other one?
>
> To my knowledge http://www.funkwerk-itk.com/
Interesting, thanks!
Two? I only know of that company in Berlin that does something related
to stalking people on the Internet to deliver personalized ads or
something like that. What's the other one?
To my knowledge http://www.funkwerk-itk.com/
I'll admit this is a bit unorthodox, but...I've been wondering about
something regarding Phobos regex's implementation and internal
architecture: Just how compartmentalized is the parsing of standard PCRE
regex syntax vs actual usage of regexes once parsed?
Or more to the point, (and again, I
On 4/13/17 7:53 AM, Nick Sabalausky (Abscissa) wrote:
I'll admit this is a bit unorthodox, but...I've been wondering about
something regarding Phobos regex's implementation and internal
architecture: Just how compartmentalized is the parsing of standard PCRE
regex syntax vs actual usage of regexe
hello, first message here.
Just started learning about D
Looking to see if D can be used as 'System language for Grid
computing'
Specifically for building up distributed coordinated services
such as distributed File systems/etc.
One specific thing I am looking for is Clojure avout like
Software
Thanks all for the helpful responses. Since we seem to have some real
Unicode-knowledge people here, I'd like to repost a question I had asked
elsewhere awhile back, but didn't get an answer:
Can someone explain how
Nick Sabalausky wrote:
Thanks all for the helpful responses. Since we seem to have some real
Unicode-knowledge people here, I'd like to repost a question I had asked
elsewhere awhile back, but didn't get an answer:
---
How many GC's do we get, if we build a D application linking it to a D
library statically, or dynamically, or by loading it at runtime?
It seems to me, that one thing people really want in this discussion is to
be able to select a single allocation strategy for their application,
regardless
Howdy,
This is a bit involved, so bear with me.
Suppose I have a template, Decider(Args...) and some other templates,
Option1(...), Option2(...), etc.
The job of Decider() is to decide, based on the given parameters, which
of the possible OptionN templates to use.
Decider uses "static if"
On Tuesday, 4 February 2014 at 13:52:53 UTC, Regan Heath wrote:
It seems to me, that one thing people really want in this
discussion is to be able to select a single allocation strategy
for their application, regardless of the libraries involved.
I want:
1. To use full GC during start up and
I've been trying to make a grammar for the Haxe langauge, and I've been
having a hell of a time emulating it's expression-based if/if-else (as
opposed to statement-based as in D). I'm sure a big part of it is my
inexperience with writing grammars, but I've also been starting to wonder if
it's i
Austin Hastings wrote:
If Decider uses Option1.sizeof, does any Option1 code get emitted?
For sizeof to be known, the template would have to be instantiated, yes.
If Decider uses some external function that makes use of type aliases in
Option1, (example: Option1() { alias byte value_t; }
On 10/24/2010 5:16 AM, Simen kjaeraas wrote:
Austin Hastings wrote:
If Decider uses Option1.sizeof, does any Option1 code get emitted?
For sizeof to be known, the template would have to be instantiated, yes.
Instantiated does not necessarily imply emitting code, I think. (Of
course, this
On Sun, 24 Oct 2010 00:06:23 -0400, Austin Hastings
wrote:
Howdy,
This is a bit involved, so bear with me.
Suppose I have a template, Decider(Args...) and some other templates,
Option1(...), Option2(...), etc.
The job of Decider() is to decide, based on the given parameters, which
of
On Monday, October 25, 2010 06:08:24 Austin Hastings wrote:
> On 10/24/2010 5:16 AM, Simen kjaeraas wrote:
> > Austin Hastings wrote:
> >> If Decider uses Option1.sizeof, does any Option1 code get emitted?
> >
> > For sizeof to be known, the template would have to be instantiated, yes.
>
> Insta
On 25-ott-10, at 18:04, Steven Schveighoffer wrote:
On Sun, 24 Oct 2010 00:06:23 -0400, Austin Hastings > wrote:
Howdy,
This is a bit involved, so bear with me.
Suppose I have a template, Decider(Args...) and some other
templates, Option1(...), Option2(...), etc.
The job of Decider() is
Howdy,
I'm jammed up against a variation of the issue#3745/3770 AA linkage problem.
In my case, I'm using an int[ string ] AA, and I'm getting the dreaded
Error 42: Symbol Undefined
_D6object28__T16AssociativeArrayTAyaTiZ16AssociativeArray4keysMFNdZAAya
My code looks something like:
class g
"Nick Sabalausky" wrote in message
news:h7fl1o$f8...@digitalmars.com...
> I've been trying to make a grammar for the Haxe langauge, and I've been
> having a hell of a time emulating it's expression-based if/if-else (as
> opposed to statement-based as in D). I'm sure a big part of it is my
> in
Nick Sabalausky Wrote:
> "Nick Sabalausky" wrote in message
> news:h7fl1o$f8...@digitalmars.com...
> > I've been trying to make a grammar for the Haxe langauge, and I've been
> > having a hell of a time emulating it's expression-based if/if-else (as
> > opposed to statement-based as in D). I'm
Nick Sabalausky Wrote:
> "Nick Sabalausky" wrote in message
> news:h7fl1o$f8...@digitalmars.com...
> > I've been trying to make a grammar for the Haxe langauge, and I've been
> > having a hell of a time emulating it's expression-based if/if-else (as
> > opposed to statement-based as in D). I'm
"Tim M" wrote in message
news:h7hrf2$vj...@digitalmars.com...
>
> Although I don't really understand your problem or how it relates to the D
> lang.
It doesn't really relate to D. Hence "[OT]" off-topic ;) But there seem to
be a number of people here that are good with language theory (or at l
Nick are you on freenode.org #haxe ?
:-)
"Danny Wilson" wrote in message
news:op.uzpaihg5bmu...@danny-wilsons-ep45-ds4.local...
> Nick are you on freenode.org #haxe ?
>
> :-)
No, I haven't really used IRC in ages. If you (or anyone) wanted to contact
me privately though, my email is here (
http://www.semitwist.com/contact.html ) (yes
Shooting in the dark here (I can't reproduce the error for
whatever reason), but for similar problems, I've found this fixes
it:
Add a function somewhere in your file that says:
void hackAroundBug() {
writeln(typeid(int[string]));
}
You never actually need to call it. Just putting it there
The hackAroundBug()/typeid approach didn't work for me - I still got the
error 42. Presently, I'm using a local method, but this is annoying for
obvious reasons:
string[] aa_keys( int[ string ] aa )
{
return aa.keys;
}
Even more annoying is that this wor
{} for tuples hasn't worked out since it was deemed ambiguous with
delegate syntax (was it for the case of empty statements/tuple?).
How about the following syntax instead:
{} // delegate (existing syntax)
q{...} // string literal (existing syntax)
t{...} // tuple(a,b) (proposed synt
On 05.04.2016 07:45, Timothee Cour via Digitalmars-d wrote:
How about the following syntax instead:
{} // delegate (existing syntax)
q{...} // string literal (existing syntax)
t{...} // tuple(a,b) (proposed syntax)
T{...} // TypeTuple!(a,b) (proposed syntax)
In existing syntax, most
On Tuesday, 5 April 2016 at 05:45:08 UTC, Timothee Cour wrote:
{} for tuples hasn't worked out since it was deemed ambiguous
with delegate syntax (was it for the case of empty
statements/tuple?).
How about the following syntax instead:
{} // delegate (existing syntax)
q{...} // s
On Tuesday, 5 April 2016 at 15:29:06 UTC, ZombineDev wrote:
Action action = {}; // error: `{}` is an empty tuple, can't be
assigned to delegates
auto t = {}; // deduced as an empty tuple.
Also, the non-empty {} syntax can't be mistaken for a function
literal because non-empty function literals
On Tuesday, 5 April 2016 at 05:45:08 UTC, Timothee Cour wrote:
{} for tuples hasn't worked out since it was deemed ambiguous
with delegate syntax (was it for the case of empty
statements/tuple?).
How about the following syntax instead:
{} // delegate (existing syntax)
q{...} // s
On Tuesday, 5 April 2016 at 16:56:15 UTC, Jack Stouffer wrote:
Tuple and AliasSeq are library types, so the chance that they
will be added into the language is slim to none.
Yes on Tuple, but AliasSeq actually is in the language (just
unnamed there, it is what you get with T... in a template
On Tuesday, 5 April 2016 at 16:34:49 UTC, jmh530 wrote:
On Tuesday, 5 April 2016 at 15:29:06 UTC, ZombineDev wrote:
Action action = {}; // error: `{}` is an empty tuple, can't be
assigned to delegates
auto t = {}; // deduced as an empty tuple.
Also, the non-empty {} syntax can't be mistaken for
stead:
{} // delegate (existing syntax)
q{...} // string literal (existing syntax)
t{...} // tuple(a,b) (proposed syntax)
T{...} // TypeTuple!(a,b) (proposed syntax)
See also [1] where i propose i{...} for a D analog of C++11's uniform
initialization.
[1] EMAIL: uniform initialization in D (as in
tuple?).
How about the following syntax instead:
{} // delegate (existing syntax)
q{...} // string literal (existing syntax)
t{...} // tuple(a,b) (proposed syntax)
T{...} // TypeTuple!(a,b) (proposed syntax)
See also [1] where i propose i{...} for a D analog of C++11'
as it for the case of empty statements/tuple?).
How about the following syntax instead:
{} // delegate (existing syntax)
q{...} // string literal (existing syntax)
t{...} // tuple(a,b) (proposed syntax)
T{...} // TypeTuple!(a,b) (proposed syntax)
See also [1] where i propose i{...} fo
On Tuesday, 5 April 2016 at 14:00:46 UTC, ag0aep6g wrote:
I'm not sure if the new syntax is worth adding, though.
`T{...}` (or `T[...]`) saves just one character over `T!(...)`.
The latter can be done without touching the language. For the
value tuple, one can do `alias t = std.typecons.tuple;`
63 matches
Mail list logo
