Re: D2 port of Sociomantic CDGC available for early experiments
Am 11.10.2014 um 06:43 schrieb dennis luehring: Am 11.10.2014 06:25, schrieb Andrei Alexandrescu: On 10/10/14, 7:54 PM, Walter Bright wrote: On 10/10/2014 5:45 PM, Leandro Lucarella wrote: I still don't understand why wouldn't we use environment variables for what they've been created for, it's foolish :-) Because using environment variables to tune program X will also affect programs A-Z. Nope. Try this at your Unix command prompt: echo $CRAP CRAP=hello echo $CRAP CRAP=world echo $CRAP in windows there are user-environment-variables (walter talking about) and shell-environment variables (like in your example) setting user-environement variables will affect every program thats why java is not using them And lets not forget about OS/400 or any of the other non-POSIX systems out there, unless D is never expected to target such OSs. -- Paulo
Interview with Andrei Alexandrescu on the D Programming Language
https://www.youtube.com/watch?v=tvdoIJaPooI On reddit: https://www.reddit.com/r/programming/comments/2iws85/interview_with_andrei_alexandrescu_on_the_d/
Re: Interview with Andrei Alexandrescu on the D Programming Language
On Saturday, 11 October 2014 at 09:21:21 UTC, Walter Bright wrote: https://www.youtube.com/watch?v=tvdoIJaPooI On reddit: https://www.reddit.com/r/programming/comments/2iws85/interview_with_andrei_alexandrescu_on_the_d/ Andrei mentions in this talk, that C++ support is implemented to the extent, when you can pass std::vector from C++ to D and in the opposite direction without friction. Are the any pointers on how I can try it out? Like, is it in git master? Where can I find a documentation or an article about that? The corresponding section on the site (http://dlang.org/cpp_interface.html) says: D templates have little in common with C++ templates, and it is very unlikely that any sort of reasonable method could be found to express C++ templates in a link-compatible way with D. This means that the C++ STL, and C++ Boost, likely will never be accessible from D. And I assume this is no longer true. So, anywhere I can look for it?
Re: Interview with Andrei Alexandrescu on the D Programming Language
On Saturday, 11 October 2014 at 11:31:12 UTC, Sergei Nosov wrote: On Saturday, 11 October 2014 at 09:21:21 UTC, Walter Bright wrote: https://www.youtube.com/watch?v=tvdoIJaPooI On reddit: https://www.reddit.com/r/programming/comments/2iws85/interview_with_andrei_alexandrescu_on_the_d/ Andrei mentions in this talk, that C++ support is implemented to the extent, when you can pass std::vector from C++ to D and in the opposite direction without friction. Are the any pointers on how I can try it out? Like, is it in git master? Where can I find a documentation or an article about that? I got interested in the very same part.
Re: Interview with Andrei Alexandrescu on the D Programming Language
On Saturday, 11 October 2014 at 13:07:42 UTC, Szymon Gatner wrote: On Saturday, 11 October 2014 at 11:31:12 UTC, Sergei Nosov wrote: On Saturday, 11 October 2014 at 09:21:21 UTC, Walter Bright wrote: https://www.youtube.com/watch?v=tvdoIJaPooI On reddit: https://www.reddit.com/r/programming/comments/2iws85/interview_with_andrei_alexandrescu_on_the_d/ Andrei mentions in this talk, that C++ support is implemented to the extent, when you can pass std::vector from C++ to D and in the opposite direction without friction. Are the any pointers on how I can try it out? Like, is it in git master? Where can I find a documentation or an article about that? I got interested in the very same part. Take a look here [1] and here [2] You must use the current git master (Digger [3] can help you with an easy build of it). Note that some template mangling are still broken, and there are problems with the pass-by-ref, but, well, somehow it works! https://github.com/D-Programming-Language/dmd/blob/master/test/runnable/cppa.d https://github.com/D-Programming-Language/dmd/blob/master/test/runnable/extra-files/cppb.cpp https://github.com/CyberShadow/Digger --- /Paolo
Re: D2 port of Sociomantic CDGC available for early experiments
On 10/11/2014 3:59 PM, Leandro Lucarella wrote: You can use different mechanisms in different OSs. There is no need to force a runtime to be OS-independent. If that were the case, then we should close the concurrent GC pull request now. I still don't see why it can't use a special argument to the C main() function.
Re: D2 port of Sociomantic CDGC available for early experiments
Andrei Alexandrescu, el 10 de October a las 21:25 me escribiste: On 10/10/14, 7:54 PM, Walter Bright wrote: On 10/10/2014 5:45 PM, Leandro Lucarella wrote: I still don't understand why wouldn't we use environment variables for what they've been created for, it's foolish :-) Because using environment variables to tune program X will also affect programs A-Z. Nope. Try this at your Unix command prompt: echo $CRAP CRAP=hello echo $CRAP CRAP=world echo $CRAP Your example is actually broken, because this is parsed by the shell separately, CRAP=hello is passed as an env variable to the echo command but the $CRAP expansion is evaluated before the command is called, so it will always have the value that had before every echo call (which is empty if you didn't define it before running those 3 commands). But try this for example: LANG=nonexistent perl /dev/null And see how your perl complaints. But anyway, yeah, that's the idea, there are many ways to define environment variables, and usually you never do so globally (except for things that you really want to affect the whole system, like the language). That doesn't mean you can't override it for a particular program. You can also create scripts to run programs, this is how Firefox runs for example: --- $ file /usr/bin/firefox /usr/bin/firefox: symbolic link to `../lib/firefox/firefox.sh' $ file /usr/lib/firefox/firefox.sh /usr/lib/firefox/firefox.sh: POSIX shell script, ASCII text executable $ grep -v '^#' /usr/lib/firefox/firefox.sh | head set -e MOZ_LIBDIR=/usr/lib/firefox MOZ_APP_LAUNCHER=`which $0` MOZ_APP_NAME=firefox MOZ_DEFAULT_PROFILEDIR=.mozilla/firefox MOZ_PROFILEDIR=.mozilla/firefox --- It basically defines a bunch of environment variables and run the binary. This is a super common practice in posix systems. We are not inventing anything here. I don't know how windows or other OSs deal with defining environment variables in a script. Very basic facilities are always configured this way, for example try man 3 mallopt to see how can you change options in the malloc implementation using environment variables... -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Ladrón no es cualquiera, ladrón es quien usurpa el bien ajeno en beneficio propio, si no, no. -- Ricardo Vaporeso
Re: Visual D 0.3.39 released - mago now supports 64-bit debugging
I'm not sure what the problem is, but with this release, when I open a new file and select empty D module, after a few seconds devenv.exe goes berserk and starts eating up my CPU. At that point, Visual Studio becomes unresponsive.
Re: Despiker 0.1: a GUI real-time profiler for game development
On Friday, 10 October 2014 at 23:55:03 UTC, Kiith-Sa wrote: -- Announcing Despiker, a GUI real time profiler for game development -- Very cool. Tharsis looks very interesting too. Also, it appears you have a great blog about this and other stuff I'm surprised I've never seen before.
Re: D2 port of Sociomantic CDGC available for early experiments
On 10/11/2014 4:23 PM, Leandro Lucarella wrote: It basically defines a bunch of environment variables and run the binary. This is a super common practice in posix systems. We are not inventing anything here. I don't know how windows or other OSs deal with defining environment variables in a script. Very basic facilities are always configured this way, for example try man 3 mallopt to see how can you change options in the malloc implementation using environment variables... I don't deny it is common practice on Linux, but defining a bunch of environment variables and then running the app, i.e. using the ev's as command line switches, seems pointless. Just use command line switches. Anyhow, environment variables are a common source of problems on Windows, which is why dmd, for example, uses dmd.conf instead.
Re: struct and default constructor
On Friday, October 10, 2014 22:49:13 Walter Bright via Digitalmars-d wrote:
On 10/10/2014 9:43 PM, Dicebot wrote:
There is ER somewhere in bugzilla AFAIR about allowing CTFE-only struct
default constructors.
Note that you can do (as pointed out upthread):
struct S {
int x = 7;
string s = hello;
}
which then has default initialization. Of course, CTFE will work on those
rvalues.
The only reason that I can think of to have default constructors for filling
in the member variables during CTFE would be if you wanted to calculate some
of the values based on other values, and while that might be nice upon
occasion, I don't think that not having it is much of a loss.
- Jonathan M Davis
Re: Worse is better?
On 10/10/2014 06:25 PM, Walter Bright wrote: On 10/9/2014 5:36 PM, deadalnix wrote: Is this the politically correct wy to say we don't care about simplicity anymore! ? If simplicity was the overriding goal, we'd settle for the simplest possible language that was Turing complete. In other words, Brainfuck: http://en.wikipedia.org/wiki/Brainfuck It only has 8 commmands and *nothing* else, SOOO SIMPLE!!! I've been incredibly productive ever since I switched to BF! It's so amazingly simple and orthogonal that it only takes *just* a day or so to write a hello world! Brilliant! Today hello world, next millennium pong, and then some glorious day...*real useful software*! Mwahahahahah! /sarcastic_bastard turns back to his complicated language and resumes getting real work done...
Re: GDC Pandaboard/QEMU Framebuffer
On 10/11/2014 2:27 PM, John A wrote: One thing I'll do first is see if I can modify Derelict3 to be Phobos free. If so the opengl3 library will probably be more useful to me. There might even be a mid-point where only a portion of Phobos needs porting. I would recommended using the packages from DerelictOrg [1] rather than Derelict 3, as the latter is no longer maintained. [1] https://github.com/DerelictOrg --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote: On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote: This has come up before, and has been debated at length. const is used both as a storage class and as a type constructor, and is distinguished by the grammar: const(T) v; // type constructor, it affects the type T const T v; // storage class, affects the symbol v and the type of v In particular, const T *v; does not mean: const(T)* v; Wait what? Are you saying there is a single case when this: const T var; is not identical to this: const(T) var; No, look at the pointer symbol. Reddit users are not the ones who invest into this language. If this attitude won't change it is only a matter of time until you start losing existing corporate users deciding to go with other language or a fork instead (likely latter). I am very serious. Being a D user pretty much by definition implies someone willing to risk and experiment with programming tools to get a business edge. If costs of maintaing own fork become lower than regular losses from maintenance overhead from language quirks it becomes simple pragmatical solution. There is nothing personal about it. Consistency and being robust in preventing programmer mistakes is single most important feature in the long term. @nogc, C++ support, any declared feature - it all means nothing with a simple necessity to not waste money fighting the language. In that sense proposed change is _very_ beneficial in ROI terms. It forces trivial code base adjustment that results in preventing very common mistake rarely obvious for a newbies. This means a very real money gains in terms of training and daily mantenance overhead. Something I don't care much in a personal projects but will damn appreciate as one caring for success of my employer. This endless search for the ideal syntax is consuming our time while we aren't working on issues that matter. (And this change will consume users' time, too, not just ours.) Hardly anything matters more than that. Issues like that consume our time continiously for years, accumulating in wasted days weeks of worker time. Compared with time needed to adjust even several MLOC project gain is clear. Agreed with the sentiment. #pleasebreakourcode Lol.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote: On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote: Reddit users are not the ones who invest into this language. If this attitude won't change it is only a matter of time until you start losing existing corporate users deciding to go with other language or a fork instead (likely latter). Sadly, +1 I am very serious. Being a D user pretty much by definition implies someone willing to risk and experiment with programming tools to get a business edge. If costs of maintaing own fork become lower than regular losses from maintenance overhead from language quirks it becomes simple pragmatical solution. There is nothing personal about it. Consistency and being robust in preventing programmer mistakes is single most important feature in the long term. @nogc, C++ support, any declared feature - it all means nothing with a simple necessity to not waste money fighting the language. In that sense proposed change is _very_ beneficial in ROI terms. It forces trivial code base adjustment that results in preventing very common mistake rarely obvious for a newbies. This means a very real money gains in terms of training and daily mantenance overhead. Something I don't care much in a personal projects but will damn appreciate as one caring for success of my employer. This endless search for the ideal syntax is consuming our time while we aren't working on issues that matter. (And this change will consume users' time, too, not just ours.) Hardly anything matters more than that. Issues like that consume our time continiously for years, accumulating in wasted days weeks of worker time. Compared with time needed to adjust even several MLOC project gain is clear. #pleasebreakourcode +1 over all Plus, I would not spend anymore one world in arguing against the reddit argumentation: it's really too much for me. --- /Paolo
Re: struct and default constructor
On Friday, 10 October 2014 at 22:34:45 UTC, ketmar via
Digitalmars-d wrote:
I think I like the idea of the factory method now though, as
I've learned you can hide a struct inside a function, and then
call the function to set the struct up properly and return it.
At least, I'm sure I've seen code that does that..
ah, yes, it's Voldemort type. ;-)
auto thatWhoCantBeNamed () {
static struct A { ... }
return A();
}
voila. you have type that you can use but cannot create without
factory. but you need to have postblit enabled with this.
It's not a Voldemort type if the struct A is static, is it? You
can just alias A = typeof(thatWhoCantBeNamed()); and then create
a new object of the same type.
--
Nicolas
Re: struct and default constructor
On Friday, 10 October 2014 at 22:34:45 UTC, ketmar via Digitalmars-d wrote: On Fri, 10 Oct 2014 21:45:32 + Shouldn't properties not mutate the data? it depends. ;-) i think that doing such lazy initialization in property is acceptable. maybe not the best style, but acceptable. yet i may be wrong, of course. Ah, I see. Lazy initialization is a nice approach to some things. But I'm not entirely sure it belongs in the structure or object itself.. however, if I were too I might put it in a 'length' or 'rezise' member function.. but that'd be better for a resizable object.. better methods to doing it safely, for sure. But to do the same with only a single pointer? why do you insisting on having single pointer? sure you can use all sort of tricks to pack alot of data in single pointer, but i can't see any practical sense in it. today when smartphones have gigabytes of RAM, i'll trade some more pointers for ease of using and safety. Actually, I think memory efficiency and speed are pretty key today, especially with embedded systems, server farms, and mobile devices. And it doesn't just have to do with available memory, but cache lines, register usage, etc. But that's another debate for another time. As far as the safety tradeoff though.. I prevent copying and default construction, so at least two problems should theoretically be solved. The possibility of using ranges or pointers outside of the function or scope is the only thing that would need to be controlled for. And there I suppose the GC or reference counting mechanisms would be the only other options. But hopefully if I document it right, and suggest the correct alternatives to use, I can prevent careless programmers from making those mistakes. (I think std.container.array.Array is a nice fallback) ah, yes, it's Voldemort type. ;-) Ah, I had wondered why/where/what context I heard that under! Makes more sense now. =) Also, thanks for the other pointers (I didnt quote everything here)
Re: struct and default constructor
Okay, I'm still kind of new to this language, so forgive me if I
see things a little differently than long time users..
Here's what I see though.
With Walter's description of what structures should be, it seems
to me to be slightly at odds with what D structures are capable
of, and in fact what they are being used for in a number of
places ('fixing' GC, adding reference counting, providing RAII,
etc).
Structs are classically POD types, as we know from C. But with D
you've added overloaded constructors, destructors, member
functions etc. To me that more or less defines an object, albeit
one with special limits. If you don't want to call them objects,
thats fine. But the fact that they have customizable behavior in
creation, copying, moving, and destruction means that they are
much more than just a plain old data type with generic T.init
states. They are a kind of living object, yea?
And it seems to me that the default constructor is just the last
component left to cement the structure as an object. It seems
curious that you would allow the ability to disable default
construction and copy construction, and allow hiding of
constructors, etc.. but then determine that default constructors
are going too far?
Sure, having a guarantee that a struct will always be created
without a fail state is a great concept. But why then haven't
they just been kept as a collection of data types, and another
'scope object' been created instead?
It seems what has happened is a FrankenStruct monster was created
in the midst of trying to find some midway point between D
objects and 'scope objects'..
I would myself love to use objects all the time, but I see these
problems that currently only the FrankenStructs resolve:
1. Objects are basically pointers, and can be null pointers at
that! (To me, that's C-levels of safety there)
However: Structs are always created.
2. Without assigning something to an object, there's obviously no
real initialization.
However: Structs are initialized on creation.
3. Object Destructors are called 'sometime in the future' when GC
runs. Cleaning up resources is discouraged as those resources
might have been cleaned up by the GC?
However: Struct destructors run when they are out of scope.
4. Objects always have at least one level of indirection (and a
lot of extra data)
Structs are there where you define them. (with no extra data)
I may not be 100% on all of this, I'm still learning. But many
times browsing the forums, reading the D books etc, I see the
solutions to D object problems becoming this: wrap it with a
struct. So whether its something like RefCounted, Scoped,
NonNullable, UniqueArray etc.. the problems with D objects are
fixed by relying on the guarantees provided by structures to
solve them.
I dunno, to me it all seems a bit discordant with what Walter
seems to want them to be?
(Sorry in advance if any of this comes off as mean or provoking..
I'm just sharing how I view the language design)
Re: struct and default constructor
On Sat, 11 Oct 2014 08:41:15 +
Nicolas Sicard via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Friday, 10 October 2014 at 22:34:45 UTC, ketmar via
Digitalmars-d wrote:
I think I like the idea of the factory method now though, as
I've learned you can hide a struct inside a function, and then
call the function to set the struct up properly and return it.
At least, I'm sure I've seen code that does that..
ah, yes, it's Voldemort type. ;-)
auto thatWhoCantBeNamed () {
static struct A { ... }
return A();
}
voila. you have type that you can use but cannot create without
factory. but you need to have postblit enabled with this.
It's not a Voldemort type if the struct A is static, is it? You
can just alias A = typeof(thatWhoCantBeNamed()); and then create
a new object of the same type.
yes, my bad. i'm so used to write static to avoid the things that
compiler can remove for me that my code is polluted with it.
thank you.
signature.asc
Description: PGP signature
Re: What are the worst parts of D?
On Wednesday, 8 October 2014 at 19:00:44 UTC, Jonathan wrote: 3) Taking a hint from the early success of Flash, add Derelict3 (or some basic OpenGL library) directly into Phobos. Despite some of the negatives (slower update cycle versus external lib), it would greatly add to D's attractiveness for new developers. I nearly left D after having a host issues putting Derelict3 into my project. If I had this issue, we may be missing out from attracting newbies looking to do gfx related work. This reminds of an idea I've been pondering over for a while now. What if there was a language, that came with a standard toolkit for the more fun stuff such as OpenGL (There could be one already and I just don't know of it). But if we take that idea and try to apply it to D, we sortof get Deimos. Problem is Deimos, is pretty disjointed and is only updated every now and then, so then as an alternative I suppose there is Derelict. However, Derelict is maintained primarily by one person it seems (he does a great job though!), but Derelict isn't a standard feature (I know Deimos isn't either) and I *personally* don't care much for it's heavy leaning on dub. +Derelict isn't always a walk in the park to get running The alternative I'm suggesting, not by any means a top priority, is give Deimos a makeover (Derelict could possibly be a big part of this) and turn it into a semi-standard feature. So you can import phobos modules to do the stuff phobos normally does, but if you feel like making a quick tool or two, you can import deimos to get Tcl/tk like you would in python, or call OpenGl, or whatever other tool you need (doesn't have to be a graphics thing). Then at compile time the compiler could just copy or build the required dll's\so's object files into the specified directory, or whatever works best. On Wednesday, 8 October 2014 at 19:47:05 UTC, Jeremy Powers via Digitalmars-d wrote: Personally I take the opposite view - I'd much prefer a strong and easily consumed third-party library ecosystem than to shove everything into Phobos. Dub is a wonderful thing for D, and needs to be so good that people use it by default. Not to initiate my biweekly not a fan of dub conversation, but just wanna say real quick: Not everyone really likes to use dub. The only thing I like about it, is using it as the build script for a library to get the .lib files and whatnot. Though I don't feel like it really adds a drastic improvement over a .d build script. However, I don't work on any open source libraries, but maybe if I did, I'd like it better then..? Not something I would have an answer to right now, soo... yea:P Aside from what I mentioned above, I'm not sure where I'd like D to be at next to be perfectly honest. Stuff like no GC or C++ integration sound cool, but for me personally they just seem like 'neat' feature, not something that I feel like would change my current workflow for better or worse. Refinement of what's already in place sounds the best if anything. So those are just some passing thoughts of a stranger.. carry on, this thread has been very interesting so far ;P
Re: compile time configurations
I did something similar a while back. It parsed a .ini that
contained default values and created a statically typed runtime
parser for the actual .ini file from it. It was fun, to see
that you can do that with D.
Yes. I use import('filename') to configure my application too. I
have config.json, where I store standard application's file
paths, options and so on. It's very handy compiler's feature
Re: struct and default constructor
On Sat, 11 Oct 2014 08:53:08 + dcrepid via Digitalmars-d digitalmars-d@puremagic.com wrote: structs also can't be inherited and can't have virtual methods (obviously, as they have no VMT). just a comment. ;-) ah, and don't forget another great aspect of structs: confusing C++ users! ;-) signature.asc Description: PGP signature
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On 10/10/2014 4:16 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
I agree with that general sentiment, but doesn't this patch only deprecate
left-hand-side function attributes?
Only some of them, others remain:
pure int foo() { ... }
I don't particularly mind you refusing it, but deprecation (in support of good
stylistic practice) isn't breaking.
Deprecation means it'll be removed.
Re: What are the worst parts of D?
On Saturday, 11 October 2014 at 03:39:10 UTC, Dicebot wrote: I am not speaking about O(1) internal heap increases but O(1) GC.malloc calls Typical pattern is to encapsulate temporary buffer with the algorithm in a single class object and never release it, reusing with new incoming requests (wiping the buffer data each time). Such buffer quickly gets to the point where it is large enough to contain all algorithm temporaries for a single request and never touches GC from there. In a well-written program which follows such pattern there are close to zero temporaries and GC only manages more persistent entities like cache elements. I understand that. My argument is that the same should apply to the entire heap: After you've allocated and released a certain amount of objects via GC.malloc() and GC.free(), the heap will have grown to a size large enough that any subsequent allocations of temporary objects can be satisfied from the existing heap without triggering a collection, so that only the overhead of actual allocation and freeing should be relevant.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote: #pleasebreakourcode No, it's #pleasedeprecateourcode For a change like this, with proper deprecation, there will be no broken code.
Re: [Semi OT] Language for Game Development talk
Le 02/10/2014 08:22, Manu via Digitalmars-d a écrit : On 2 October 2014 00:16, bearophile via Digitalmars-d digitalmars-d@puremagic.com wrote: Max Klyga: https://www.youtube.com/watch?v=TH9VCN6UkyQ A third talk (from another person) about related matters: https://www.youtube.com/watch?v=rX0ItVEVjHc He doesn't use RTTI, exceptions, multiple inheritance, STL, templates, and lot of other C++ stuff. On the other hand he writes data-oriented code manually, the compiler and language give him only very limited help, and the code he writes looks twiddly and bug-prone. So why aren't they designing a language without most of the C++ stuff they don't use, but with features that help them write the data-oriented code they need? Most gamedev's aren't quite as staunch as Mike Acton. The principle is there, ingrained in every gamedev, but that doesn't mean we all love flat C (although lots of us do!). I've never used RTTI, I've never used exceptions, certainly never use multiple inheritance, I rarely use templates (in C++)... but I'm still attracted to D!? I often find this strange... but not really. In D, I still don't use RTTI, I still don't use exceptions, I tend to box use of templates into their own worlds, so I would never use them pervasively (like phobos). You'll notice at one point that he talked about using offline text processing tools to do codegen... this is basically because C's preprocessor sucks, and C++ templates suck. D templates have proven to eliminate a lot of those offline tools for me. The code is kept in the same place, and built using the same tool. I suspect even Acton would appreciate features like CTFE. You'll also notice he made repeated reference to build environment complexity and build times. D also offers potential compiler advantages, purity, immutable, etc, which give the optimiser information which it can use to improve codegen which is awkward in C/C++. For the application I am working on the 3D developer wrote everything in c++ style, but he made a lot of mistakes that killing performances. We are far away cache miss issues (or polymorphism,...), and more in instancing ones. Last week I removed allocation and deallocation of meshes made in the sort for transparent models. new and delete aren't the main problem, it was the code in constructors and destructors that made heavy use of vectors. Things like vector.erase(vector.find(boo)); One my PC (a gamer one) I just win 20FPS from 10 to 30. For a scene of 700 objects ( 50 000 triangles). YEP this is really bad for my i7 and my 670GTX. I have a lot of work to do, normally on my PC for a such scene I can expect much more than 200 FPS. This is just one of our performances issues, and for me it's not due to only C++ OOP. It's about experience. I had never worked on games or applications need a level of optimization impose me SOA design but reusing chunk of memories and avoiding unnecessary computations are always things I carry on. For those are interested to see more about the application : https://groups.google.com/forum/#!forum/home-design-3d-beta This is also the one that inspired me and my friend for DQuick.
Re: What are the worst parts of D?
Exactly. C++ support is of no interest at all, and GC is something we contribute to, rather than something we expect from the community. Interestingly we don't even care much about libraries, we've done everything ourselves. So what do we care about? Mainly, we care about improving the core product. In general I think that in D we have always suffered from spreading ourselves too thin. We've always had a bunch of cool new features that don't actually work properly. Always, the focus shifts to something else, before the previous feature was finished. At Sociomantic, we've been successful in our industry using only the features of D1. We're restricted to using D's features from 2007!! Feature-wise, practically nothing from the last seven years has helped us! With something like C++ support, it's only going to win companies over when it is essentially complete. That means that working on it is a huge investment that doesn't start to pay for itself for a very long time. So although it's a great goal, with a huge potential payoff, I don't think that it should be consuming a whole lot of energy right now. And personally, I doubt that many companies would use D, even if with perfect C++ interop, if the toolchain stayed at the current level. As I said in my Dconf 2013 talk -- I advocate a focus on Return On Investment. I'd love to see us chasing the easy wins. disclaimer: i am rather new to D and thus have a bit of a distant view. i think the above touches an important point. One thing GO does right is that they focused on feature rich stdlib/library ecosystem even though the language was very young. i'm coming from Ruby/Python and the reason i use those languages is that they have two things: a) they are fun to use (as andrei said in the floss interview: the creators had taste). b) huge set of libs that help me to get stuff done. now i think a) is fine, but with b) i am not sure if the strategy to get full C/C++ interop will not take too long and scare those people off that are not coming from C/C++. i think D is a fantastic tool to write expressive, fast and readable code. I don't need much more language features (again, look at GO...) but a solid foundation of libs to gain competitive advantage in my daily work.
Re: DIP66 - Multiple alias this
On 2014-10-11 00:52, Walter Bright wrote: I like the C++ rule that says that access control is not considered for name lookup. I know it makes for some annoying results, but the simplicity of the rule makes it much more understandable. I'm not so sure about that. Perhaps it makes it more understandable for a language designer. But not for a user. You try to call a function but you get a conflict with a private symbol. The user will get frustrated thinking: stupid compiler, of course I want to call the public function. -- /Jacob Carlborg
Re: std.experimental.logger formal review round 3
On 2014-10-11 05:41, Dicebot wrote: I don't see critical objections so far and this will move to voting stage this weekend. Please hurry up if you want to say something bad :) I think it's unacceptable that the documentation of defaultLogFunction and trace, info and so on is merged. Same thing with memLogFunctions. Do these even need to be exposed? -- /Jacob Carlborg
Re: std.experimental.logger formal review round 3
On Saturday, 11 October 2014 at 10:48:00 UTC, Jacob Carlborg wrote: On 2014-10-11 05:41, Dicebot wrote: I don't see critical objections so far and this will move to voting stage this weekend. Please hurry up if you want to say something bad :) I think it's unacceptable that the documentation of defaultLogFunction and trace, info and so on is merged. Same thing with memLogFunctions. Do these even need to be exposed? this has been used make user defined LogLevel log functions, like trace1(...), trace2(...)
Re: std.experimental.logger formal review round 3
On Saturday, 11 October 2014 at 04:31:17 UTC, Jakob Ovrum wrote: On Saturday, 11 October 2014 at 03:41:08 UTC, Dicebot wrote: I don't see critical objections so far and this will move to voting stage this weekend. Please hurry up if you want to say something bad :) Attributes need to be applied thoroughly. Even if most uses will be through the base class `Logger`, it's still useful to have stronger guarantees through a derived class reference. This is particularly important because it's an important design decision to choose which attributes to apply to `Logger`'s methods. @trusted is used everywhere instead of properly using @safe and minimized @trusted. I think this is the third time I point this out... The multiloggers are a complete mess. There's both `ArrayLogger` and `MultiLogger`, and while `ArrayLogger` has simple O(n) operations, `MultiLogger` is a disaster: insertion iterates all elements twice and sorts the entire collection on every call, and removal iterates all elements once, then does binary search twice. Once using `SortedRange`'s search, and once using its own binary search algorithm. It also contains debug code that writes to stdout. Neither type adheres to the Phobos container concept, instead the underlying array is exposed as a public, undocumented field. `string` is used instead of `const(char)[]` for search and removal operations. The latest std.container.Array broke the code anyway, so it is due for a rewrite anyway. The implementation of `Logger` has several performance problems. `Logger` provides default behaviour that allocates GC memory multiple times for even the simplest log messages through the `Appender`. I don't think this behaviour should be encouraged by putting it in the root logger class, and besides, it can be made much more intelligent than just using a new appender for each message. Well, to have ultra simple thread-safe sub classing (which is an important part of the design), this was the price. This being said. Doing it nogc yourself if you know the output is very easy as shown in FileLogger. Another issue is that the way it's written currently, `writeLogPart` is called a lot more often than necessary, without any opportunity for optimization within `formattedWrite`, thus `FileLogger` is doomed to write to the underlying file character-by-character in easily reproducible circumstances (e.g. log a range of characters); this issue probably doesn't affect the API though. Again, by design. To allow user created structured logging, this is necessary. `Logger` has a bunch of public and documented `*Impl` functions... see my other post Some other line comments I posted a while ago have not been addressed. I will recheck github
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Saturday, 11 October 2014 at 10:18:29 UTC, bachmeier wrote: On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote: #pleasebreakourcode No, it's #pleasedeprecateourcode For a change like this, with proper deprecation, there will be no broken code. It does not sound as catchy :P Though I agree in statement itself
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Saturday, 11 October 2014 at 07:36:21 UTC, monarch_dodra wrote: Wait what? Are you saying there is a single case when this: const T var; is not identical to this: const(T) var; No, look at the pointer symbol. module test; const int** a; const(int**) b; **a = 42; Error: cannot modify const expression **a B _D4test1axPPi 0008 B _D4test1bxPPi ??? Can you give an examle of the code that actually observes the semantical difference?
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
https://github.com/D-Programming-Language/dmd/pull/4043#issuecomment-58748353 There has been a broad support for this on the newsgroup discussion because this regularly confuses beginners. There are also some arguments against it (particularly by Walter) saying that this change will put too much work on D code owners. Let's continue with the following steps. - add RHS/LHS function qualifiers to D's style guide - change all code formatting (like dmd's headergen and ddoc to use RHS qualifiers) - help Brian to get dfix up and running (https://github.com/Hackerpilot/dfix/issues/1) Then we might revisit the topic in 6 month and see whether we have better arguments now.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Sat, 11 Oct 2014 14:47:55 +0200 Martin Nowak via Digitalmars-d digitalmars-d@puremagic.com wrote: Then we might revisit the topic in 6 month and see whether we have better arguments now. six month? SIX FCKING MONTH?! ARE YOU KIDDING? ah, probably not... ok, at least reddit users will be happy. they will, aren't they? signature.asc Description: PGP signature
Re: std.experimental.logger formal review round 3
On 09/28/2014 02:24 PM, Dicebot wrote: Important changes since last review: - new approach for compile-time log level filtering What's new here? It still relies on version identifiers to do so. As I said in some earlier review, I think it's a bad idea for a library to rely on version identifiers that are defined in client code. I will only work for templated code and makes it much harder for build tools. In a way it's the equivalent of #define LOG_LEVEL 2 #include logger.h I even proposed an alternative that uses type tags instead. http://dpaste.dzfl.pl/95fb6a4e086d Usual process : 2 weeks for checking out if there are any critical issues that are likely to prevent successful voting, write a comment if you need more time for review, focus on API issues. - Documentation is out of sync. - ArrayLogger seems to do about the same as MultiLogger - Why do loggers have to be classes? - Define a concept (isLogger template) with the requirements. - Add a Logger interface and a loggerObject to wrap structures when polymorphic loggers are needed.
Re: std.experimental.logger formal review round 3
On Saturday, 11 October 2014 at 13:16:18 UTC, Martin Nowak wrote: On 09/28/2014 02:24 PM, Dicebot wrote: Important changes since last review: - new approach for compile-time log level filtering What's new here? It still relies on version identifiers to do so. As I said in some earlier review, I think it's a bad idea for a library to rely on version identifiers that are defined in client code. I will only work for templated code and makes it much harder for build tools. In a way it's the equivalent of #define LOG_LEVEL 2 #include logger.h All that code is contained in 30 line template, That is by far the best working option anybody could come up with I even proposed an alternative that uses type tags instead. http://dpaste.dzfl.pl/95fb6a4e086d And I showed that it did not work. - Documentation is out of sync. gh-page is yes, give me 15min - ArrayLogger seems to do about the same as MultiLogger have you read my reply to Jacob - Why do loggers have to be classes? As answered multiply times before, to build log hierarchies.
Re: std.experimental.logger formal review round 3
On Saturday, 11 October 2014 at 03:41:08 UTC, Dicebot wrote: I don't see critical objections so far and this will move to voting stage this weekend. Please hurry up if you want to say something bad :) MultiLogger got a new simpler impl.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Saturday, 11 October 2014 at 12:48:03 UTC, Martin Nowak wrote: https://github.com/D-Programming-Language/dmd/pull/4043#issuecomment-58748353 There has been a broad support for this on the newsgroup discussion because this regularly confuses beginners. There are also some arguments against it (particularly by Walter) saying that this change will put too much work on D code owners. Let's continue with the following steps. - add RHS/LHS function qualifiers to D's style guide - change all code formatting (like dmd's headergen and ddoc to use RHS qualifiers) - help Brian to get dfix up and running (https://github.com/Hackerpilot/dfix/issues/1) Then we might revisit the topic in 6 month and see whether we have better arguments now. Sounds good but what is the benefit over just having deprecation period 6 months longer?
Re: What are the worst parts of D?
On Saturday, 11 October 2014 at 09:26:28 UTC, Marc Schütz wrote: I understand that. My argument is that the same should apply to the entire heap: After you've allocated and released a certain amount of objects via GC.malloc() and GC.free(), the heap will have grown to a size large enough that any subsequent allocations of temporary objects can be satisfied from the existing heap without triggering a collection, so that only the overhead of actual allocation and freeing should be relevant. But it still requires GC to check its pool state upon each request and make relevant adjustments for malloc/free combo. For something like a hundred of temporary allocations per request it accumulates into notable time (and milliseconds matter). In absence of collection it is cheap enough to not care about single malloc call on its own but still not cheap enough to ignore costs of many calls. You have interested me in doing some related benchmarks though.
Re: DIP66 - Multiple alias this
On Saturday, 11 October 2014 at 00:00:48 UTC, Walter Bright wrote:
On 10/10/2014 4:23 PM, IgorStepanov wrote:
On Friday, 10 October 2014 at 22:50:25 UTC, Walter Bright
wrote:
must be an error, even if one of C.a() or C.b() might be a
better match.
This is how things work for template mixins and imports.
So it is.
Good!
The same rule applies for overloading.
I've implemented overloading:
https://github.com/D-Programming-Language/dmd/pull/3998/files#diff-17b22eae29e74ce6ec29037438b5031cR2136
Please, tell me, what changes should I make to the DIP as a
result of yesterday's discussions.
And please, tell your opinion about is issue:
class A
{
int i;
alias i this;
}
class B
{
int i;
alias i this;
}
class C
{
A a;
B b;
alias a this;
alias b this;
}
void foo(T)(T arg) if(is(T : int))
{
...
}
foo(C()); //Should it pass or not?
Re: std.experimental.logger formal review round 3
On 2014-10-11 14:08, Robert burner Schadek wrote: this has been used make user defined LogLevel log functions, like trace1(...), trace2(...) I still don't like the merge of the documentation. -- /Jacob Carlborg
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Saturday, 11 October 2014 at 13:00:33 UTC, ketmar via Digitalmars-d wrote: On Sat, 11 Oct 2014 14:47:55 +0200 Martin Nowak via Digitalmars-d digitalmars-d@puremagic.com wrote: Then we might revisit the topic in 6 month and see whether we have better arguments now. six month? SIX FCKING MONTH?! ARE YOU KIDDING? ah, probably not... ok, at least reddit users will be happy. they will, aren't they? gtfo ketmar
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Saturday, 11 October 2014 at 15:17:36 UTC, ketmar gtfo wrote: On Saturday, 11 October 2014 at 13:00:33 UTC, ketmar via Digitalmars-d wrote: On Sat, 11 Oct 2014 14:47:55 +0200 Martin Nowak via Digitalmars-d digitalmars-d@puremagic.com wrote: Then we might revisit the topic in 6 month and see whether we have better arguments now. six month? SIX FCKING MONTH?! ARE YOU KIDDING? ah, probably not... ok, at least reddit users will be happy. they will, aren't they? gtfo ketmar gtfo ketmar gtfo
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Saturday, 11 October 2014 at 12:45:40 UTC, Dicebot wrote: On Saturday, 11 October 2014 at 07:36:21 UTC, monarch_dodra wrote: Wait what? Are you saying there is a single case when this: const T var; is not identical to this: const(T) var; No, look at the pointer symbol. module test; const int** a; const(int**) b; The original code you quoted was const(T)* v; where the * was *outside* of the parens. **a = 42; Error: cannot modify const expression **a B _D4test1axPPi 0008 B _D4test1bxPPi ??? Can you give an examle of the code that actually observes the semantical difference? I cannot. I was trying to prove that there isn't, after you made the statement Wait what? Are you saying there is a single case when this is not identical to this.
Why this doesn't compile?
When I want to pass generic String by const reference I get an
error. As far as I understand const should accept both mutable
and immutable data. And there I want to pass it by reference. Is
it possible? Or is there any reason why it is not? Is it a bug?
void doSmth(String)(ref const(String) str) {}
void main()
{
doSmth(Foo);
}
Compilation output:
/d198/f399.d(5): Error: template f399.doSmth does not match any
function template declaration. Candidates are:
/d198/f399.d(1):f399.doSmth(String)(ref const(String) str)
/d198/f399.d(5): Error: template f399.doSmth(String)(ref
const(String) str) cannot deduce template function from argument
types !()(string)
Re: Why this doesn't compile?
On Sat, 11 Oct 2014 18:01:39 + Uranuz via Digitalmars-d digitalmars-d@puremagic.com wrote: Is it a bug? yes. this is a bug in your code. and it's not alone. signature.asc Description: PGP signature
Re: Why this doesn't compile?
On Saturday, 11 October 2014 at 18:01:41 UTC, Uranuz wrote:
When I want to pass generic String by const reference I get an
error. As far as I understand const should accept both mutable
and immutable data. And there I want to pass it by reference.
Is it possible? Or is there any reason why it is not? Is it a
bug?
void doSmth(String)(ref const(String) str) {}
void main()
{
doSmth(Foo);
}
Compilation output:
/d198/f399.d(5): Error: template f399.doSmth does not match any
function template declaration. Candidates are:
/d198/f399.d(1):f399.doSmth(String)(ref const(String)
str)
/d198/f399.d(5): Error: template f399.doSmth(String)(ref
const(String) str) cannot deduce template function from
argument types !()(string)
Try doSmth!String(bla);
Also, the type is string, not String ?
Re: Why this doesn't compile?
On Saturday, 11 October 2014 at 18:01:41 UTC, Uranuz wrote: When I want to pass generic String by const reference I get an error. Strings are passed by reference automatically, so you wouldn't want to double reference them anyway. As far as I understand const should accept both mutable and immutable data. And there I want to pass it by reference. Yes, but since foo isn't an lvalue (variable), you can't pass it by ref in D, even if it is const. This differs from C++, but I don't recall the reason, I think there's just too many weird edge cases that D wanted to avoid. But in the case of strings, arrays, classes, pointers, and user defined structs that wrap these, you don't need to pass it as ref at all, just use plain const.
Re: Why this doesn't compile?
yaOn Saturday, 11 October 2014 at 18:11:07 UTC, ketmar via Digitalmars-d wrote: On Sat, 11 Oct 2014 18:01:39 + Uranuz via Digitalmars-d digitalmars-d@puremagic.com wrote: Is it a bug? yes. this is a bug in your code. and it's not alone. You said you leave. Why dont you just go? Don't be a liar. Bye ketmar!
Re: Program logic bugs vs input/environmental errors
On 10/10/2014 05:31 AM, Joseph Rushton Wakeling wrote: On Friday, 10 October 2014 at 06:28:06 UTC, Iain Buclaw via Digitalmars-d wrote: http://www.wired.com/2012/12/what-does-randomness-look-like/ ... yes, allowing for the reasonable expectations one can have for extended runs of heads in a regular 50/50 coin-flip process. Actually, related to that article, in my very first stats lecture at university, the first slide the lecturer showed us (on the overhead projector...) was, side by side, two patterns of dots each within a rectangular area. He asked: Do you think these points are distributed at random? Well, they pretty much looked the same to the naked eye. Then he took another transparency, which placed grids over the two rectangular dot-filled areas. In one, the dots were here, there, with some grid squares containing no dots at all, some containing clusters, whatever. In the other, every single grid square contained exactly one dot. I still think that was one of the single most important lessons in probability that I ever had. I like that. I actually have a similar classroom probability story too (involving one of the best teachers I ever had): As part of a probability homework assignment, we were asked to flip a coin 100 times and write down the results. Uhh, yea, there's no way I'm doing that. I'm just gonna write down a bunch of T's and F's. Having previously played around with PRNG's (using them, not actually creating them), I had noticed that you do tend to get surprisingly long runs of one value missing, or the occasional clustering. I carefully used that knowledge to help me cheat. During the next class, the teacher pointed out that I can tell, most of you didn't actually flip a coin, did you? You just wrote down T's and F's... Which turned out to be the whole *point* of the assignment. Deliberately get students to cheat and fake randomness - poorly - in order to *really* get them to understand the nature of randomness. Then he turned to me and said, Uhh, Nick, you actually DID flip a coin didn't you? Hehe heh heh. Nope :) I got a good chuckle out of that.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Saturday, 11 October 2014 at 17:27:22 UTC, monarch_dodra wrote: On Saturday, 11 October 2014 at 12:45:40 UTC, Dicebot wrote: On Saturday, 11 October 2014 at 07:36:21 UTC, monarch_dodra wrote: Wait what? Are you saying there is a single case when this: const T var; is not identical to this: const(T) var; No, look at the pointer symbol. module test; const int** a; const(int**) b; The original code you quoted was const(T)* v; where the * was *outside* of the parens. There was no * in my quote, only `const(T)` vs `const T` (with any compound T) The fact that const T* means const(T*) does not indicate that const is a storage class but simply a parsing rule. Walter has made a statement that there is a const storage class that is distinct from const qualified. I want example.
Re: struct and default constructor
On Saturday, 11 October 2014 at 09:19:47 UTC, ketmar via Digitalmars-d wrote: On Sat, 11 Oct 2014 08:53:08 + dcrepid via Digitalmars-d digitalmars-d@puremagic.com wrote: structs also can't be inherited and can't have virtual methods (obviously, as they have no VMT). just a comment. ;-) Yeah, thats one of the things I meant by with special limits. =)
Re: std.experimental.logger formal review round 3
On Saturday, 11 October 2014 at 03:41:08 UTC, Dicebot wrote: I don't see critical objections so far and this will move to voting stage this weekend. Please hurry up if you want to say something bad :) I don't think I will use it for the reasons I stated in the previous thread, so no point in saying anything bad.
Re: Program logic bugs vs input/environmental errors
On 10/9/2014 9:33 AM, Johannes Pfau wrote: A point which hasn't been discussed yet: Errors and therefore assert can be used in nothrow functions. This is a pita for compilers because it now can't do certain optimizations. When porting GDC to ARM we started to see problems because of that (can't unwind from nothrow functions on ARM, program just aborts). And now we therefore have to worsen the codegen for nothrow functions because of this. I think Walter sometimes suggested that it would be valid for a compiler to not unwind Errors at all (in release mode), but simply kill the program and dump a error message. This would finally allow us to optimize nothrow functions. Currently, Errors can be caught, but intervening finally blocks are not necessarily run. The reasons for this are: 1. better code generation 2. since after an Error the program is likely in an unknown state, the less code that is run after an Error, the better, because it may make things worse
Re: Program logic bugs vs input/environmental errors
On 10/9/2014 10:31 AM, Dicebot wrote: On Thursday, 9 October 2014 at 16:33:53 UTC, Johannes Pfau wrote: I think Walter sometimes suggested that it would be valid for a compiler to not unwind Errors at all (in release mode), but simply kill the program and dump a error message. This would finally allow us to optimize nothrow functions. I think this is reasonable in general but as long as assert throws Error and assert is encouraged to be used in unittest blocks such implementation would mark compiler as unusable for me. All assert actually does is call a function in druntime. You can override and insert your own assert handling function, and have it do as you need. It was deliberately designed that way. We may need to have another look at what is truly an Error and what is not before going that path. This involves making some hard decisions, but is worthwhile.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Saturday, October 11, 2014 14:47:55 Martin Nowak via Digitalmars-d wrote: https://github.com/D-Programming-Language/dmd/pull/4043#issuecomment-5874835 3 There has been a broad support for this on the newsgroup discussion because this regularly confuses beginners. There are also some arguments against it (particularly by Walter) saying that this change will put too much work on D code owners. Let's continue with the following steps. - add RHS/LHS function qualifiers to D's style guide - change all code formatting (like dmd's headergen and ddoc to use RHS qualifiers) - help Brian to get dfix up and running (https://github.com/Hackerpilot/dfix/issues/1) Then we might revisit the topic in 6 month and see whether we have better arguments now. This has been being brought up for years. I wouldn't expect 6 months to change anything. If we want to delay it until dmd's headergen and ddoc are fixed and put a note in the changelog on the next release that it's going to be deprecated rather than deprecating it immediately, we can do that, but I don't think for a second that the arguments are going to change. Many of us have been complaining about this for years, and it's primarily been Walter who hasn't wanted it on the grounds that it's more consistent as it is (which I strongly dispute). As far as I can tell, Walter is the only real obstacle to this. Almost no one else ever seems to think that having const function modifiers on the left is a good idea. And now that someone has finally implemented the change, I really think that we need to get it merged. Honestly, I think that delaying making the change just increases how much harm the problem is causing, because it's around that much longer, confusing that many more folks. As far as popular opinion goes, it's quite clear that almost everyone posting here thinks that it should be changed. The only one who seems to really need to be convinced is Walter, and apparently, no one knows how to do that. I can see delaying making the changes until the dmd headergen is fixed being needed so that the compiler isn't generating code that it then prints a deprecation message for, and it would be nice if the ddoc generation were fixed ASAP as well, but if that's the case, I think that that just means that those should be fixed ASAP so that const function qualifiers on the left can be deprecated ASAP. I see no need to continue to discuss whether we should do this beyond someone miraculously coming up with a way to convince Walter. - Jonathan M Davis
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
Jonathan M Davis: and it's primarily been Walter who hasn't wanted it on the grounds that it's more consistent as it is Consistency is a good thing to have, but if adhering to it causes bugs and troubles, and if the symmetry breakage causes readable compile-time errors, then it's often a good idea to do it. D language contains plenty of situations where this happens (and arguably few more cases should be added, like the sbyte/ubyte pair of names breaking the consistency of name/uname naming scheme for the other integral types, to avoid people think all the time that a byte is unsigned). Bye, bearophile
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Sat, 11 Oct 2014 22:41:50 + bearophile via Digitalmars-d digitalmars-d@puremagic.com wrote: Jonathan M Davis: and it's primarily been Walter who hasn't wanted it on the grounds that it's more consistent as it is Consistency is a good thing to have and it's not a goal, it's just a nice way to say i don't want this. see @safe, @trusted, pure and nothrow, for example. i can hardly say that it's consistent. breaking consistency rising up only if there is nothing else to say against something. signature.asc Description: PGP signature
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On 10/11/2014 3:18 AM, bachmeier via Digitalmars-d wrote: On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote: #pleasebreakourcode No, it's #pleasedeprecateourcode For a change like this, with proper deprecation, there will be no broken code. Yes, there will be. That there's a period of transition helps reduce it, but to believe that all code everywhere is upgraded during that transition is... wishful thinking. That said, I'm still in favor of this change. Please, remove the human confusion, there's enough of it already and this one is easy to fix.
Re: std.experimental.logger formal review round 3
Am Sat, 11 Oct 2014 12:23:10 + schrieb Robert burner Schadek rburn...@gmail.com: On Saturday, 11 October 2014 at 04:31:17 UTC, Jakob Ovrum wrote: The implementation of `Logger` has several performance problems. `Logger` provides default behaviour that allocates GC memory multiple times for even the simplest log messages through the `Appender`. I don't think this behaviour should be encouraged by putting it in the root logger class, and besides, it can be made much more intelligent than just using a new appender for each message. Well, to have ultra simple thread-safe sub classing (which is an important part of the design), this was the price. This being said. Doing it nogc yourself if you know the output is very easy as shown in FileLogger. I had the same feeling as Jakob about an `Appender` already in the base class and would have expected a bare bones abstract class + a batteries included version using `Appender`. (A bit like Java's …Listener and …Adapter classes.) That seems more clean to me in a representational fashion. Technically we can just ignore the extra field... It also seems legit to reduce pressure on the GC, by resetting the `Appender` instead of nulling it. -- Marco
Re: Why this doesn't compile?
On 2014-10-11 18:10:52 +, ketmar via Digitalmars-d said: On Sat, 11 Oct 2014 18:01:39 + Uranuz via Digitalmars-d digitalmars-d@puremagic.com wrote: Is it a bug? yes. this is a bug in your code. and it's not alone. image I've withheld from responding to you for a good long while. But, what is your deal Ketmar? You're constantly trolling on this newsgroup. It's not appreciated.
Re: Why this doesn't compile?
On 2014-10-11 18:10:22 +, Adam D. Ruppe said: On Saturday, 11 October 2014 at 18:01:41 UTC, Uranuz wrote: When I want to pass generic String by const reference I get an error. Strings are passed by reference automatically, so you wouldn't want to double reference them anyway. That's not entirely true. They're passed by value unless something changed. By value in that the struct representation is passed. That is to say, the length and a pointer. As far as I understand const should accept both mutable and immutable data. And there I want to pass it by reference. Yes, but since foo isn't an lvalue (variable), you can't pass it by ref in D, even if it is const. This differs from C++, but I don't recall the reason, I think there's just too many weird edge cases that D wanted to avoid. But in the case of strings, arrays, classes, pointers, and user defined structs that wrap these, you don't need to pass it as ref at all, just use plain const. That's because string literals are stored in the data segment and are immutable rvalues. You can't have a ref to an rvalue.
Re: DIP66 - Multiple alias this
On 10/11/2014 3:42 AM, Jacob Carlborg wrote: On 2014-10-11 00:52, Walter Bright wrote: I like the C++ rule that says that access control is not considered for name lookup. I know it makes for some annoying results, but the simplicity of the rule makes it much more understandable. I'm not so sure about that. Perhaps it makes it more understandable for a language designer. But not for a user. You try to call a function but you get a conflict with a private symbol. The user will get frustrated thinking: stupid compiler, of course I want to call the public function. The theory is that simpler rules are better than complex rules, even if the simpler rules aren't always ideal.
Re: DIP66 - Multiple alias this
On 10/11/2014 7:23 AM, IgorStepanov wrote:
On Saturday, 11 October 2014 at 00:00:48 UTC, Walter Bright wrote:
On 10/10/2014 4:23 PM, IgorStepanov wrote:
On Friday, 10 October 2014 at 22:50:25 UTC, Walter Bright wrote:
must be an error, even if one of C.a() or C.b() might be a better match.
This is how things work for template mixins and imports.
So it is.
Good!
The same rule applies for overloading.
I've implemented overloading:
https://github.com/D-Programming-Language/dmd/pull/3998/files#diff-17b22eae29e74ce6ec29037438b5031cR2136
Please, tell me, what changes should I make to the DIP as a result of
yesterday's discussions.
At the very least, it should say it resolves ambiguities the same way that
imports and template mixins do.
And please, tell your opinion about is issue:
class A
{
int i;
alias i this;
}
class B
{
int i;
alias i this;
}
class C
{
A a;
B b;
alias a this;
alias b this;
}
void foo(T)(T arg) if(is(T : int))
{
...
}
foo(C()); //Should it pass or not?
There's a rule with imports that if the same symbol is reachable via multiple
paths through the imports, that it is not an ambiguity error. Here, the same
type is reachable through multiple alias this paths, so by analogy it shouldn't
be an error.
Re: COFF on Win32 how to try?
On 10.10.2014 20:44, Szymon Gatner wrote:
Hi, thanks for all the information.
I got Digger (pretty nice tool btw) and it pulled all neccessary repos
from GitHub. As my understanding is that I should not be doing Build
with Diggger I just opened Windows console, entered druntime dir and typed:
You have to build dmd, so it should be good starting point to succeed
in building the full chain for win64: dmd, druntime and win64.
d:\digger-1.0\repo\druntimemake -f win64.mak MODEL=32mscoff
CC=\%VCINSTALLDIR
%\bin\cl.exe\
and got:
dmd -c -o- -Isrc -Iimport -Hfimport\core\sync\barrier.di
src\core\sync\barrier.d
src\core\stdc\stdio.d(859): Error: found 'nothrow' when expecting '{'
Ahh, I thought it would use a compiled dmd by default. You will have to
specify the path to dmd too:
make -f win64.mak MODEL=32mscoff CC=\%VCINSTALLDIR%\bin\cl.exe\
DMD=../result/bin/dmd
The given dmd path is specific to building with digger (the normal path
is ../dmd/src/dmd). You'll have to update sc.ini there, too.
Re: COFF on Win32 how to try?
On Saturday, 11 October 2014 at 09:21:18 UTC, Rainer Schuetze
wrote:
On 10.10.2014 20:44, Szymon Gatner wrote:
Hi, thanks for all the information.
I got Digger (pretty nice tool btw) and it pulled all
neccessary repos
from GitHub. As my understanding is that I should not be doing
Build
with Diggger I just opened Windows console, entered druntime
dir and typed:
You have to build dmd, so it should be good starting point to
succeed in building the full chain for win64: dmd, druntime and
win64.
You mean for Win32? Beacause that is what I am after.
d:\digger-1.0\repo\druntimemake -f win64.mak MODEL=32mscoff
CC=\%VCINSTALLDIR
%\bin\cl.exe\
and got:
dmd -c -o- -Isrc -Iimport -Hfimport\core\sync\barrier.di
src\core\sync\barrier.d
src\core\stdc\stdio.d(859): Error: found 'nothrow' when
expecting '{'
Ahh, I thought it would use a compiled dmd by default. You will
have to specify the path to dmd too:
make -f win64.mak MODEL=32mscoff
CC=\%VCINSTALLDIR%\bin\cl.exe\ DMD=../result/bin/dmd
The given dmd path is specific to building with digger (the
normal path is ../dmd/src/dmd). You'll have to update sc.ini
there, too.
So to build HEAD druntime and Phobos I also need HEAD DMD,
correct? Installation of 2.066 I have now is not sufficent?
Re: COFF on Win32 how to try?
On Saturday, 11 October 2014 at 10:12:47 UTC, Szymon Gatner wrote:
On Saturday, 11 October 2014 at 09:21:18 UTC, Rainer Schuetze
wrote:
On 10.10.2014 20:44, Szymon Gatner wrote:
Hi, thanks for all the information.
I got Digger (pretty nice tool btw) and it pulled all
neccessary repos
from GitHub. As my understanding is that I should not be
doing Build
with Diggger I just opened Windows console, entered druntime
dir and typed:
You have to build dmd, so it should be good starting point to
succeed in building the full chain for win64: dmd, druntime
and win64.
You mean for Win32? Beacause that is what I am after.
d:\digger-1.0\repo\druntimemake -f win64.mak MODEL=32mscoff
CC=\%VCINSTALLDIR
%\bin\cl.exe\
and got:
dmd -c -o- -Isrc -Iimport -Hfimport\core\sync\barrier.di
src\core\sync\barrier.d
src\core\stdc\stdio.d(859): Error: found 'nothrow' when
expecting '{'
Ahh, I thought it would use a compiled dmd by default. You
will have to specify the path to dmd too:
make -f win64.mak MODEL=32mscoff
CC=\%VCINSTALLDIR%\bin\cl.exe\ DMD=../result/bin/dmd
The given dmd path is specific to building with digger (the
normal path is ../dmd/src/dmd). You'll have to update sc.ini
there, too.
So to build HEAD druntime and Phobos I also need HEAD DMD,
correct? Installation of 2.066 I have now is not sufficent?
sounds good
Re: COFF on Win32 how to try?
On 11.10.2014 12:12, Szymon Gatner wrote:
On Saturday, 11 October 2014 at 09:21:18 UTC, Rainer Schuetze wrote:
On 10.10.2014 20:44, Szymon Gatner wrote:
Hi, thanks for all the information.
I got Digger (pretty nice tool btw) and it pulled all neccessary repos
from GitHub. As my understanding is that I should not be doing Build
with Diggger I just opened Windows console, entered druntime dir and
typed:
You have to build dmd, so it should be good starting point to succeed
in building the full chain for win64: dmd, druntime and win64.
You mean for Win32? Beacause that is what I am after.
I meant Win64, because the tool chain is very much the same as for
win32mscoff (MS compiler and linker and C runtime). Win32 means dmc and
optlink. That's also why the win64.mak makefiles are abused for win32mscoff.
d:\digger-1.0\repo\druntimemake -f win64.mak MODEL=32mscoff
CC=\%VCINSTALLDIR
%\bin\cl.exe\
and got:
dmd -c -o- -Isrc -Iimport -Hfimport\core\sync\barrier.di
src\core\sync\barrier.d
src\core\stdc\stdio.d(859): Error: found 'nothrow' when expecting '{'
Ahh, I thought it would use a compiled dmd by default. You will have
to specify the path to dmd too:
make -f win64.mak MODEL=32mscoff CC=\%VCINSTALLDIR%\bin\cl.exe\
DMD=../result/bin/dmd
The given dmd path is specific to building with digger (the normal
path is ../dmd/src/dmd). You'll have to update sc.ini there, too.
So to build HEAD druntime and Phobos I also need HEAD DMD, correct?
Installation of 2.066 I have now is not sufficent?
Yes, DMD git HEAD is required.
Re: Building a dmd that works on old systems: TLS problems with libc
On Friday, 3 October 2014 at 14:21:02 UTC, Atila Neves wrote: Then I tried only using dmd to compile and linking it myself. That worked, but the resulting binary crashed. After loading it up in gdb, it crashed in __tls_get_addr My guess would be that your system doesn't have __tls_get_addr, which is unique in that it is provided by the runtime linker from glibc. You may want to try out my Android patch for dmd, which doesn't use native TLS and doesn't rely on that function either: http://164.138.25.188/dmd/packed_tls_for_elf.patch You'll want to get rid of that last change to mars.c, substitute rt/sections_android.d for rt/sections_linux.d in druntime (don't forget to change the version (Android): inside that file to version (linux): also), and make sure you're using the default ld.bfd linker and not the gold linker. That might work for you. On Thursday, 9 October 2014 at 17:30:04 UTC, Kevin Lamonte wrote: I am experiencing a similar problem trying to build a static executable, exactly as described in https://issues.dlang.org/show_bug.cgi?id=12268 . I don't know if the root cause is a gcc issue or a phobos issue. Probably neither, probably a druntime issue, specifically the rt.sections_linux module's use of the __tls_get_addr function, which is called from the dynamic linker at runtime.
Re: ini library in OSX
On Thursday, 11 September 2014 at 10:49:48 UTC, Robert burner Schadek wrote: some self promo: http://code.dlang.org/packages/inifiled I would like an example?
[yajl-d] hello world with json arrays
Disclaimer: Don't eat me.
I was just wondering to those who are experienced in using yajl-d
to show me the proper implementation of using it with arrays.
So far this is what I understand from parsing Json Objects:
class random{
private string foo;
private string bar;
}
void main(string [] args){
random rand = decode!random(to!string(read(json_file.json)));
//do stuff
Now I'm just wondering how can I implement it with Json arrays.
Just some information or a place to start with is all I ask.
Thank you.
[Issue 13601] static if (__ctfe) should emit warning
https://issues.dlang.org/show_bug.cgi?id=13601 Ketmar Dark ket...@ketmar.no-ip.org changed: What|Removed |Added CC||ket...@ketmar.no-ip.org --- Comment #2 from Ketmar Dark ket...@ketmar.no-ip.org --- that's only if the author wants to go to mainline. me not. i don't care anymore if my code will lang into the oficial branch or not. it's just a patch for those who interested to patch dmd manually and either trust me or will write test themselves. --
[Issue 9294] foreach tuple unpack with opApply
https://issues.dlang.org/show_bug.cgi?id=9294 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from bearophile_h...@eml.cc --- This is a bad idea, it's better to add a general and safe syntax to unpack tuples in foreach. Closed. --
[Issue 4508] tuples should be indexable with foreach over range
https://issues.dlang.org/show_bug.cgi?id=4508
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
--- Comment #1 from bearophile_h...@eml.cc ---
I think this is a bad idea, in this form. So I suggest to close this issue.
I prefer this syntax much more:
static foreach(i; 0..tup.length) {
--
[Issue 9817] Syntax change for front tuple expansion in foreach
https://issues.dlang.org/show_bug.cgi?id=9817 --- Comment #1 from bearophile_h...@eml.cc --- The idea is to deprecate and then remove the current syntax (that is undocumented, see Issue 7361 ) and to replace it with a general syntax to unpack tuples. --
[Issue 4181] GDB prints wrong value of TLS variables
https://issues.dlang.org/show_bug.cgi?id=4181 --- Comment #24 from Martin Krejcirik m...@krej.cz --- Can you elaborate ? I've tried gdb 7.8.50.20141011-cvs on Debian x86_64 and it doesn't seem broken. --
[Issue 4181] GDB prints wrong value of TLS variables
https://issues.dlang.org/show_bug.cgi?id=4181 --- Comment #25 from Iain Buclaw ibuc...@gdcproject.org --- Can you elaborate ? I've tried gdb 7.8.50.20141011-cvs on Debian x86_64 and it doesn't seem broken. In response to my own Comment 10. --
[Issue 8578] std.demangle.demangle does not parse symbols that are type names
https://issues.dlang.org/show_bug.cgi?id=8578 --- Comment #1 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dlang.org https://github.com/D-Programming-Language/dlang.org/commit/ed1cfd04037ffe948120f0744b03aa5ae2cffdff Merge pull request #628 from Poita/bug8578 Add the Z 'type' to the mangling ABI to denote internal symbols. --
[Issue 8578] std.demangle.demangle does not parse symbols that are type names
https://issues.dlang.org/show_bug.cgi?id=8578 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/c51bd14c5bf617c36fe9b55c377a3045023879be Partial Fix Issue 8578 - Demangle special symbols https://github.com/D-Programming-Language/druntime/commit/83053e8fb5bd733a09442d1ed318efef15ed3b1b Merge pull request #725 from Poita/bug8578 Partial Fix Issue 8578 - Demangle special symbols (__init, __Class, etc --
[Issue 8578] std.demangle.demangle does not parse symbols that are type names
https://issues.dlang.org/show_bug.cgi?id=8578 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 12567] Modules can't be marked as deprecated
https://issues.dlang.org/show_bug.cgi?id=12567 --- Comment #8 from github-bugzi...@puremagic.com --- Commit pushed to 2.066 at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/194b4c216b828fff9430e0b1fcd4163761731330 Merge pull request #3907 from 9rnsr/fix12567 [enh] Issue 12567 - Modules can't be marked as deprecated Conflicts: src/hdrgen.c src/module.c --
[Issue 13504] ICE(backend/cgelem.c 2418) with -O -cov
https://issues.dlang.org/show_bug.cgi?id=13504 --- Comment #4 from github-bugzi...@puremagic.com --- Commit pushed to 2.066 at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/3005775b9c3562562128f3e54eff5a389d648124 Merge pull request #4047 from MartinNowak/fix13504 fix Issue 13504 - ICE(backend/cgelem.c 2418) with -O -cov --
[Issue 5713] Broken final switch on ints
https://issues.dlang.org/show_bug.cgi?id=5713
--- Comment #14 from bearophile_h...@eml.cc ---
Another simple case worth supporting:
void main() {
foreach (immutable i; 0 .. 3) {
final switch (i) {
case 0: break;
case 1: break;
case 2: break;
}
}
}
--
[Issue 13603] New: rdmd: if dmd.conf is missing, always rebuilds the target
https://issues.dlang.org/show_bug.cgi?id=13603 Issue ID: 13603 Summary: rdmd: if dmd.conf is missing, always rebuilds the target Product: D Version: D2 Hardware: x86 OS: Mac OS X Status: NEW Severity: normal Priority: P1 Component: tools Assignee: nob...@puremagic.com Reporter: and...@erdani.com When starting dmd is looking for its config file, e.g. /etc/dmd.conf. If that's missing, all works fine as far as dmd is concerned. However, rdmd considers the missing config file infinitely newer than the target and therefore always builds the target. --
[Issue 13603] rdmd: if dmd.conf is missing, always rebuilds the target
https://issues.dlang.org/show_bug.cgi?id=13603 --- Comment #1 from Andrei Alexandrescu and...@erdani.com --- https://github.com/D-Programming-Language/tools/pull/149 --
