Re: '<' and '>' are "matching delimiters"?
On Saturday, 30 June 2012 at 05:32:31 UTC, Jonathan M Davis wrote:
On Saturday, June 30, 2012 07:05:04 Mehrdad wrote:
They are, according to the "Nesting Delimiters" table in:
http://dlang.org/lex.html
When exactly are they seen as nesting delimiters?
When they're used in delimited strings. That's the whole point
of that
section. The examples are
q"(foo(xxx))" // "foo(xxx)"
q"[foo{]" // "foo{"
but they could have included something like
q"" // "foo{"
- Jonathan M Davis
Ooh I didn't understand that. lol it seems so obvious
now. >_<
Thanks!
Re: '<' and '>' are "matching delimiters"?
On Saturday, June 30, 2012 07:05:04 Mehrdad wrote:
> They are, according to the "Nesting Delimiters" table in:
> http://dlang.org/lex.html
>
>
> When exactly are they seen as nesting delimiters?
When they're used in delimited strings. That's the whole point of that
section. The examples are
q"(foo(xxx))" // "foo(xxx)"
q"[foo{]" // "foo{"
but they could have included something like
q"" // "foo{"
- Jonathan M Davis
'<' and '>' are "matching delimiters"?
They are, according to the "Nesting Delimiters" table in: http://dlang.org/lex.html When exactly are they seen as nesting delimiters?
Re: D in the cloud with cassandra ?
It's pretty new and has not yet started commercially but should so in the coming months. Red Hat's OpenShift Platform might catch your needs. I am not fully sure if it is capable of doing all you want, especially the Cassandra thing but a search for 'openshift diy cartridge' should bring you further. OpenShift is no IaaS but a PaaS but gives you choice on what you want to run as your cartridge as long as the binary runs on a x64 Red Hat Enterprise Linux and speaks http. On Thursday, 28 June 2012 at 00:33:28 UTC, Knud Soerensen wrote: Hi. I looking into making a website for the cloud and I was wondering if anyone have tried D in connection with amazon EC2, Google app engine or similar cloud service ? I am also planing to use a column store as Apache's Cassandra have anyone tried it with D ? Knud PS.) I have been away from the D list for 4 years so this might be a stupid question, but skimming trough the change log for dmd noticed references to ICE. What does ICE stand for ??
Re: Raw binary(to work without OS) in D
On Thursday, 28 June 2012 at 16:50:59 UTC, David Nadlinger wrote: On Thursday, 28 June 2012 at 14:35:24 UTC, Andrei Alexandrescu wrote: On 6/28/12 10:07 AM, Roman D. Boiko wrote: On Thursday, 28 June 2012 at 14:04:37 UTC, Mehrdad wrote: I think just exposing them via .sig and .exp might be the way to go? sig is easy to confuse with sign .mantissa and .exp .exp might potentially lead to confusion regarding std.math.exp with UFCS in place. Not that this would be a huge deal, but since new property would be used only very rarely anyway, I don't think going for a longer name like .exponent or even rawExponent/exponentBits/… would be a problem. David How about .mant and .expo? That's what I'm using in the BigDecimal/BigFloat modules as private names. The property names are .coefficient and .exponent.
Re: Inferred return types
class Foo
{
auto foo ()
{
return "Foo";
}
}
class Bar : Foo
{
auto foo ()
{
return "Bar";
}
}
Ouch, what a terrible idea to base a class hierachy on inference.
But nonetheless covariance checking should be performed after inference.
Re: Inferred return types
On 2012-06-29 21:25, Timon Gehr wrote: This is a bug I have run into as well, but I have missed to report it. Reported: http://d.puremagic.com/issues/show_bug.cgi?id=8318 -- /Jacob Carlborg
Re: Inferred return types
Jacob Carlborg:
Is that supposed to work?
If the D specs don't agree, then in this case I think the D specs
need to be modified.
Second, it seems it's not possible to override a method with an
inferred return type,
This seems a bug report fit for Bugzilla:
class Foo {
string foo() {
return "Foo.foo";
}
}
class Bar : Foo {
override /*string*/ foo() { // compiles un-commenting string
return "Bar.foo";
}
}
void main() {}
Bye,
bearophile
Re: Inferred return types
On 06/29/2012 09:17 PM, Jacob Carlborg wrote:
I just noticed that the return type of a function can be inferred
without using a storage class:
@property foo ()
{
return "foo";
}
void main ()
{
string str = foo;
}
Is that supposed to work?
Yes.
The specification says:
"If it does not already have a storage class, use the auto storage class."
But @property is not a storage class. It seems I can put most of the
attributes there instead of @property, both those with and without a @.
The spec (and the implementation as well) considers them to be storage
classes. I think the term 'storage class' should be retired.
Second, it seems it's not possible to override a method with an inferred
return type, as the example below shows:
class Foo
{
auto foo ()
{
return "Foo";
}
}
class Bar : Foo
{
auto foo ()
{
return "Bar";
}
}
void main ()
{
Foo f = new Bar;
writeln(f.foo());
}
Results in:
Error: function main.Bar.foo of type () overrides but is not covariant
with main.Foo.foo of type ()
--
/Jacob Carlborg
This is a bug I have run into as well, but I have missed to report it.
Inferred return types
I just noticed that the return type of a function can be inferred
without using a storage class:
@property foo ()
{
return "foo";
}
void main ()
{
string str = foo;
}
Is that supposed to work? The specification says:
"If it does not already have a storage class, use the auto storage class."
But @property is not a storage class. It seems I can put most of the
attributes there instead of @property, both those with and without a @.
Second, it seems it's not possible to override a method with an inferred
return type, as the example below shows:
class Foo
{
auto foo ()
{
return "Foo";
}
}
class Bar : Foo
{
auto foo ()
{
return "Bar";
}
}
void main ()
{
Foo f = new Bar;
writeln(f.foo());
}
Results in:
Error: function main.Bar.foo of type () overrides but is not covariant
with main.Foo.foo of type ()
--
/Jacob Carlborg
Re: Raw binary(to work without OS) in D
On Thursday, 28 June 2012 at 16:50:59 UTC, David Nadlinger wrote: On Thursday, 28 June 2012 at 14:35:24 UTC, Andrei Alexandrescu wrote: On 6/28/12 10:07 AM, Roman D. Boiko wrote: On Thursday, 28 June 2012 at 14:04:37 UTC, Mehrdad wrote: I think just exposing them via .sig and .exp might be the way to go? sig is easy to confuse with sign .mantissa and .exp .exp might potentially lead to confusion regarding std.math.exp with UFCS in place. Not that this would be a huge deal, but since new property would be used only very rarely anyway, I don't think going for a longer name like .exponent or even rawExponent/exponentBits/… would be a problem. David In my BigDecimal/BigFloat modules I use .coefficient and .exponent externally but .mant and .expo internally. It would be nice to be consistent -- I can adapt to whatever is best. Paul
Re: Douglas Crockford on JavaScript and bad styles
On 06/29/2012 09:13 AM, Manipulator wrote: http://www.youtube.com/channel/UCF0LH5GvQI3u9c36oAAzWXQ/videos Just watched these videos with Douglas Crockford and thought that he made some very good points. Why we still design languages that invite bad styles? That is quite obvious from Crockford's talk alone: Because that kind of language is popular. I feel that many people in the D community is the exhibitionist type of person. Let's stop! I'd have to disagree with this statement, because of the following facts: 1. There is no formal language specification. 2. There are fewer unexpected edge cases, because the language is better designed than JS. 3. The compiler does not implement them correctly, and abusing bugs is likely to result in code that changes its behaviour or becomes illegal. Because of 1, nobody can study the language specification, because of 2 and 3, finding unexpected edge cases is unproductive (you are more likely to segfault the compiler than to find exploitable behaviour), and because of 1 and 3, found edge cases are hard to successfully leverage into bad style D code. D/DMD in its current state does not support exhibitionism!
Re: Raw binary(to work without OS) in D
Iain Buclaw: From a user perspective? A switch that has a less ugly than -vimplicit_library_calls. Which spurts out messages like: "Function %s builds a closure", func http://d.puremagic.com/issues/show_bug.cgi?id=5070 Bye, bearophile
Re: Raw binary(to work without OS) in D
On 28 June 2012 18:02, Sean Kelly wrote: > On Jun 28, 2012, at 9:45 AM, Iain Buclaw wrote: >> >> Wouldn't it be useful if the compiler had diagnostics for all implicit >> allocations it makes (ie: closures, array literals)? Similar to that >> of the -vtls switch. These such things you may want to avoid in a >> freestanding environment (no link to C runtime). > > Yes it would. I guess the question is how to expose this. Generally > speaking though, array append type operations allocate, AA insertions > allocate, and non-scope delegate use allocates. I think that's it. >From a user perspective? A switch that has a less ugly than -vimplicit_library_calls. Which spurts out messages like: "Function %s builds a closure", func or "Expression %s makes implicit allocation call to %s", expr, func -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: New hash API: namespace
Don Clugston wrote: On 25/06/12 20:04, Jesse Phillips wrote: On Monday, 25 June 2012 at 16:09:43 UTC, Felix Hufnagel wrote: +1 for hashes into std.hash and cryptographic primitives into std.crypto and we should have a std.net (std.uri, std.socket, std.socketstream , std.net.curl, ...), std.io. for (Outbuffer, file, ) and probably std.database or something like that for (csv, json, xml, ...) I'd be for not being so flat. I reckon, follow biology. There's kingdom.phyllus.class.order.family.genus.species But in practice, that's far too clumsy. Instead, everyone just uses genus.species. And this works even though there are more than a million species. So I reckon two levels of modules is enough. More than that is clumsy. And, if you're not sure where something should be, because there are two or more equally valid alternatives, it should probably be a level closer to the root of the tree. I'd not generalize that much. Sometimes two levels are enough, sometimes there are three or more. I'd say "It depends" :) And yes, I think we should have std.net package. Hey, packages were created for that!
Re: LLVM IR influence on compiler debugging
On 29/06/12 08:04, bearophile wrote: This is a very easy to read article about the design of LLVM: http://www.drdobbs.com/architecture-and-design/the-design-of-llvm/240001128 That IR has a great effect on making it simpler to debug the compiler, I think this is important (and I think it partially explains why Clang was created so quickly): It's a good design, especially for optimisation tests. Although I can't see an immediate application of this for D. DMD's backend is nearly bug-free. (By which I mean, it has 100X fewer bugs than the front-end).
Re: New hash API: namespace
On 25/06/12 20:04, Jesse Phillips wrote: On Monday, 25 June 2012 at 16:09:43 UTC, Felix Hufnagel wrote: +1 for hashes into std.hash and cryptographic primitives into std.crypto and we should have a std.net (std.uri, std.socket, std.socketstream , std.net.curl, ...), std.io. for (Outbuffer, file, ) and probably std.database or something like that for (csv, json, xml, ...) I'd be for not being so flat. I reckon, follow biology. There's kingdom.phyllus.class.order.family.genus.species But in practice, that's far too clumsy. Instead, everyone just uses genus.species. And this works even though there are more than a million species. So I reckon two levels of modules is enough. More than that is clumsy. And, if you're not sure where something should be, because there are two or more equally valid alternatives, it should probably be a level closer to the root of the tree.
Re: D in the cloud with cassandra ?
On Thursday, 28 June 2012 at 00:33:28 UTC, Knud Soerensen wrote: Hi. I looking into making a website for the cloud and I was wondering if anyone have tried D in connection with amazon EC2, Google app engine or similar cloud service ? You can take a look on Azure VM (linux or windows). I am also planing to use a column store as Apache's Cassandra have anyone tried it with D ? Most of blob storages provides a rest api than can be easily implemented. Knud PS.) I have been away from the D list for 4 years so this might be a stupid question, but skimming trough the change log for dmd noticed references to ICE. What does ICE stand for ?? ICE - internal compiler error.
Re: LLVM IR influence on compiler debugging
I implemented a compiler back end with LLVM some time ago. The IM helped a lot in both, spotting errors in IM codegen and issues with target codegen (e.g. because of some misconfiguration). You always have the high level IM available as text and the unoptimized target assembler usually is pretty similar to the IM code and thus provides a great guide deciphering the assembler. Also the fact that you can output and modify a module as IM code to try certain things is really useful sometimes.
