My knowledge of compiler constructions is fairly limited and I
might be wrong, but it seems to me that the Scala compiler is
broken. Scala has gained some bad reputation for long build times
(just google for Scala and build time) which IMHO cannot be
explained by the large number of language
On Thursday, 3 April 2014 at 08:18:01 UTC, Bienlein wrote:
My knowledge of compiler constructions is fairly limited and I
might be wrong, but it seems to me that the Scala compiler is
broken. Scala has gained some bad reputation for long build
times (just google for Scala and build time) which
If I remember what the state of Groovy is (around 2012). The
compiler devs focussed quite heavily on functionality not
performance. Even refused to go that direction.
It was quite bad.
Its a real shame. I liked it. Although if they had and had
unsigned types I probably wouldn't be in D!
On Thursday, 3 April 2014 at 08:18:01 UTC, Bienlein wrote:
My knowledge of compiler constructions is fairly limited and I
might be wrong, but it seems to me that the Scala compiler is
broken. Scala has gained some bad reputation for long build
times (just google for Scala and build time) which
On Thursday, 3 April 2014 at 11:03:56 UTC, bachmeier wrote:
What about Clojure? It is getting real world use. The recent
release makes it easier to call Clojure from Java. Example:
IFn map = Clojure.var(clojure.core, map);
IFn inc = Clojure.var(clojure.core, inc);
map.invoke(inc,
On Thursday, 3 April 2014 at 08:43:33 UTC, Bienlein wrote:
If I remember what the state of Groovy is (around 2012). The
compiler devs focussed quite heavily on functionality not
performance. Even refused to go that direction.
It was quite bad.
Its a real shame. I liked it. Although if they
https://www.sociomantic.com/dunnhumby-acquires-sociomantic/
On Thursday, 3 April 2014 at 13:23:16 UTC, Paulo Pinto wrote:
I think you missed the post date.
I think so too ...
On 4/3/14, Don x...@nospam.com wrote:
https://www.sociomantic.com/dunnhumby-acquires-sociomantic/
Congrats!
I don't suppose there will be a blog post showcasing a successful exit
of a startup that used D as its core technology? It could be a nice
advertisement for D. :)
On Tuesday, 25 March 2014 at 00:08:27 UTC, bearophile wrote:
I don't mind, I am happy :-) Thank you for adding a sorely
needed function.
It's been merged :-)
I notice that he mentioned the objection to defining equality and
so on for the root object. I have heard this before from Philip
Wadler, and the more I think about it, the more it makes sense.
This is essentially the idea of removing every method from
Object, which we have dicussed before.
On Thursday, 3 April 2014 at 01:55:48 UTC, Andrei Alexandrescu
wrote:
A lot of them could apply to us as well.
https://www.youtube.com/watch?v=TS1lpKBMkgg
Andrei
His examination of the compare function was interesting. I think,
though, that it's misguided, and not one of Scala's problems.
A more interesting point of his is the limitation of Scala's
ability to optimize functions like filter... This is also a
problem in D, but not as visible as we do not have macros to
perform the sort of transformation he describes (turning filter
f1, filter f2, filter f3 into filter f1 f2 f3).
On Friday, 4 April 2014 at 01:14:37 UTC, Meta wrote:
A more interesting point of his is the limitation of Scala's
ability to optimize functions like filter... This is also a
problem in D, but not as visible as we do not have macros to
perform the sort of transformation he describes (turning
Whoops, should be:
import std.stdio;
void main()
{
float x1 = long.max;
float x2 = long.max - int.max;
writeln(typeof(x2).stringof, , x2);
}
Not that it makes a difference.
Meta:
Returning an int to denote less than, equal, and greater than
is a very small complexity, and makes it very fast to check the
result.
The point of that part of the rant is that using an integer is
very not-precise, typing-wise. Having more precise typing
sometimes helps.
In a
On Fri, Apr 04, 2014 at 00:59:23 +, Meta wrote:
His examination of the compare function was interesting. I think,
though, that it's misguided, and not one of Scala's problems.
Maybe not major, but it's not completely ignorable.
Returning an int to denote less than, equal, and greater than
On 4/3/2014 6:14 PM, Meta wrote:
A more interesting point of his is the limitation of Scala's ability to optimize
functions like filter... This is also a problem in D, but not as visible as we
do not have macros to perform the sort of transformation he describes (turning
filter f1, filter f2,
On Friday, 4 April 2014 at 01:31:20 UTC, bearophile wrote:
The point of that part of the rant is that using an integer is
very not-precise, typing-wise. Having more precise typing
sometimes helps.
In a little higher level language using a 3-value enum (as in
Haskell, more or less) is still
On Thu, Apr 03, 2014 at 18:51:56 -0700, Walter Bright wrote:
Since in D you can detect if a function is pure, and specialize
accordingly, it is not necessary to require that the filter function
be pure.
Is there a built-in compose operator or function (Haskell's (.)
operator)? How would you
On Friday, 4 April 2014 at 01:51:58 UTC, Walter Bright wrote:
Since in D you can detect if a function is pure, and specialize
accordingly, it is not necessary to require that the filter
function be pure.
That's true, but then somebody somewhere accidentally passes in a
delegate that
Meta:
I would agree if D actually had type-safe enums.
enum a
{
val = 1
}
enum b
{
val = 1
}
assert(a.val - b.val == 0);
C enums are mostly type unsafe. C++11 has enum class that is
strongly typed. D enums are intermediate (and it has final
switches). I have asked for
On 4/3/14, 7:04 AM, Don wrote:
https://www.sociomantic.com/dunnhumby-acquires-sociomantic/
Congratulations to all involved!
How will this impact the use of D at dunnhumby?
Andrei
On 4/3/2014 7:01 PM, Ben Boeckel wrote:
Is there a built-in compose operator or function (Haskell's (.)
operator)? How would you copy the common attributes of the composed
functions to the new function (if not builtin)?
The compiler does attribute inference for template functions and lambdas.
On 4/3/2014 7:00 PM, Meta wrote:
The upside in D is that you can explicitly mark delegates as pure and
have the compiler check for you, but that still puts the onus on the user to be
disciplined and not forget.
It's really like everything else in programming - at some point, if you don't
On 4/3/2014 7:19 PM, bearophile wrote:
I have asked for fully
typesafe enums in D, but in several years I think Walter has never answered, nor
he has explained why D has chosen such intermediate point. I presume this choice
is based on practical reasons, but I don't know exactly what they are
On 4/3/2014 7:19 PM, bearophile wrote:
I have asked for fully typesafe enums in D,
You can do this:
struct MyInt {
int x;
alias this x;
... put your various constraints here ...
}
to get typesafe enums. In fact, you can use this construct to create a type that
On Friday, 4 April 2014 at 04:31:41 UTC, Walter Bright wrote:
On 4/3/2014 7:19 PM, bearophile wrote:
I have asked for fully typesafe enums in D,
You can do this:
struct MyInt {
int x;
alias this x;
... put your various constraints here ...
}
to get typesafe enums.
On Wednesday, 2 April 2014 at 21:18:19 UTC, Dmitry Olshansky
wrote:
03-Apr-2014 00:46, Walter Bright пишет:
On 4/2/2014 12:38 PM, Dmitry Olshansky wrote:
memchr is already optimized by SIMD, and std.algorithm.find
uses memchr.
In general, enormous effort has been poured into optimizing C
On Wednesday, 2 April 2014 at 22:06:53 UTC, Walter Bright wrote:
Here's Andrei's proposal:
extern (C++) template nspace() {
int foo();
}
@namespace(nspace)
extern (C++) {
int foo();
}
One downside of this proposal is that if we ever (perish the
thought!) attempted to
On Wednesday, 2 April 2014 at 22:06:53 UTC, Walter Bright wrote:
A possible enhancement would be to allow (for all templates
with no parameters):
nspace.foo();
std.string - does it refer to phobos module or C++ string?
Same under windows. Is this compiler/phobos bug?
Though native doesn't mean as fast as other native languages. The
speed depends on used features. Well, number crunching can be
definitely sped up.
On Thursday, 3 April 2014 at 07:05:13 UTC, Ondrej Pokorny wrote:
Same under windows. Is this compiler/phobos bug?
I can tell *why* it's breaking right now, but have been unable to
understand what caused said breakage, or how it worked at all to
begin with.
Will reduce and file (and
This is not really spectacular. The intermediate byte code
generated by the C# compiler also in the past was transfered to
machine code. But this was happening at start-up time and this
way slowing down application start-up. The change MS now made is
only about reducing start-up times. It will
On Thursday, 3 April 2014 at 07:40:11 UTC, Bienlein wrote:
This is not really spectacular. The intermediate byte code
generated by the C# compiler also in the past was transfered to
machine code. But this was happening at start-up time and this
way slowing down application start-up. The change
Does anybody have any form of diagrams for CTFE? And its place in
the build process?
I'm in need of it for a report. So any help would be greatly
appreciated.
I would rather somebody who understood how its implemented to
help with this than me. After all I'll muck it up ;)
On Wednesday, 2 April 2014 at 21:43:05 UTC, Adam Wilson wrote:
On Wed, 02 Apr 2014 13:36:56 -0700, Orvid King
blah38...@gmail.com wrote:
On Wed, 02 Apr 2014 15:24:00 -0500, Paulo Pinto
pj...@progtools.org wrote:
So it finally happened, C# gets an AOT compiler in addition
to NGEN/JIT
as
On 4/2/14, Artur Skawina art.08...@gmail.com wrote:
template expand(alias A, alias M=Delay) {
mixin(q{alias expand = TypeTuple!(}
~ iota(A.length).map!q{,M!(A,[!a..$]~text(a)~)}().join()
~ q{);});
}
You can always use string mixins for these hacks. But
On 4/2/14, bearophile bearophileh...@lycos.com wrote:
In Python2 and Haskell it's a built-in feature.
But what is the performance cost? In D it is a compile-time feature,
everything can be inlined.
Also, what this shows is how you can take advantage of *existing*
features to implement something
On 4/2/14, Simen Kjærås simen.kja...@gmail.com wrote:
In fact, it does not even need to have arg and idx explicitly passed,
and the alias for Array is redundant.
Nice! I recall trying to use .length before but I've had some CT
errors. It was probs my fault.
On 4/2/14, Simen Kjærås simen.kja...@gmail.com wrote:
In fact, it does not even need to have arg and idx explicitly passed,
and the alias for Array is redundant.
Actually, I've just realized the inner Delay() becomes a nested
function with a hidden context pointer. If you mark the function as
On 4/3/14, Walter Bright newshou...@digitalmars.com wrote:
A possible enhancement would be to allow (for all templates with no
parameters):
nspace.foo();
My only problem with this is how it will affect existing code. E.g.:
template take(alias templ) { }
template take(T) { }
template
On 2014-04-03 03:48:18 +, Walter Bright newshou...@digitalmars.com said:
On 4/2/2014 7:14 PM, Michel Fortin wrote:
That's a contrived example.
Not at all. The whole point of using namespaces in C++ is to introduce
a scope. And the whole point of scopes is to have the same name in
V Thu, 3 Apr 2014 06:36:54 -0400
Michel Fortin michel.for...@michelf.ca napsáno:
On 2014-04-03 03:48:18 +, Walter Bright
newshou...@digitalmars.com said:
On 4/2/2014 7:14 PM, Michel Fortin wrote:
That's a contrived example.
Not at all. The whole point of using namespaces in C++
DanielKozák wrote in message
news:mailman.36.1396437697.19942.digitalmar...@puremagic.com...
I thought it was a stated goal of D to have C++ interoperability
for the same compiler suite?
E.g. dmd/dmc++, g++/gdc, ldc/clang…
This would be awesome. But it would be much better if DMD has
Walter Bright wrote in message news:lhi1lt$269h$1...@digitalmars.com...
Here's Andrei's proposal:
extern (C++) template nspace() {
int foo();
}
This is really ugly and complicated.
Why not just
pragma(cpp_namespace, outer)
{
pragma(cpp_namespace, inner)
{
Andrej Mitrovic:
But what is the performance cost?
In D the minimal one. In Python is not that important. And in
Haskell it's efficient.
Also, what this shows is how you can take advantage of
*existing*
features to implement something interesting. It shows power,
rather
than the ability
On Thursday, 3 April 2014 at 08:59:44 UTC, Andrej Mitrovic wrote:
On 4/2/14, Artur Skawina art.08...@gmail.com wrote:
template expand(alias A, alias M=Delay) {
mixin(q{alias expand = TypeTuple!(}
~
iota(A.length).map!q{,M!(A,[!a..$]~text(a)~)}().join()
~
On 02/04/14 23:00, James Buren wrote:
On Wednesday, 2 April 2014 at 15:49:18 UTC, Jacob Carlborg wrote:
Use a compiler that can already parse C, i.e. Clang.
Use a compiler that can handle those extensions, i.e. Clang.
I'm already wanting to reuse an existing parser or compiler frontend.
On 03/04/14 01:16, Rikki Cattermole wrote:
Interestingly I was having a play recently with a CTFE'd macro
preprocessor in the hope that I could push it through a c lexer and
create via template mixins the entire bindings to files.
Few limitations like string imports not recursive on Windows
On 04/03/14 10:56, Andrej Mitrovic wrote:
On 4/2/14, Artur Skawina art.08...@gmail.com wrote:
template expand(alias A, alias M=Delay) {
mixin(q{alias expand = TypeTuple!(}
~ iota(A.length).map!q{,M!(A,[!a..$]~text(a)~)}().join()
~ q{);});
}
You can
On Wednesday, 2 April 2014 at 20:53:53 UTC, Joseph Rushton
Wakeling wrote:
You could do much worse than a Wordpress blog -- simple, has
built-in comments and lots of plugins, talks very easily to
lots of the rest of the internet ...
...and it has all the security of a plastic sieve filled
On 03/04/14 00:07, Walter Bright wrote:
Here's Andrei's proposal:
extern (C++) template nspace() {
int foo();
}
It would be accessed in D by:
nspace!().foo();
A possible enhancement would be to allow (for all templates with no
parameters):
nspace.foo();
Note
On 4/3/14, Artur Skawina art.08...@gmail.com wrote:
Actually, they are *much easier* to debug than the recursive templates
-- because you can always look at the generated code, something that
is impossible when using the templates.
Personally I think we need a third mechanism. I would totally
Walter Bright:
That's like saying inlining has no point because it doesn't
have a particular syntax.
Hopefully Dmitry Olshansky can explain why you are probably wrong
regarding the proposed feature.
Bye,
bearophile
I am not sure what is the best option, but it should be readable
and obvious. So I might prefer to just have :: if possible.
Somewhat annoying and verbose, so I am not sure about this, but
the advantage is that it is easy to see what is C++ and what is D
function calls.
On Thursday, 3 April 2014 at 13:38:48 UTC, Andrej Mitrovic wrote:
static if (is(T == int))
FilterInts ~= T; // populate a type tuple
It would have been a very complex and non-precedent feature, much
more so than a simple static foreach.
I personally did not have any
On 04/03/14 15:38, Andrej Mitrovic wrote:
On 4/3/14, Artur Skawina art.08...@gmail.com wrote:
Actually, they are *much easier* to debug than the recursive templates
-- because you can always look at the generated code, something that
is impossible when using the templates.
Personally I
On Wednesday, 2 April 2014 at 16:53:28 UTC, monnoroch wrote:
I created a D binding to JNI and some convenient wrappers
around it.
Here it is: https://github.com/Monnoroch/DJni
Note, that this is a port from similar C++ lib, so it can be
not the best D code, but it's a start.
I would love if
On 04/03/14 04:40, Walter Bright wrote:
On 4/2/2014 6:21 PM, bearophile wrote:
Then this feature needs a specific and explicit syntax, or it has _no_ point
at
all.
That's like saying inlining has no point because it doesn't have a particular
syntax.
Weak inlining *hints* have no point -
On Thursday, 3 April 2014 at 03:48:08 UTC, Walter Bright wrote:
Alternatively you can use another module for the other
namespace.
Forcing C++ code that exists in a single file to be split up
among multiple D files is inflicting unnecessary punishment on
the poor guy trying to justify
On Wednesday, 2 April 2014 at 11:34:34 UTC, Dicebot wrote:
Awesome stuff there!
I do want to propose one fundamental change though - change
grouping / ordering to be based on potential importance to the
casual end user and not by information origin. For example, I
am pretty sure that merged
On Wednesday, 2 April 2014 at 14:31:49 UTC, Wyatt wrote:
This is a good base. In general, I would suggest not shying
away from subheadings. It gives you more opportunities to
catch the eye and tends to allow readers to see the parts that
interest them more easily. Conversely, making phrases
On Wednesday, 2 April 2014 at 20:53:53 UTC, Joseph Rushton
Wakeling wrote:
Honestly think that you should go with the solution that will
make it easiest to write and share the results. The point of a
newsletter like this is to communicate! You could do much
worse than a Wordpress blog --
On Tuesday, 1 April 2014 at 23:25:07 UTC, Meta wrote:
You can view the rought draft here.
https://docs.google.com/document/d/1Elwm-k6Gs9f7Y-FQNmRVt1uycPEtLkHgpR4v2aQjGwc/edit?usp=sharing
Could you please use canonical links to forum posts?
http://forum.dlang.org/help#canonical
If linking to
On Thursday, 3 April 2014 at 16:34:28 UTC, Vladimir Panteleev
wrote:
On Tuesday, 1 April 2014 at 23:25:07 UTC, Meta wrote:
You can view the rought draft here.
https://docs.google.com/document/d/1Elwm-k6Gs9f7Y-FQNmRVt1uycPEtLkHgpR4v2aQjGwc/edit?usp=sharing
Could you please use canonical links
On Thursday, 3 April 2014 at 16:07:06 UTC, Meta wrote:
The links, especially the Github ones, tend to be quite long,
and I didn't want to take up too much space with them,
especially with the one link per line format.
To clarify, I'm not against descriptive text serving as a link;
my
On 4/2/14, 11:19 PM, monarch_dodra wrote:
If I were to request the actual memchr/wmemchr/dmemchr functions
in some core.??? module, is this something we'd want, and would
somebody know how to provide an efficient implementation?
Yes. Probably checking stuff with SIMD and a few other approaches
On 4/3/2014 4:06 AM, Daniel Kozák wrote:
I think we should distinguish modules lookup from namespaces lookup.
Something like this:
A.B.foo() // call foo function from module/struct/class A and B
#A.#B.foo // call foo function from namespaces A and B
or
A::B.foo // call foo function from
On 4/3/2014 3:36 AM, Michel Fortin wrote:
I'd tend to simply implement extern(C++, namespace.here), which should work fine
to wrap single-namespace cpp files, and wait to see what are the actual friction
points before introducing more (people can experiment with structs or other
modules
03-Apr-2014 10:19, monarch_dodra пишет:
If I were to request the actual memchr/wmemchr/dmemchr functions
in some core.??? module, is this something we'd want, and would
somebody know how to provide an efficient implementation?
Something I wanted in D since about 2011. Should have put an
On Thursday, 3 April 2014 at 19:44:02 UTC, Walter Bright wrote:
On 4/3/2014 4:06 AM, Daniel Kozák wrote:
I think we should distinguish modules lookup from namespaces
lookup.
Something like this:
A.B.foo() // call foo function from module/struct/class A and B
#A.#B.foo // call foo function
On 4/3/14, 4:19 AM, Daniel Murphy wrote:
Walter Bright wrote in message news:lhi1lt$269h$1...@digitalmars.com...
Here's Andrei's proposal:
extern (C++) template nspace() {
int foo();
}
This is really ugly and complicated.
Why not just
pragma(cpp_namespace, outer)
{
03-Apr-2014 05:05, Walter Bright пишет:
On 4/2/2014 3:06 PM, bearophile wrote:
Walter Bright:
I don't see why not. Note that we couldn't do this for extern(C)
functions, or
variadics, or caller functions with parameters that need destruction, or
parameters that may refer to any locals. That
The sfloat24 data type is half way between a float and a double
in storage size. It offers high precison and speed, but is
currently not available as a built-in data type in any compiler
that I am aware of.
Adding an aditional built-in datatype to a compiler would be alot
of work, but for
On 2014-04-03 19:43:23 +, Walter Bright newshou...@digitalmars.com said:
On 4/3/2014 3:36 AM, Michel Fortin wrote:
I'd tend to simply implement extern(C++, namespace.here), which should
work fine
to wrap single-namespace cpp files, and wait to see what are the actual
friction
points
03-Apr-2014 01:51, Walter Bright пишет:
On 4/2/2014 1:54 PM, Dmitry Olshansky wrote:
If we can alter semantics of
return foo(arg);
to _always_ be a goto, guarantee a jump and reuse of the stack, then
I'm all
for it.
I don't see why not. Note that we couldn't do this for extern(C)
functions,
On Thursday, 3 April 2014 at 20:13:35 UTC, Bill Buckels wrote:
The sfloat24 data type is half way between a float and a double
in storage size.
Wait. 24 bits would be halfway between half (16 bits) and single
precision (32 b its).
On Thursday, 3 April 2014 at 11:19:53 UTC, Daniel Murphy wrote:
Walter Bright wrote in message
news:lhi1lt$269h$1...@digitalmars.com...
Here's Andrei's proposal:
extern (C++) template nspace() {
int foo();
}
This is really ugly and complicated.
Why not just
On Thursday, 3 April 2014 at 19:39:57 UTC, Andrei Alexandrescu
wrote:
On 4/2/14, 11:19 PM, monarch_dodra wrote:
If I were to request the actual memchr/wmemchr/dmemchr
functions
in some core.??? module, is this something we'd want, and
would
somebody know how to provide an efficient
On 4/3/14, Bill Buckels bbuck...@mts.net wrote:
D Compiler for .NET -- Compiles the code to Common Intermediate
Language (CIL) bytecode rather than to machine code. The CIL can
then be run via a Common Language Infrastructure (CLR) virtual
machine
This seems out of place? What about D for
On Thu, Apr 03, 2014 at 12:43:59PM -0700, Walter Bright wrote:
On 4/3/2014 4:06 AM, Daniel Kozák wrote:
I think we should distinguish modules lookup from namespaces lookup.
Something like this:
A.B.foo() // call foo function from module/struct/class A and B
#A.#B.foo // call foo function
Interesting development.
http://blogs.msdn.com/b/dotnet/archive/2014/04/02/announcing-net-native-preview.aspx
On Thursday, 3 April 2014 at 20:33:51 UTC, anonymous wrote:
On Thursday, 3 April 2014 at 20:13:35 UTC, Bill Buckels wrote:
The sfloat24 data type is half way between a float and a
double in storage size.
Wait. 24 bits would be halfway between half (16 bits) and single
precision (32 b its).
On Monday, 31 March 2014 at 20:22:57 UTC, Andrej Mitrovic wrote:
On 1/29/14, Ryan Voots simcop2...@simcop2387.info wrote:
I've started a fork of YAGE in an attempt to revive it. So far
I'm still working on porting it to build with dub and D2, but
it's coming along faster than I had expected.
On Wednesday, 2 April 2014 at 22:06:53 UTC, Walter Bright wrote:
Here's Andrei's proposal:
extern (C++) template nspace() {
int foo();
}
It would be accessed in D by:
nspace!().foo();
A possible enhancement would be to allow (for all templates
with no parameters):
On Thursday, 3 April 2014 at 21:06:52 UTC, Andrej Mitrovic wrote:
On 4/3/14, Bill Buckels bbuck...@mts.net wrote:
D Compiler for .NET -- Compiles the code to Common Intermediate
Language (CIL) bytecode rather than to machine code. The CIL
can
then be run via a Common Language Infrastructure
On Thu, 03 Apr 2014 16:13:34 -0400, Bill Buckels bbuck...@mts.net wrote:
The sfloat24 data type is half way between a float and a double in
storage size. It offers high precison and speed, but is currently not
available as a built-in data type in any compiler that I am aware of.
Adding an
Please vote now!
http://www.easypolls.net/poll.html?p=533e10e4e4b0edddf89898c5
See also results from previous years:
- http://d.darktech.org/2012.png
- http://d.darktech.org/2013.png
I'm almost at the point where I've been a D fanatic for half my
programmer years... the time sure flies.
I think I surpassed writing more D code than all other languages
combined last year, taking the prize away from C.
I couldn't remember when I started using D, so I had to go dig in my
personal diary entries until I found it...
In late 2011, I had already heard of D during my search for something
better than C++, but I didn't really start seriously using D until by
chance I came across Andrei's TDPL at a local
Andrei Alexandrescu wrote in message
news:lhkebg$1i1p$1...@digitalmars.com...
extern (C++) template nspace() {
int foo();
}
This is really ugly and complicated.
I don't quite see how one is ugly and complicated and the other is...
pretty and simple? Anyhow de
Ryan Voots wrote in message news:asffkvstgjtktahlp...@forum.dlang.org...
It'd be really nice if someone knew how to get DMD to spew out
EVERY error it finds instead of stopping after the first 100 or
so so that I could go fix things in larger chunks.
In mars.c, find the comment
//moderate
Tnx, chcp 65001 and Lucida font out correct string.
On Tuesday, April 01, 2014 03:54:07 Jonathan M Davis wrote:
On Tuesday, April 01, 2014 05:35:28 ed wrote:
OK, lazy me just read the std.satetime article again. It appears
the design is for no invalid values and it is currently a known
limitation due to CTFE.
---
d_time_nan There is
I have 2 modules:
module A;
public class A {
private static void foo() {}
public static void foo(int) {}
}
module B;
import A;
public class B {
public static void bar() { A.foo(0); }
}
Error: class A.A member foo is not accessible
On Wednesday, 2 April 2014 at 22:07:36 UTC, FreeSlave wrote:
Contents of struct are compared field by field using comparison
for the type of each field. Dynamic arrays are compared by
contents. If you want to compare them by pointer use .ptr
property.
opEquals and opCmp are not about
I often have trouble finding documentation for keywords such as
in and is in D. Also, functions like find I expect to be
in std.string but it's actually in std.algorithm and Tuple I
expect to be in std.typetuple but it's actually in std.typecons.
These make sense in retrospect, but it would
If two dynamic arrays point to the same place in memory, is it
fast to compare them for equality? or does every element still
have to be compared?
1 - 100 of 185 matches
Mail list logo
