Error instantiating std.container.Array
I'm trying to instantiate a std.container.Array of a given class (named Material), by a simple Array!Material _myStuff; I get two compile errors stating the following: C:\D\dmd2\windows\bin\..\..\src\phobos\std\container\array.d(85): Error: template std.algorithm.initializeAll cannot deduce function from argument types !()(Material[]), candidates are: C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(1502): std.algorithm.initializeAll(Range)(Range range) if (isInputRange!Range hasLvalueElements!Range hasAssignableElements!Range) C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(1530): std.algorithm.initializeAll(Range)(Range range) if (is(Range == char[]) || is(Range == wchar[])) C:\D\dmd2\windows\bin\..\..\src\phobos\std\container\array.d(825): Error: template std.algorithm.copy cannot deduce function from argument types !()(Range, Range), candidates are: C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(7808): std.algorithm.copy(Range1, Range2)(Range1 source, Range2 target) if (isInputRange!Range1 isOutputRange!(Range2, ElementType!Range1)) Any idea about what might be happening? I can't give a quick minimal example of the code since it is quite complex (and I failed at using dustmite trying to minimize it)
Re: Error instantiating std.container.Array
On Monday, 2 March 2015 at 14:46:31 UTC, ketmar wrote: On Mon, 02 Mar 2015 14:40:50 +, Francesco Cattoglio wrote: did you tried to dustmite[1] it? [1] https://github.com/CyberShadow/DustMite/wiki I tried to dub dustmite, but it failed with a object.Exception@DustMite\dustmite.d(220): Initial test fails The dustmite version is the one that was bundled with dmd 2.066.1-rc2. I'll update dmd in the mean time, but I have a feeling that this is not related.
Re: Error instantiating std.container.Array
On Monday, 2 March 2015 at 15:01:55 UTC, Tobias Pankrath wrote:
I'm really clueless... :P
Something is wrong with your Material class, but you'll need to
show us a reduced example.
After a really long time I finally found what was wrong.
http://dpaste.dzfl.pl/16d202b7124d
Wow, I honestly could have NEVER foreseen this.
This is all it takes for a class being unusable in a
std.container.Array
class MyClass
{
void init();
}
Re: Cannot instantiate a std.container.Array of a class with a init() function member.
On Monday, 2 March 2015 at 15:57:10 UTC, Tobias Pankrath wrote: Please file a bug report. Will do!
Cannot instantiate a std.container.Array of a class with a init() function member.
Taken from http://forum.dlang.org/thread/gjrbmskictrbcyedu...@forum.dlang.org trying to instantiate an Array!MyClass fails with a rather obscure error message if the MyClass has a member function void init(): http://dpaste.dzfl.pl/16d202b7124d Is this a std library bug, or should this be considered a mistake on the library user side to name a member function init?
Re: accept @pure @nothrow @return attributes
On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis wrote: But It's not like this really improves consistency all that much anyway, because public, protected, package, private, final, override, static, const, immutable, inout, and deprecated all don't have @. So, most function attributes _don't_ have @ on them, and we just added @ to some of them, making things even _less_ consistent. In fact, priore to this, @safe, @trusted, @system, and @property were the _only_ function attributes with @ on them. So, if we really wanted to improve consistency IMHO, we'd get rid of @ from everything that's built-in and leave it for user-defined attributes, but that would break existing code too. - Jonathan M Davis At this point, it might be nicer to have only attributes that exists as C++ keywords not having the @ identifier before them. That is: public, protected, private, override, deprecated, static and const. But this probably doesn't make much sense now, does it?
Re: A naive attempt at a refcounted class proxy
On Tuesday, 13 January 2015 at 18:52:25 UTC, ketmar via Digitalmars-d-learn wrote: On Tue, 13 Jan 2015 18:36:15 + aldanor via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Tuesday, 13 January 2015 at 18:19:42 UTC, ketmar via Digitalmars-d-learn wrote: and then you can go with structures in the first place, i think. remember that you have that k00l `alias this` trick for them! Which doesn't always help in case of multiple inheritance :( e.g. the blasted hdf c++ class hierarchy example. multiple `alias this` may help here... to some extent. ;-) Are they even enabled in dmd already? 2.65 still reports the there can only be one alias this error.
Re: What's missing to make D2 feature complete?
On Saturday, 20 December 2014 at 20:13:31 UTC, weaselcat wrote: On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak wrote: Just wondering what the general sentiment is. For me it's these 3 points. - tuple support (DIP32, maybe without pattern matching) - working import, protection and visibility rules (DIP22, 313, 314) - finishing non-GC memory management Unique! and RefCounted! in a usable state. +1 No RefCounted classes and non-reentrant GC makes it really awkward to write libraries that handle non-memory resources in a nice way. My experience with (old versions of) GFM has been horrible at times: you have to close() everything by yourself, if you forget about that sooner or later the GC will collect something, proc a call to close(), which in turns procs a call to the logger, which will end up with a InvalidMemoryOperationError. Not being able to allocate during ~this() can be extremely annoying for me.
Re: OT: Minecraft death by GC
On Tuesday, 21 October 2014 at 16:08:41 UTC, Israel wrote: On Tuesday, 21 October 2014 at 15:23:11 UTC, David Gileadi wrote: On 10/21/14, 2:47 AM, monarch_dodra wrote: Hurp, I wonder why GC issues only appear with application that use a GC. Hurp-a-durp. Also, the issue of memory leak and core dumps seem to only appear when you use a systems language. How crazy is that? Happily with a little work D allows you to have both! :) Im curious, will D be one of the first languages to have the ability to use a GC and not use one? More likely: to give you the ability to shoot yourself in the foot both with a GC and without it. ;)
Re: [OT] How Blue Byte made Might Magic Heroes Online in Flash
On Sunday, 19 October 2014 at 21:16:14 UTC, Paulo Pinto wrote: Since the topic of games and GC is a big one, maybe it is interesting to read about how Blue Byte decided to make Might Magic Heroes Online in Flash and their opinion from the point of view of a C++ AAA studio on the whole development experience. The only real GC-related thing coming out of this seems to be the usual one: Java GC is fast enough for a MMO backend, probably just because it's Java. The new extra lesson is that anything can work just fine for a Hardware-Accelerated frontend :P
Re: UFCS in C++
On Monday, 13 October 2014 at 08:53:28 UTC, Peter Alexander wrote: Looks like Bjarne has proposed UFCS for C++ http://isocpp.org/files/papers/N4174.pdf No mention of D though... Seriously, not even a mention? Ok, I'm mad. Can I be mad?
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote: Kenji just proposed a slightly controversial pull request so I want to reach out for more people to discuss it's tradeoffs. It's about deprecating function qualifiers on the left hand side of a function. I'm all for it Then at some future point we could apply the left hand side qualifiers to the return type, e.g. `const int foo();` == `const(int) foo();` I know it's not happening anytime soon, but I'm against this second idea. This will be an extra annoyance when porting old D code to a new version. Just removing the currently ambiguous attribute on the left should be plenty. No need to try to mimic C in this regard.
-inline switch changes code behaviour
Today I just realized that in DMD optimize flag does not imply inlining, therefore I promptly added the inline to my dub build settings and recompiler, expecting to see speedups in my code execution. To my surprise, I could not see anything at all: all that I get now is a blank screen. The rendering code uses an old-ish version of gfm-sdl, but I did not find any issue related to compiler swirches. Any idea about what might be happening/any suggestion on how to debug this?
Re: Dutyl - a Vim plugin for running D tools
On Tuesday, 19 August 2014 at 19:03:45 UTC, Idan Arye wrote: Anyways, version 1.0.1 is out with many bugfixes and speedups - including a fix for this problem. I can confirm it works under windows now! Very good job, and thank you for your efforts :)
Re: Dutyl - a Vim plugin for running D tools
On Thursday, 14 August 2014 at 22:20:52 UTC, Idan Arye wrote:
GitHub repo: https://github.com/idanarye/vim-dutyl
vim.org page:
http://www.vim.org/scripts/script.php?script_id=5003
Very very nice... So... how does it work?
I added a Bundle idanarye/vim-dutyl to my $MTVIMRC.
I added the following three lines as well
let g:dutyl_stdImportPaths=['C:\D\dmd2\src\phobos']
call dutyl#register#tool('dcd-client','C:/D/DCD/dcd-client')
call dutyl#register#tool('dcd-server','C:/D/DCD/dcd-server')
When I try to do a completion with ctrl-X ctrl-O I get DCD server
to only output some errors:
Cannot cache modules in
C:\some\folder\for\dub\packages\derelict-blabla\ -I
E:\my\project\subfolder because it does not exist
(The folders are in the filesystem, I can confirm they DO exist)
Am I missing something, or should I open an issue at github?
Re: const int vs. int const
On Saturday, 16 August 2014 at 21:42:59 UTC, Jonathan M Davis wrote: On Saturday, 16 August 2014 at 18:50:08 UTC, Jacob Carlborg wrote: On 2014-08-16 01:33, Mike wrote: Sounds like a worthwhile impromement to me. Sounds like a breaking change to me. Which will include the usual complains. Yes, but it's either that or have people running into this problem and complaining about it and the bugs that it causes for years to come. And it's _already_ bad practice to put const, immutable, inout, or shared on the left-hand side without parens, and pretty much everyone has run into the problem at one time or another when trying to return const from a function and would know to avoid putting those atributes on the left. So, the vast majority of code wouldn't be affected. And of course, we'd do it via deprecation, so it wouldn't immediately break code. For what it is worth, I can confirm this bit me and a coworker of mine. Deprecation of this makes sense. IIRC there's a bunch of C valid code that are rejected by dmd because the semantic is different. This seems to be one of those cases.
Re: C++ template name mangling
On Friday, 15 August 2014 at 19:53:28 UTC, Walter Bright wrote: Currently, D supports: 1. C++ function name mangling 2. C++ namespace name mangling 3. C++ class field and vtbl[] layout 4. C++ function calling conventions But what is missing is name mangling to match C++ templates. This makes it awkward and tedious to construct a D interface to a C++ template. Andrei has proposed that D support, for templates declared within an extern(C++) block, C++ name mangling. This should not be difficult, it should not break any existing D source code, and will enable limited interaction with C++ templates from D. One nice side benefit is that no other language offers such support, and given the increasing ubiquity of C++ template use, it would give us a nice leg up. Do different C++ compilers even mangle template names in the same way? I remember function and classes mangling being almost standard nowadays, does this apply to templates, too? Sure this would add to the Cool things you can do in D; do you have any estimate of the amount of work needed/target release?
Get the default hash function.
Really simple question:
how do I get the compiler-generated hash function for a given
type?
For example:
Struct S
{
int i;
}
can be used in an associative array. That means the compiler
generates a toHash function. Is there any simple way to call it
directly?
Re: Voting: std.logger
On Tuesday, 29 July 2014 at 05:11:33 UTC, Dicebot wrote: 1) Yes / No for inclusion into std.experimental Yes, absolutely. 2) Yes / No for inclusion into Phobos in its current state Not yet. 3) If you have answered No for (2) : list of mandatory changes that are needed to make you vote Yes As far as I undestood, there's no way right now to do logging without using the GC. And that means it is currently impossible to log inside destructor calls. That is a blocker in my book. 4) Any additional comments for author. No matter the changes that might be applied to reduce suffix notation, I would love to retain the ability to do conditional unformatted logging.
Re: Open source Windows debugger
On Sunday, 27 July 2014 at 20:39:53 UTC, Vladimir Panteleev wrote: On Sunday, 27 July 2014 at 19:07:14 UTC, Walter Bright wrote: http://x64dbg.com/#start Anyone want to give this a whirl? It looks like an open-source clone of OllyDbg. Looking at the advertised features, it seems to be aimed at reverse engineering, as I see no mention of source-level debugging, or any supported debug information formats. I'd guess that it would not be great at debugging your own programs. Yep, I have to agree. Or well, probably it's good enough for Walter, but I would be utterly unable to debug even 50 lines of code with that :-P
Re: Review: std.logger
On Friday, 25 July 2014 at 07:11:06 UTC, Jacob Carlborg wrote: On 22/07/14 11:43, ponce wrote: NullLogger is there precisely because it's trivial and needed. If it's so trivial then the users can implement that themselves. A standard library isn't about implementing what's trivial, it's about implementing what's most useful to most people. http://dlang.org/phobos/std_math.html#.fmin fmin is trivial as well, is not used all the time, yet is in the standard library. Sometime trivial stuff is still good to have.
Type deduction on templated constructor.
So, I have this code (also on http://dpaste.dzfl.pl/3f767b17e83c)
This Vector(T) struct is taken from gfm.math.vector.
struct Vector(T) {
T x, y, z;
this(X : T, Y : T, Z : T)(X x_, Y y_, Z z_)
{
x = x_; y = y_; z = z_;
}
}
void main()
{
Vector!ubyte test = Vector!ubyte(1, 1, 1);
}
It fails to compile because template
f508.Vector!ubyte.Vector.__ctor cannot deduce function from
argument types !()(int, int, int).
Note that if one just defines a constructor as this(T x_, T y_, T
z_) everything works.
My question is: should this code compile? I understand that the
literal 1 is int therefore it can screw type deduction, but I
wonder if the compiler should be smart enough to deduce it
correctly.
Re: Type deduction on templated constructor.
On Thursday, 24 July 2014 at 09:38:14 UTC, bearophile wrote: francesco cattoglio: should this code compile? I understand that the literal 1 is int therefore it can screw type deduction, but I wonder if the compiler should be smart enough to deduce it correctly. To keep both the compiler and programmers sane, D templates don't perform implicit type conversions. This sometimes is not handy, but on the whole saves from a large number of troubles. So you can write (D V.2.066): Vector!ubyte(ubyte(1), ubyte(1), ubyte(1)); Or you can create a little helper function that makes that code more DRY. Bye, bearophile I expected such an answer and I do understand the decisions behind it. Yet, you gave me a really GOOD news! Having to write cast(ubyte) 1 was way too much verbose for my liking, while the new ubyte(1) is reasonable enough.
Re: DGui is alive
On Wednesday, 23 July 2014 at 12:58:46 UTC, Gary Willoughby wrote: On Wednesday, 23 July 2014 at 11:40:01 UTC, FrankLike wrote: How about the DGui's status? https://bitbucket.org/dgui/dgui/issues déjà vu
Re: core.exception.InvalidMemoryOperationError
On Friday, 11 July 2014 at 11:43:44 UTC, Joakim wrote: On Thursday, 10 July 2014 at 15:36:53 UTC, francesco cattoglio wrote: A code I'm working on stops working and starts printing an infinite loop of core.exception.InvalidMemoryOperationError to the command line output. The code is quite complex and the bug seems to present itself almost in random situation so I would like to try to understand the issue better before looking for the wrong line of code hiding somewhere. I've read it might be that something is trying to allocate during a destructor call, but it sounds really strange to me that there's a neverending amount of exceptions being thrown. This is the first exception being thrown (nothing is thrown before the infinite loop begins). Anyone has suggestions/ideas/heard of a similar stuff before? If you look at the source for the garbage collector, the only place that error is called is if the gc is trying to malloc or execute other memory operations while the collector is running. I ran across this myself because an assert was getting triggered in a destructor. Since an assert tries to malloc and the destructor is called by the GC, I got an InvalidMemoryOperationError which swallowed up the message from the original assert. By putting printfs in the code path in druntime, I was able to track it down to that destructor, otherwise I had no idea where the invalid memory error was getting triggered. You can probably do the same, but you can be sure it's a GC issue, and I would guess tied to allocating in a destructor (unless you happen to be calling InvalidMemoryOperationErrors somewhere in your own code or some library that you're using, which is unlikely). It's unfortunate that you wrote this only 4 hours ago, because I already spent the morning doing more-or-less the same thing, and finaly realized what was happening and WHO was allocating during a destructor. :o) It's even somewhat told in the docs of core.exception module. What I really don't understand is how the hell was it possible that something managed to either recurse or loop to generate an infinite WOE (Wall Of Exceptions).
core.exception.InvalidMemoryOperationError
A code I'm working on stops working and starts printing an infinite loop of core.exception.InvalidMemoryOperationError to the command line output. The code is quite complex and the bug seems to present itself almost in random situation so I would like to try to understand the issue better before looking for the wrong line of code hiding somewhere. I've read it might be that something is trying to allocate during a destructor call, but it sounds really strange to me that there's a neverending amount of exceptions being thrown. This is the first exception being thrown (nothing is thrown before the infinite loop begins). Anyone has suggestions/ideas/heard of a similar stuff before?
Re: What exactly module in D means?
On Saturday, 5 July 2014 at 17:08:01 UTC, Olivier Pisano wrote:
No, import is different from include. It does not stupidly copy
and paste its content but tells the compiler to take the module
into account for name resolution. The result may seem similar,
but is much more efficient.
In fact, try to write the following C code:
int main() {
#include stdio.h
[whatever else you want]
}
and look at those lovely error messages from the compiler :P
Bug or Feature? compile error: to!string(const Object)
I found out today that the following code won't compile:
import std.conv;
class MyClass {}
void doStuffKo(const MyClass instance)
{
string temp = to!(string)(instance);
}
Everything compiles fine if I remove the const from the function
signature.
I found out this issue named in earlier threads but I could not
find any bug about it on the issue tracker. Is this a bug, a
missing feature, or is this something that is almost impossible
to achieve and therefore not implemented on purpose?
Re: std.math performance (SSE vs. real)
On Sunday, 29 June 2014 at 00:22:02 UTC, Walter Bright wrote: On 6/28/2014 4:27 AM, francesco cattoglio wrote: We are talking about paying a price when you don't need it. More than that - the suggestion has come up here (and comes up repeatedly) to completely remove support for 80 bits. Heck, Microsoft has done so with VC++ and even once attempted to completely remove it from 64 bit Windows (I talked them out of it, you can thank me!). Then I must have missed the post. Removing 80 bit support would sound like madness to my ears. And about that Microsoft thing, thanks a lot :o)
Re: std.math performance (SSE vs. real)
On Saturday, 28 June 2014 at 09:07:17 UTC, John Colvin wrote: On Saturday, 28 June 2014 at 06:16:51 UTC, Walter Bright wrote: On 6/27/2014 10:18 PM, Walter Bright wrote: On 6/27/2014 4:10 AM, John Colvin wrote: *The number of algorithms that are both numerically stable/correct and benefit significantly from 64bit doubles is very small. To be blunt, baloney. I ran into these problems ALL THE TIME when doing professional numerical work. Sorry for being so abrupt. FP is important to me - it's not just about performance, it's also about accuracy. When you need accuracy, 999 times out of 1000 you change the numerical technique, you don't just blindly upgrade the precision. The only real reason one would use 80 bits is when there is an actual need of adding values which differ for more than 16 orders of magnitude. And I've never seen this happen in any numerical paper I've read. I still maintain that the need for the precision of 80bit reals is a niche demand. Its a very important niche, but it doesn't justify having its relatively extreme requirements be the default. Someone writing a matrix inversion has only themselves to blame if they don't know plenty of numerical analysis and look very carefully at the specifications of all operations they are using. Couldn't agree more. 80 bit IS a niche, which is really nice to have, but shouldn't be the standard if we lose on performance. Paying the cost of moving to/from the fpu, missing out on increasingly large SIMD units, these make everyone pay the price. Especially the numerical analysts themselves will pay that price. 64 bit HAS to be as fast as possible, if you want to be competitive when it comes to any kind of numerical work.
Re: std.math performance (SSE vs. real)
On Saturday, 28 June 2014 at 10:42:19 UTC, Walter Bright wrote: On 6/28/2014 2:47 AM, francesco cattoglio wrote: I have experience doing numerical work? Upgrading the precision is the first thing people try. Brute force is always the first thing people try :o) It happens with both numerical integration and inverting matrices. Inverting matrices is commonplace for solving N equations with N unknowns. Errors accumulate very rapidly and easily overwhelm the significance of the answer. And that's exactly the reason you change approach instead of getting greater precision: the adding precision approach scales horribly, at least in my field of study, which is solving numerical PDEs. (BTW: no sane person inverts matrices) Getting the wrong answer quickly is not useful when you're calculating the stress levels in a part. We are talking about paying a price when you don't need it. With the correct approach, solving numerical problems with double precision floats yelds perfectly fine results. And it is, in fact, commonplace. Again, I've not read yet a research paper in which it was clearly stated that 64bit floats were not good enough for solving a whole class of PDE problem. I'm not saying that real is useless, quite the opposite: I love the idea of having an extra tool when the need arises. I think the focus should be about not paying a price for what you don't use
Re: DIP64: Attribute Cleanup
On Saturday, 21 June 2014 at 18:07:25 UTC, Temtaime wrote: And it's C++ that shows that almost all of D attributes are not necessary. How so? Anyway, I totally agree that attributes NEED cleanup, it really makes zero sense to have some without @ annotation. Really, keep Scott's talk in mind! :P About code breakage: a sane deprecation path and an automated tool to make the code up-to-date will make sure there is zero discomfort for D users. The alias for the @attribute set seems a very nice syntax to me.
Re: DIP64: Attribute Cleanup
On Saturday, 21 June 2014 at 20:48:41 UTC, Brian Schott wrote: I think the proposal said that the type constructors would be exempt, You wouldn't have @const but you would have @final. I think you needed to underline this part better. This is indeed extremely important, and that is the reason for people complaining about your DIP being only just moving inconsistencies around
Re: how to correctly 'typedef' handle types
http://dlang.org/phobos/std_typecons.html#Typedef Take a look at it. Docs is scarce (pretty sure you will need to take a look around to find something) but it should just do what you need.
Internal linkage - equivalent of C++ global static and anonymous namespaces
Yesterday I discovered that a global static variable in D is just a global variable, with no special rule about symbol visibility and such. I've scrolled quickly through old discussions on the NG and read the relevant DIP: http://wiki.dlang.org/DIP22 It seems to me that nobody thought about reusing the module keyword for declaring symbols with internal linkage. It would look like: file foo.d: module foo; // module declaration module uint cantSeeMe; // internal linkage attribute, hidden symbol private uint can_See_Me; // private, but symbol still visible AFAIK, module keyword right now is only used for module declaration, and is not valid anywhere else. Would it make sense to use it in this context, too?
Re: Internal linkage - equivalent of C++ global static and anonymous namespaces
On Thursday, 12 June 2014 at 09:48:30 UTC, Kagamin wrote: Why private members can't have internal linkage? There has been some discussion about a few corner cases, see http://forum.dlang.org/thread/jlbsreudrapysiaet...@forum.dlang.org?page=2#post-irrbdrxordjawkryvrub:40forum.dlang.org and following posts.
Re: D Language Version 3
On Friday, 30 May 2014 at 06:14:15 UTC, Jonathan M Davis via Digitalmars-d wrote: Yeah, sorry about that. The web interface that I'm forced to use for e-mail when I'm at work just got changed, and it screwed with my settings - and clearly in a very nasty way. It should be fixed now though. - Jonathan M Davis Perhaps it is fixed, but on the web forum still there's nothing to be seen. What was it about? Something serious or some joke/semiserious stuff?
Differences between const Type function() and const(Type) function()
Today I got the following compile error:
Cannot implicitly convert expression (blabla) of type
const(Type) to Type
and this is a reduced example ( also on
http://dpaste.dzfl.pl/f2f3bd921989):
module test;
import std.stdio;
class Foo {
int i = 42;
}
class MyClass {
private { Foo _Q; }
this() {_Q = new Foo;}
Foo getQ () { return _Q; }
const (Foo) getQ () const { return _Q; } // OK
// const Foo getQ () const { return _Q; } // fails
}
void main() {
const MyClass instance = new MyClass;
writeln(instance.getQ.i);
}
I don't really understand what's going on here. Why is const Foo
getQ() wrong?
And why is const(Foo) getQ so much different? (e.g: this is an
explicit cast, right? Is there anything that might go wrong?)
Re: Differences between const Type function() and const(Type) function()
On Friday, 30 May 2014 at 12:57:52 UTC, anonymous wrote: And why is const(Foo) getQ so much different? (e.g: this is an explicit cast, right? Is there anything that might go wrong?) It's not a cast. It's the unambiguous notation for a qualified type. Often you can omit the parentheses. With methods you cannot. With methods you need the parentheses to let the compiler know that you indeed mean the return type to be const, not the method itself. Ouch... I even wonder why I wrote about is this a cast?... Noob mistake! :P Anyway thank you everyone, I really thought the two way of writing were equivalent. (it's C++ fault, not mine! I tell you!)
Re: Programming a Game in D? :D
On Wednesday, 28 May 2014 at 17:46:23 UTC, David wrote: Ok, now I just wonder wich Engine. (I know everybody hates the discussion about the best engine.) CryEngine, UDK, Unity or a less known Engine? I'll be honest, perhaps I risk being misunderstood, but the questions you are asking denote a lack of even basic knowledge about the subject, so I really think you should do some good amount of research before even trying to write something on your own. Have you tried at least some free tools that allow you to script stuff and have simple stuff displayed on screen? I'm talking about stuff like Construct 2, GameMaker, RPGMaker, zGameEditor... even map editors like the ones from Blizzard (WarCraft 3 : TFT or StarCraft 2)?
Re: Programming a Game in D? :D
On Thursday, 22 May 2014 at 15:48:50 UTC, John Colvin wrote: On Thursday, 22 May 2014 at 15:39:36 UTC, David wrote: Hey, I'm really new to D, and pretty new to programming overall too, But I want to make a 3d Game, (just sth. small). I really like D and want to do it in D, but in the Internet there is no shit about programming a game in D ^^ Is there any engine written in D? For example the CryEngine is for C++, so I would have to write a wrapper? So, how do I write a wrapper? I would need a wrapper for DirectX too right? Are there any wrappers ore Engines for D i can use? btw. I know I dont write that in 1 day ^^ Are there any tutorials or sth. on Programming a Game in D? S I just wanna come as far to have a little Cube where i can run around on with a few phisics :) so just the startup to load a world and so on Thanks in advance :) And sry my english sucks :D There are quite a few game related libs on code.dlang.org that you can take a look at. Also see some of the recent D.announce posts. Yep. Start by learning dub (code.dlang.org), which is a build automation tool that helps you alot by saving headaches caused by the heap of dependencies that a complex software like a game has. Don't start by diving into graphics just yet, spend your first days by doing stuff on the command line. There are a few engines that are being developed by others, but there's nothing like e.g. Unity right now. I think that every engine is in early development stage, too. Also, I think most of current libraries use OpenGL instead of DirectX, so you might want to learn that (at least the basics).
Re: Scalar + array operations
On Wednesday, 21 May 2014 at 13:52:47 UTC, John Colvin wrote: On Wednesday, 21 May 2014 at 11:45:57 UTC, Stefan Frijters wrote: I would have expected the last case to work as well, but I get testarr.d(20): Error: incompatible types for ((dfoo) * (ibar[])): 'double' and 'int[]' Is this by design? It was very surprising to me, especially since all other combinations do seem to work. Kind regards, Stefan Frijters Please file a bug, there's no reason for that not to work, it just needs to be implemented properly. To me, it just feels reasonable that it is not allowed. What should be the correct type of the result? int[]? I thought double to int conversion was not allowed unless you explicitly asked for it.
Re: Templating everything? One module per function/struct/class/etc, grouped by package?
On Monday, 12 May 2014 at 08:37:43 UTC, JR wrote: What am I missing? Error messages! If your code is not compiled, you can't know whether it is valid or not. I must say that since we have unittests, this is somewhat less relevant, but still... One nice thing would be stripping the executable of unneeded code. One trick I've seen done in a program which compiled some scripts to an intermediate language was zeroing the parts which are unused, then use some executable compressor.
Re: More radical ideas about gc and reference counting
On Sunday, 11 May 2014 at 22:06:55 UTC, Francesco Cattoglio wrote: On Sunday, 11 May 2014 at 21:49:06 UTC, ponce wrote: On Sunday, 11 May 2014 at 21:43:06 UTC, sclytrack wrote: There is very little use of @, it's mostly and ~. Heck I didn't find any @ while casually browsing the code. It's like they are not using it at all. Similarly in current C++ std::shared_ptr is barely there while std::unique_ptr is all over the place. I guess that after burning their fingers with auto_ptr, people still have to realize that unique_ptr might be good to use. sorry, my bad, I read it reversed :D
Re: More radical ideas about gc and reference counting
On Sunday, 11 May 2014 at 21:49:06 UTC, ponce wrote: On Sunday, 11 May 2014 at 21:43:06 UTC, sclytrack wrote: There is very little use of @, it's mostly and ~. Heck I didn't find any @ while casually browsing the code. It's like they are not using it at all. Similarly in current C++ std::shared_ptr is barely there while std::unique_ptr is all over the place. I guess that after burning their fingers with auto_ptr, people still have to realize that unique_ptr might be good to use.
Re: More radical ideas about gc and reference counting
On Saturday, 10 May 2014 at 07:08:04 UTC, Andrei Alexandrescu wrote: On 5/9/14, 11:27 PM, Manu via Digitalmars-d wrote: ARC overhead would have no meaningful impact on performance, GC may potentially freeze execution. I am certain I would never notice ARC overhead on a profiler, and if I did, there are very simple methods to shift it elsewhere in the few specific circumstances it emerges. This is very, very, very wrong. -- Andrei I've seen this discussion (it's almost performance-free, it's a performance killer) so many times, I can't even say who has the burden of proof anymore.
Re: More radical ideas about gc and reference counting
On Friday, 9 May 2014 at 21:05:18 UTC, Wyatt wrote: But conversely, Manu, something has been bothering me: aren't you restricted from using most libraries anyway, even in C++? Decent or acceptable performance isn't anywhere near maximum, so shouldn't any library code that allocates in any language be equally suspect? So from that standpoint, isn't any library you use in any language going to _also_ be tuned for performance in the hot path? Maybe I'm barking up the wrong tree, but I don't recall seeing this point addressed. More generally, I feel like we're collectively missing some important context: What are you _doing_ in your 16.6ms timeslice? I know _I'd_ appreciate a real example of what you're dealing with without any hyperbole. What actually _must_ be done in that timeframe? Why must collection run inside that window? What must be collected when it runs in that situation? (Serious questions.) I'll try to guess: if you want something running at 60 Frames per Second, 16.6ms is the time you have to do everything between frames. This means that in that timeframe you have to: -update your game state. -possibly process all network I/O. -prepare the rendering pipeline for the next frame. Updating the game state can imply make computations on lots of stuff: physics, animations, creation and deletion of entities and particles, AI logic... pick your poison. At every frame you will have an handful of objects being destroyed and a few resources that might go forgotten. One frame would probably only need very little objects collected. But given some times the amount of junk can grow out of control easily. Your code will end up stuttering at some point (because of random collections at random times), and this can be really bad.
Re: DIP60: @nogc attribute
On Tuesday, 15 April 2014 at 19:57:59 UTC, monarch_dodra wrote: I have an issue related to adding an extra attribute: Attributes of non-template functions. Currently, you have to mark most functions as already pure, nothrow and @safe. If we are adding another attribute. Code will start looking alike this: int someTrivialFunction(int i) @safe pure nothrow @nogc; don't forget final ;)
Re: dec64 decimal floating point type
On Sunday, 13 April 2014 at 18:42:43 UTC, Alix Pexton wrote: The talk I watched only touched on the motivation for a new format very briefly, but the gist was that the existing offerings were too computationally expensive to emulate in software and hardware support is not forthcoming. My understanding is that this format is designed around what can be done efficiently with the instructions that are available in hardware today. A... This would make sense, at least partially, if hardware supporting the ieee was non-existant, but apparently hardware support for the decimal64 standard is already here! Being a numerical analyst I can say I'm extremely interested when someone comes up with new interesting ideas, but as far as I can tell we still need to go down a long road before finding something better than good old floats. And I really think that one should stick to the standards, as long as the standard is good enough. On a side note, I think that support for decimal64 might be something nice to have in the D language, because apparently that one is the most used floating point type in the economic sectors.
Re: dec64 decimal floating point type
On Saturday, 12 April 2014 at 21:48:15 UTC, Alix Pexton wrote: http://dec64.org/ I recently discovered this while watching a presentation by Doug Crockford on YouTube. I know that Dlang is not in the category of languages that this new numeric representation is aimed at, but Dlang might well be used to implement a VM or compiler for one that is. I think it is ripe for implementation along the same lines as half floats. The reference implementation is on github (linked from the above) and is marked as public domain but porting the assembler (or rather the macros) non-trivial with my skill-set. Anyone else convinced or opposed? Anyone with more assembler-foo willing to lend a hand to the porting effort? A... I don't quite see the point in this, when there is already a standard for floating point decimals http://en.wikipedia.org/wiki/Decimal64_floating-point_format I really should take a deeper look at this, it might be more interesting that I am expecting.
Re: null dereference
On Saturday, 15 March 2014 at 23:23:04 UTC, Jonathan M Davis wrote: I believe that there was some work done to make it so that druntime would detect a segfault and print a stacktrace when that happens, but it's not enabled normally, and I don't know quite what state it's in. That would probably be the ideal solution though, since it gives you the stacktrace without requiring additional checks. - Jonathan M Davis I read some _very_ old threads, and apparently a null dereference raised an exception only on Windows, while on linux it still needed work to be implemented properly. Things probably changed a lot in the mean time, but I think the default behaviour should be throw an exception on every platform. A core dump with zero extra info is bad. I don't care if 95% of times you can fire up a debugger and find out what happened. This is not something that can be always done.
Re: Final by default?
I don't think that the virtual-by-default is the most important aspect of the language, so I can live with it (even if I strongly dislike it). What actually scares me is this: On Saturday, 15 March 2014 at 11:59:41 UTC, Marco Leise wrote: One message that this sends out is that a proposal, even with almost complete lack of opposition, an in-depth discussion, long term benefits and being in line with the language's goals can be turned down right when it is ready to be merged. A decision was taken, being backed by several people, work had begun (yebbiles pulls) and now the proposal gets reverted out of the blue. Somehow makes me wonder how the future of D is decided upon. To me, it really feels like it's made by last-second decisions. I think it can really make a bad impression to newcomers. I neither see a small vocal faction intimidating (wow!) the leadership, nor do I see a dictate of the majority. Agree. But I think that the vocal faction intimidating was just a horrible choice of words, with no harmful intent. Just like the But we nearly lost a major client over it. used at the begin of the thread.
Re: My D book is now officially coming soon
On Monday, 3 March 2014 at 16:37:49 UTC, Adam D. Ruppe wrote: As some of you might know, I've been working on a D book over the last few months. It is now available as coming soon on the publisher's website: http://www.packtpub.com/discover-advantages-of-programming-in-d-cookbook/book I see there's a sample chapters tab, which is empty right now. Can we expect some preview chapter coming out soonish, too?
Re: D, Dub and distributions
On Sunday, 2 March 2014 at 18:55:46 UTC, Russel Winder wrote: Waf is packaged by Fedora but not Debian. On a completely unrelated side note: Waf is NOT supposed to be packaged at all. Being distributed along with the sources is part of the design.
Re: DIP56 Provide pragma to control function inlining
On Monday, 24 February 2014 at 22:09:49 UTC, Jerry wrote: Andrei Alexandrescu seewebsiteforem...@erdani.org writes: On 2/23/14, 8:26 PM, Vladimir Panteleev wrote: Thus, I think there should be try to inline (same as -inline) and always inline (failure stops compilation). Sounds fair enough. pragma(inline, false); pragma(inline, true); pragma(inline, force); // inline or die How is that? Personally I like it. Perhaps you forgot pragma(inline, never); // don't inline or die but I honestly have no idea if this would actually be useful. Anyway, I'm really fine if there will be no way to force inline. But if we can't guarantee that inlining actually happens, please change the pragma name.
Re: Practical Problems with distribution D projects
On Tuesday, 25 February 2014 at 14:51:48 UTC, Assaf Gordon wrote: Also, as long as DMD is not free, providing easy way to install LDC/GDC is highly desired. On my Ubuntu laptop (standard repos as far as I remember) I have to apt-get install gdc to install it. I don't understand what you meant with easy way to install. Are you talking about getting it from sources or what?
Re: Practical Problems with distribution D projects
On Tuesday, 25 February 2014 at 15:18:06 UTC, Dicebot wrote: On Tuesday, 25 February 2014 at 15:12:08 UTC, Francesco Cattoglio wrote: On my Ubuntu laptop (standard repos as far as I remember) I have to apt-get install gdc to install it. I don't understand what you meant with easy way to install. Are you talking about getting it from sources or what? It is a rather old gdc, I can't recommend to use it ;) since gdc --version output is 4.8.1, what version would it be? like 2.060 or more like 2.052?
Re: Practical Problems with distribution D projects
On Tuesday, 25 February 2014 at 15:31:19 UTC, Dicebot wrote: On Tuesday, 25 February 2014 at 15:24:19 UTC, Francesco Cattoglio wrote: since gdc --version output is 4.8.1, what version would it be? like 2.060 or more like 2.052? Hm, ones I see in package list are for 4.6 - are you using some sort of testing repo? 4.8.* can possibly be pretty new, you can check fronend version by compiling test program with pragma(msg, __VERSION__) 2062L! 2.062 is decently recent I'd say ;) Perhaps is from some launchpad repo, but nothing too much trascendental. Anyway, my point was that GDC and LDC are easily available under most used distros, given a bit of patience. I mean, we can probably package them faster than the distribution updates them (I'm referring to Ubuntu 6-months cycle in particular)
Re: D alternative for C/C++ -Dfoo=42
On Tuesday, 25 February 2014 at 14:26:13 UTC, Tobias Pankrath
wrote:
Something like static if(fileExists!config.d)
mixin(import(config.d)) else
Thoughts?
Regards
- Cherry
--
static if(__traits(compiles, import(config.d)))
{
// import/parse/mixin
}
else
{
// default here
}
--
May be wrapped into a template for more convenience.
I thought that too... And then, when I tried, SURPRISE, it
doesn't work :S
Re: D alternative for C/C++ -Dfoo=42
On Tuesday, 25 February 2014 at 14:30:23 UTC, Francesco Cattoglio
wrote:
On Tuesday, 25 February 2014 at 14:26:13 UTC, Tobias Pankrath
wrote:
Something like static if(fileExists!config.d)
mixin(import(config.d)) else
Thoughts?
Regards
- Cherry
--
static if(__traits(compiles, import(config.d)))
{
// import/parse/mixin
}
else
{
// default here
}
--
May be wrapped into a template for more convenience.
I thought that too... And then, when I tried, SURPRISE, it
doesn't work :S
Ok, MY BAD! It works, but I gave him a folder instead of a file.
When you give it a folder instead of a file, it still works but
also outputs an error:
read error, errno = 21
However the else branch is still taken. Well, this went better
than expected!
Re: dmd 2.065.0
On Monday, 24 February 2014 at 10:33:27 UTC, Szymon Gatner wrote: All Systems: http://ftp.digitalmars.com/dmd.2.065.0.zip FreeBSD: http://ftp.digitalmars.com/dmd.2.065.0.freebsd-64.zip http://ftp.digitalmars.com/dmd.2.065.0.freebsd-32.zip Linux: http://ftp.digitalmars.com/dmd_2.065.0-0_i386.deb http://ftp.digitalmars.com/dmd_2.065.0-0_amd64.deb http://ftp.digitalmars.com/dmd-2.065.0-0.fedora.i386.rpm http://ftp.digitalmars.com/dmd-2.065.0-0.fedora.x86_64.rpm http://ftp.digitalmars.com/dmd-2.065.0-0.openSUSE.i386.rpm http://ftp.digitalmars.com/dmd-2.065.0-0.openSUSE.x86_64.rpm http://ftp.digitalmars.com/dmd.2.065.0.linux.zip MAC OS X: http://ftp.digitalmars.com/dmd.2.065.0.dmg http://ftp.digitalmars.com/dmd.2.065.0.osx.zip Windows: http://ftp.digitalmars.com/dmd-2.065.0.exe http://ftp.digitalmars.com/dmd.2.065.0.windows.zip [1] http://dlang.org/chagelog.html [2] http://dlang.org/download.html Regards, Andrew [1] gives: Not Found The requested URL /chagelog.html was not found on this server. Indeed, it's a mispelling, and the changelog.html is not yet updated. However, you can download the zip and find the correct, updated changelog from the [zipfile.zip]/html/d/ folder Very nice work! 280+ issues closed for DMD, 80+ issues closed for phobos. Thank you to all the contributors!
Re: dmd 2.065.0
On Monday, 24 February 2014 at 11:45:20 UTC, Namespace wrote: Not really. This pull introduce the virtual keyword. The next step will afaik force you to write on every method if it is virtual or final. The step afterwards will probably introduce final by default. Wait, does this mean we finally came to some kind of agreement on the whole debate? I was sure that any kind of change of current behaviour was being vetoed
Re: Strategy for Traction
On Monday, 24 February 2014 at 06:36:33 UTC, Russel Winder wrote: I suspect D has no user group activity because it is a 10 year old language very few people have heard about. It needs a marketing reboot Let's make 2 or 3 breaking changes, call it D 3.0, and start spamming it around!:P
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 13:07:27 UTC, Dmitry Olshansky wrote: It's going to be near useless if it doesn't make sure inlining happened. I completely agree.
Re: Porting my Integer Sorting Algorithms to D
On Sunday, 23 February 2014 at 19:17:29 UTC, Nordlöw wrote: I guess this component would be integrated into std.algorithm when its ready, right? If you are happy with it being in there, if the algorithm has a nice behaviour, and it passes the existing test suite, I don't see why it would not!
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 20:40:44 UTC, Walter Bright wrote: Generally, when I optimize at that level, I have a window open on the assembler output of the compiler and I go back and forth on the source code until I get the shape of the assembler I need. Having compiler messages wouldn't be very helpful. Not everyone has time/knowledge for checking the ASM at every recompile. Personally I wouldn't be able to do something like this that much often, and yet I'd love to know that something is not working ASAP. Code changes, and it changes a lot during development. Having a way to make sure that one or more functions stay inlined is handy to have. If such a pragma doesn't guarantee inlining, that means we will have no way to check it quickly. Sometimes fail fast is really the best choice.
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 21:55:11 UTC, Walter Bright wrote: On 2/23/2014 1:32 PM, Francesco Cattoglio wrote: [...] I addressed these three messages in another reply to Dmitry. Read that, and you do make a point. I am no expert on optimization, but as far as I could tell, inlining is usually the easiest and most rewarding of the optimizations one can do. I know you kind of hate warnings, but perhaps we could at least get a warning if something cannot be inlined?
Re: DIP56 Provide pragma to control function inlining
On Monday, 24 February 2014 at 02:05:31 UTC, Walter Bright wrote: 1. It provides information to the compiler about runtime frequency that it cannot obtain otherwise. This is very useful information for generating better code. This answers to your own previous question: this is what makes inline a special optimization. 3. In the end, the compiler should make the decision. Inlining does not always result in faster code, as I pointed out in another post. Honestrly, in the small profiling I've done in my life, at least inlining never made my code slower. But I do realize this is not relevant to the discussion. Perhaps the lesson is the word 'inline' carries certain expectations with it, and the feature would be better positioned as something like: pragma(usage, often); pragma(usage, rare); Yes, I think inline carries huge expectations: the expectation for the compiler to comply. If the plan is hinting frequency information, then usage makes way more sense. It might be used in if blocks and in switch cases too, when branch prediction might be sloppy or unoptimal.
Re: hiding a class property behind a method
On Saturday, 22 February 2014 at 17:21:50 UTC, luka8088 wrote: It seems to me that the following code should be illegal, but I am uncertain of it so I am posting here for a confirmation before I post it on bug tracker: [snip] Nice find. I guess we could add this to the list of ugly code caused by calling functions without parenthesis. If parenthesis were not optional, I don't think that the code would behave in such a horrible way, right?
Re: hiding a class property behind a method
On Saturday, 22 February 2014 at 22:42:24 UTC, simendsjo wrote: The problem isn't about optional parenthesis or properties. It's the fact that you can redefine a symbol to be something entierly different, and that this difference will only be seen if you are looking at the symbol through the correct type. You are right. I thought that if we had forced parenthesis, the compiler would at least be able to understand what symbol you were referring to, but this is actually not the case.
Re: Correct comparison of signed type with unsigned type (and vice versa)
On Thursday, 20 February 2014 at 20:52:23 UTC, Xinok wrote: Others have suggested disallowing comparing a signed type with an unsigned type. I think this is a better solution. Yes, it will add a small bit of overhead, but I believe it's more important for code to be correct than to be fast. I totally agree. However, since we need correct code, we need way more features than this. I was surprised to find out that we don't have any SafeInt type in D... I was sure someone had made it but I wasn't able to find it anywhere. My ideal int type: -Has an equivalent of NaN, meaning it doesn't have 0 initialization which is somewhat bug-prone. -Is able to signal errors like overflow/division by zero, would be nice if throwing could be avoided. -Signed, but can be flagged as 0 only, and signals an error if it gets assigned a negative value. -Some extra features that are surely awesome but I'm forgetting right now. Any takers? Man, I wish I had time :S
Re: Ada conference, Ada and Spark
On Friday, 21 February 2014 at 12:56:32 UTC, Paulo Pinto wrote: That is easy to answer, I doubt they could with their rule of not having more than 5 characters per keyword. :) Wait, what? REALLY? What kind of rule is that. ahahahha... are they stuck to the 70's? :D
Re: Ada conference, Ada and Spark
On Friday, 21 February 2014 at 15:57:32 UTC, Thiez wrote: That is not true, Rust has several keywords that are more than 5 characters, such as 'continue'. The full list is here: http://static.rust-lang.org/doc/master/rust.html#keywords . It is true that they prefer short keywords over long ones. I knew there was no hard-coded limit, but this try to keep keywords short sounds really stupid to me. No offence to designers, but I really don't think we should save some spar characters in 2014... I do all my coding on a remote SSH, but still I have plenty of screen space to spare ;) My first glance: priv instead of private... bleah! At least it's clear enough mut... what is this? mutable, mutex, perhaps mute? impl could be several different things, too, but I guess it's implements And continue being a different keyword some time ago. In the end they changed it. Tons of discussions and stuff; was it worth saving 3 characters, after all? I hope their standard library is at least WAY more verbose... Otherwise I pity casual Rust programmers :D
Re: More Illuminating Introductory Code Example on dlang.org
On Wednesday, 12 February 2014 at 20:49:54 UTC, Nordlöw wrote: What do you think, fellow D programmers? What are the odds of getting a color-enabled terminal output? We could try to produce some simple ascii art :D
Re: Implement the unum representation in D ?
On Friday, 21 February 2014 at 19:12:39 UTC, Frustrated wrote: Simply not true. Maple, for example, uses constants and can compute using constants. You are mixing symbolic calculus and numerical computations. The two are completely unrelated. Basically the benefit of this(and potential) outweigh the cost of 1 bit out of 64-bits. Unless I'm completely mistaken, what you are proposing is basically creating a tagged union type. It's pretty much unrelated from the unum proposed by the PDF.
Re: Facebook puts bounties on bugs in the D programming language implementation
On Thursday, 20 February 2014 at 20:25:11 UTC, Baz wrote: Ahahahahaahhahahahahahaha$80... They just put 19 000 000 000 $ for a web app. Are you kiddin us ? Ok, I must say I'm shocked, and yes this 19 Billion $ spent make look bounties on D project some kind of joke. However JERK.MASSIVE DOUCHE.FUCK. what the hell has Andrei to do with this lol. You'd better grow a pair and send an email to Zuckerberg, my boy.
Re: Implement the unum representation in D ?
On Thursday, 20 February 2014 at 10:10:13 UTC, Nick B wrote: The abstract is here: http://openparallel.com/multicore-world-2014/speakers/john-gustafson/ The pursuit of exascale floating point is ridiculous, since we do not need to be making 10^18 sloppy rounding errors per second; we need instead to get provable, valid results for the first time, by turning the speed of parallel computers into higher quality answers instead of more junk per second Ok, I think I know a bunch of people who could question the contents of that sentence. Or, at the very least, question this guy's way of presenting sensational news.
Re: Implement the unum representation in D ?
On Thursday, 20 February 2014 at 23:21:26 UTC, Nordlöw wrote: We might not need random access though. For basic linear algebra forward or bidirectional should be enough which should suit this format. Depends on the application. Basic Linear Algebra often requires sparse matrices. Sparse Matrices = both random access and indirection.
Re: Implement the unum representation in D ?
On Thursday, 20 February 2014 at 23:52:13 UTC, Chris Williams wrote: I don't quite understand his ubox stuff, but his unum format doesn't really solve the 0.1 problem, except maybe by allowing the size of his values to exceed 64-bits so that precision errors creap up a little bit slower. (I'm not sure how many bits his format tops out at and I don't want to re-open the PDF again to look). Exctly. If I read correctly it should cover 128+ bits. It also wasn't clear whether his format removed the multiple values of NaN, -0, etc. It looked like it was just the current IEEE formats bonded to a sliding bit-length Pretty sure it would not. It seems to me that space wasted by multiple representations is still there. The only real advantage is that you can probably store a NaN in 8 bits. Honestly, who cares. If I get a NaN in my numerical simulation, I have bigger concerns other than saving memory space. I think the only way to solve for problems like 0.1 in decimal not mapping to any reasonable value in binary is to store numbers as integer equations (i.e. 0.1 = 1/10), which would take a hell of a complex format to represent and some pretty fancy CPUs. In fact, true rational numbers can only be represented by rational numbers. How extraordinary! :P The whole idea has one merit: the float now stores it's own accuracy. But I think you can achieve more or less the same goal by storing a pair of something. The whole idea of saving space sounds bogus, at least for my field of application. We already have an amazing technique for saving a lot of space for numerical simulation of PDEs, it's called grid refinement.
Re: Implement the unum representation in D ?
On Friday, 21 February 2014 at 05:21:53 UTC, Frustrated wrote: I think though adding a repeating bit would make it even more accurate so that repeating decimals within the bounds of maximum bits used could be represented perfectly. e.g., 1/3 = 0.... could be represented perfectly with such a bit and sliding fp type. With proper cpu support one could have 0.... * 3 = 1 exactly. By having two extra bits one could represent constants to any degree of accuracy. e.g., the last bit says the value represents the ith constant in some list. This would allow very common irrational constants to be used: e, pi, sqrt(2), etc... Unfortunately maths (real world maths) isn't made by common constants. More, such a repeating bit should become a repeating counter, since you usually get a certain number of repeating digits, not just a single one. For floating points, the 3rd last bit could represent a repeating decimal or they could be used in the constants for common repeating decimals. (since chances are, repeated calculations would not produce repeating decimals) Things like those are cool and might have their application (I'm thinking mostly at message passing via TCP/IP), but have no real use in scientific computation. If you want good precision, you might as well be better off with bignum numbers.
Re: foreach/iota countdown
On Monday, 17 February 2014 at 20:21:30 UTC, simendsjo wrote: I wouldn't call it randomly. In that case you should call it randomly that it suddenly doesn't run once you try to step downward. I didn't had time to work more on the iota. Perhaps after 2.065 is out I can resume working on that, but I'm really short of time right now. Allowing iota to iterate downward might become a horrible idea when we finally extend iota to other non-numeric types. The big issue is that types that define both opUnary!++ and opUnary!-- would behave in a completely different way from types that only define opUnary!++. from http://forum.dlang.org/thread/mwwznnobgecnwermr...@forum.dlang.org example: type T implements ++t and --t; type P only implements ++p; t1 t2 = iota(t2, t1) has a way to compute a non-empty range; p1 p2 = iota(p2, p1) can do nothing but return an empty range; This really looks like a minefield to me.
Re: Optimize my code =)
On Sunday, 16 February 2014 at 01:25:13 UTC, bearophile wrote: Many of the things you say and write are still wrong or confused. Usually the hard optimization of code is one the last things you learn about a language Well, actually, sometimes squeezing as much performance as you can from a test case can be a way to find out if a given language checks all the boxes and can be used to solve your problems. I must admit I'm shocked by the poor performance of D here. But I also know one HAS to try LDC or GDC, or those numbers are really meaningless.
Re: Optimize my code =)
On Sunday, 16 February 2014 at 09:53:08 UTC, bearophile wrote: Be instead amazed of the sometimes near-C++ performance levels they have pushed Java to :-) Sorry, but I fail to be amazed by what huge piles of money thrown to a project for 10+ years can achieve. Those kind of achievements are boring :P And I think D is doing well in a benchmark like this, I guess with ldc2 you can go about as fast as C++. I'm sure that other small benchmarks on computational-intensive code achieved C++ speed in the past, so if we can't get C++-like speed here, it's either a problem with the code or some serious performance regression.
Re: std.serialization
On Thursday, 13 February 2014 at 22:56:38 UTC, Orvid King wrote: so I'm releasing it as std.serialization. What does that even mean? I'm pretty sure you should NEVER call a library std.something if it hasn't been approved for inclusion into standard library. Other than that, nice work.
Re: Bounty for -minimal compiler flag
On Friday, 14 February 2014 at 11:28:30 UTC, 1100110 wrote: I thought that would be best, unfortunately. Bitcoins are nice, but bountysource is the way to go. It's both more official and easier to contribute to the bounty. I'd be fine with the switch being name -nodruntime, and honestly I like that better. I like it too. I will as soon as I iron a few wrinkles. I need to figure out if typeinfo should be a part of this as well. Work on the details, take your time, no hurry. I'm in for chipping around 50$ too.
Re: Why are there Properties in D?
On Friday, 14 February 2014 at 09:32:40 UTC, Robin wrote: more important is clean and unambiguous code. With Properties used in a code a programmer again has to look up the definition of all calls and assignments of variables just in case they could be Properties and not just member variables. Trusting the programmer that wrote code before you is something you will have to do anyway. Property however have been introduced in an incomplete way and are discussed once or twice a year in huge threads. Anyway, typical usage cases are pretty much the same described by C# properties: from http://msdn.microsoft.com: -Properties enable a class to expose a public way of getting and setting values, while hiding implementation or verification code.
Re: Thought on limiting scope of GC
On Friday, 14 February 2014 at 11:28:11 UTC, Jerry wrote: Track says keep track of objects allocated after the track call, and cleanup only looks at those objects that were recently allocated, ignoring the rest of the heap. Track cannot make sure that no reference escapes, therefore cleaning up an object could be a huge error. This would however make sense e.g. inside pure functions.
Re: Close D1 bugs?
On Wednesday, 12 February 2014 at 08:57:21 UTC, Walter Bright wrote: On 2/11/2014 11:29 AM, Steven Schveighoffer wrote: Thoughts? I closed the aforementioned bug as WONTFIX. Anyone is free to correct that if you feel it's in error :) D1 is still in use. Just ignore D1 only bugs if you don't use D1. But to close them does a disservice to the existing D1 users. Just deleting them would be a horrible disservice. Marking as WONTFIX sounds reasonable to me. After all, since support got dropped, won't be fixed sounds realistic. Also, the current open issues list is HUGE, cutting it down by discarding outdated stuff would be nice. Or at least, would *look* nice. Honestly, the first time I took a look at D I was like wait, is this a programming language or a testbed for some strange compiler? :P
Re: Idea #1 on integrating RC with GC
On Wednesday, 12 February 2014 at 02:21:38 UTC, deadalnix wrote: On Wednesday, 12 February 2014 at 01:54:15 UTC, Andrei Alexandrescu wrote: Yes. I think that's a disaster. We need to figure out the right approach to solving that. For a while, we were doing the review sunday. That was fun, everybody was talking about the pull in IRC and we were going from one to the other. Maybe it is time to start this tradition again ? Sounds like a really nice idea! I would come in and listen silently for sure! At least untill I'm knowledgeable enough :P
Re: Phobos for Review: std.buffer.scopebuffer
On Monday, 10 February 2014 at 19:31:50 UTC, Walter Bright wrote: I cannot agree with following rules to the point of throwing common sense out the window. If following the rules requires throwing common sense out of the window, perhaps it's time to change the rules.
Re: One more question - an untapped audience.
On Monday, 10 February 2014 at 19:03:22 UTC, Tofu Ninja wrote: tldr; Tools suck, documentation sucks, std lib is small and no std GUI lib... I do agree to a certain degree. std lib is not really that small, but sure it is never enough. Lack of std GUI lib, I honestly I'm perfectly fine with it. Tools on the other hand, do suck. The only way I could debug my prototype code involving std.concurrency and some OpenGL code was learning to use GDB from the command line, because GUI debuggers would fail horribly. Editors are so-so, compiler-as-a-library needs some extra time before work on it starts. Documentation is just not good enough. Perhaps I can start doing some pulls for the docs, since I'm still a n00b of the language but at least not a complete beginner anymore. Thanks God we have at least DUB. BTW: we really need to get a BIG link to dub package registry in the home page, or at least on the side bar.
Re: Idea #1 on integrating RC with GC
On Monday, 10 February 2014 at 21:57:42 UTC, Paulo Pinto wrote: A bit off topic, but can you still get new single core chips? Yes you can! http://en.wikipedia.org/wiki/Intel_Edison will be made available in 2014, single core. And since it will have very limited resources, C# and Java are probably off limits. I must say D would be a perfect language for it! :D
Re: Lists Allowing for Switching Values
On Monday, 10 February 2014 at 19:35:55 UTC, Jeroen Bollen wrote: Is there a way in D to have a list that allows you to shift around values? I'm creating a cache and I would like to keep a log of when an item was last accessed so when the cache shrinks or is about to overflow I can delete the items that haven't been accessed in a while. I would like to be able to push to the back and pop from the front. Do note that I would like to pop from the front, and not from the back, as I want the oldest items to be popped out. I would like the be able to search if the item is actually in the list. If no such functionality exists yet I could alternatively implement it myself; it's not crucial. I would like to be able to switch items around. This allows me when an item already in the list is accessed, I can put it back at the back, where the most recent items reside. Does such a feature exist already in D, is there perhaps a better approach about doing this? It all depends on the access times you need. If you are fine with O(n) or O(log n), then something from std.container with a few extra helper functions will do just fine. O(1) on the other hand, might require 2 associative arrays you will have to keep it sync. Nothing impossible anyway.
Re: Idea #1 on integrating RC with GC
On Tuesday, 11 February 2014 at 00:25:35 UTC, Ola Fosheim Grøstad wrote: There you go ad hominem again. You really need to avoid this ad hominem stuff… You see, as a hardcore roleplayer I could be tempted to switch over into a sarcastic mode. And that would not be fair to you. ;-) Ok, I'm a bit fed up by your attitude so I'll express a personal opinion now: it seems to me that when people express any kind of judgment, it's ad hominem against you. When you express judgment, is not ad hominem, it's the fruit of some kind of analysis you made. You know that ad hominem doesn't mean I disagree with you, right?
Re: Idea #1 on integrating RC with GC
On Tuesday, 11 February 2014 at 12:47:01 UTC, Ola Fosheim Grøstad wrote: Making an analysis of project as an artifact is not ad hominem Expressing an opinion on your knowledge of a subject is not ad hominem either. A few posts ago, Manu wrote I don't think you have made a game = I don't think you have the same amound of knowledge of the game industry. That is not ad hominem. You think that Andrei telling you to do something is ad hominem. Again, it's not. He is just stating that sometimes talking is not enough. If you really care about knowing how many people are interested in getting a runtime D, open a voting pool somewhere on the internet, link it in a proper thread in the announce section, and try to see what results you get, try to interpret them and so on. If you believe the people here can achieve something great, you should try to help coordinating the community. It's true that we lack organization basics. Are you knowledgeable about the subject? Are you interested in helping the community? If your answer is yes to bot questions, than you should really do something, and I talking about non-coding stuff. Being a top contributor is not a requirement for helping in a tangible way. I the case of D, it is not clear. It is not clear if there is enough momentum in the D community to sustain a real-time D either. It's a community effort. AA and WB are not leaders in the strict sense. As I already told you, if you want to contribute by helping coordinating efforts, I think all of us would be really happy about that.
Re: Idea #1 on integrating RC with GC
On Tuesday, 11 February 2014 at 18:12:41 UTC, Brad Anderson wrote: On Tuesday, 11 February 2014 at 17:37:36 UTC, Andrei Alexandrescu wrote: Yah, the whole Trello experiment has been on my tongue during this discussion. It's been made public long before its demise. Andrei I think it got off to a bad start because it was private and even after it was public it wasn't talked about much within the community (it was hard to even find because it wouldn't turn up in Trello's search). I use and enjoy Trello at work so personally I think I'd try to get everyone to give it another shot if it were up to me. I've been here on and off for lots of time, and it is the first time I hear about Trello at all :D
Re: D as A Better C?
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote: The idea is to be able to use a subset of D that does not require any of druntime or phobos - it can be linked merely with the C standard library. What do you think? I don't do embedded, so my opinion is just an opinion. I don't see any big issue with having some extra work. Do you think it would be easier to create this after having switched to DDMD?
Re: D as A Better C?
On Tuesday, 11 February 2014 at 21:53:42 UTC, Steven Schveighoffer wrote: On Tue, 11 Feb 2014 16:11:19 -0500, Walter Bright newshou...@digitalmars.com wrote: On 2/11/2014 11:43 AM, Walter Bright wrote: (First off, I hate the name better C, any suggestions?) How about EmbeddedD, though that wouldn't be entirely accurate? Sorry, WAAAY too many D's :) -Steve If you hate too many Ds, then the best name is by far D flat: D♭
Re: Idea #1 on integrating RC with GC
On Monday, 10 February 2014 at 04:26:10 UTC, Manu wrote: Sorry, I obviously mean, the only *games* company... That was a given. However I think AAA titles have the manpower to avoid those pauses, since the amount of work toward optimization is huge anyway, am I right? Ofc you still need minimal backend from the compiler and runtime support. If you lack control on internals, there's no way for you to optimize anything. And people seem to forget promptly after every single time I repeat myself: * The GC frequency of execution is directly proportional to the amount of _free memory_. In console games; NONE. * The length of the associated pause is directly proportional to the amount of memory currently in use. In console games; all of it. For simple games, it would be nice to have a better GC and cut down allocations from the standard library. I guess that would suffice, no need to move to ARC.
Re: Idea #1 on integrating RC with GC
On Monday, 10 February 2014 at 08:58:29 UTC, Manu wrote: If we wanted to spend that time+manpower (read, money overtime/sanity) on bullshit like that, we have no reason to adopt D; we already have C/C++, and we already have decades of experience mitigating that nightmare. The point is, we are REALLY sick of it. Why would we sign up to replace it with more of the same thing. What I meant: you can't get a language that performs at its best without doing your homework. Ideal performance requires time and money, no matter the tools. This doesn't mean I expect you to do the same amount of work you have to do in C++. Perhaps I expressed myself in a bad way, so here is a second try at that: I expect only simpler games to run at ideal speed without efforts. Simple here doesn't mean generic 2D platformer, it should be interpreted as not cutting edge. If you really need to squeeze every bit of performance, you can't only rely on automation.
