Re: It's official: Sociomantic Labs has been acquired by dunnhumby Ltd
On 4/4/14, 2:06 AM, Don wrote: On Friday, 4 April 2014 at 02:38:58 UTC, Andrei Alexandrescu wrote: On 4/3/14, 7:04 AM, Don wrote: https://www.sociomantic.com/dunnhumby-acquires-sociomantic/ Congratulations to all involved! How will this impact the use of D at dunnhumby? Andrei This is going to be very big for D. Our technology will be used with their data and analysis (they're not a software company). Fantastic! Good luck, and hopefully you'll switch to D2 soon! :o) Andrei
Re: I'm joining Facebook
On 4/5/14, 3:13 AM, Peter Alexander wrote: Well, I didn't considering this D.announce worthy, but Andrei suggested I post the news. As the title suggests, after over 5 years in the games industry I've decided to shake things up a bit and join Facebook at their London office. Good luck, and ping me when you're around! -- Andrei
Re: Interesting rant about Scala's issues
On 4/6/14, 3:31 AM, Leandro Lucarella wrote: What I mean is the current semantics of enum are as they are for historical reasons, not because they make (more) sense (than other possibilities). You showed a lot of examples that makes sense only because you are used to the current semantics, not because they are the only option or the option that makes the most sense. Is it better to redesign enum semantics now? Probably not, but I'm just saying :) I fully agree. In my opinion, too, the enum design in D is suboptimal. Andrei
Re: Interesting rant about Scala's issues
On 4/6/2014 4:26 AM, bearophile wrote: So do you have an example of this risk? Algol is a rather famous one. A counterexample is Go, which has gotten a lot of traction with a simple syntax.
Re: Interesting rant about Scala's issues
On 4/6/2014 3:31 AM, Leandro Lucarella wrote: What I mean is the current semantics of enum are as they are for historical reasons, not because they make (more) sense (than other possibilities). You showed a lot of examples that makes sense only because you are used to the current semantics, not because they are the only option or the option that makes the most sense. I use enums a lot in D. I find they work very satisfactorily. The way they work was deliberately designed, not a historical accident.
Re: Interesting rant about Scala's issues
On Sunday, 6 April 2014 at 16:46:12 UTC, Andrei Alexandrescu wrote: On 4/6/14, 3:31 AM, Leandro Lucarella wrote: What I mean is the current semantics of enum are as they are for historical reasons, not because they make (more) sense (than other possibilities). You showed a lot of examples that makes sense only because you are used to the current semantics, not because they are the only option or the option that makes the most sense. Is it better to redesign enum semantics now? Probably not, but I'm just saying :) I fully agree. In my opinion, too, the enum design in D is suboptimal. Andrei Hey bearophile - I rest my case... -Eric
Re: Interesting rant about Scala's issues
On Sunday, 6 April 2014 at 11:26:41 UTC, bearophile wrote: Walter Bright: Having special syntax for everything makes the language unusable. While there are ways to reach excesses in every design direction, and make things unusable, the risk discussed here seems remote to me. Too much syntax diversity for almost the same things leads to a language that is harder to learn, but I think readability has little to do with special syntax, but rather how it is done and how frequently used those constructs are. You can get syntax diversity with simple formal syntax too. Lisp code often shows signs of this. D and C++ show signs of this with overuse of templates. I find template heavy code to be very poor in terms of readability and well designed special syntax would have been much better in terms of usability.
Re: Interesting rant about Scala's issues
Am 06.04.2014 19:54, schrieb Walter Bright: On 4/6/2014 4:26 AM, bearophile wrote: So do you have an example of this risk? Algol is a rather famous one. A counterexample is Go, which has gotten a lot of traction with a simple syntax. It has more to do with Google than with the language's design.
Re: Interesting rant about Scala's issues
On Sunday, 6 April 2014 at 17:52:19 UTC, Walter Bright wrote: On 4/6/2014 3:31 AM, Leandro Lucarella wrote: What I mean is the current semantics of enum are as they are for historical reasons, not because they make (more) sense (than other possibilities). You showed a lot of examples that makes sense only because you are used to the current semantics, not because they are the only option or the option that makes the most sense. I use enums a lot in D. I find they work very satisfactorily. The way they work was deliberately designed, not a historical accident. The fact that you are unaware of how it's properly done (hint: Pascal got right with 'set of enum' being distinct from 'enum') makes it a historical accident.
Re: Interesting rant about Scala's issues
On 4/6/2014 2:26 PM, Araq wrote: The fact that you are unaware of how it's properly done (hint: Pascal got right with 'set of enum' being distinct from 'enum') makes it a historical accident. I wrote a Pascal compiler before the C one.
Re: Interesting rant about Scala's issues
On Sunday, 6 April 2014 at 19:53:43 UTC, Paulo Pinto wrote: A counterexample is Go, which has gotten a lot of traction with a simple syntax. It has more to do with Google than with the language's design. That, and being perceived as a http-server-language and having standard libraries and a threading model geared towards web servers. In addition Go has managed to improve the C syntax by removing in-most-cases redundant syntax. Which is quite nice for readability, IMO.
Re: Interesting rant about Scala's issues
On 4/6/14, 10:52 AM, Walter Bright wrote: On 4/6/2014 3:31 AM, Leandro Lucarella wrote: What I mean is the current semantics of enum are as they are for historical reasons, not because they make (more) sense (than other possibilities). You showed a lot of examples that makes sense only because you are used to the current semantics, not because they are the only option or the option that makes the most sense. I use enums a lot in D. I find they work very satisfactorily. The way they work was deliberately designed, not a historical accident. Sorry, I think they ought to have been better. -- Andrei
DAuth - Authentication Utility Lib (initial release - v.0.5.1)
I've put up an initial release of DAuth: A simple-yet-flexible salted password hash based authentication utility lib for D. Before you get too excited, know that actual cryptographic algorithms are outside the scope of this lib. Instead, it uses any Phobos-compatible digests and random number generators. The upside: This makes DAuth fully extensible with plug-in cryptographic algorithms. The downside: It's currently limited to what little exists in Phobos right now (or in any Phobos-compatible third-party digests/RNGs I may not know about). Full overview, sample code and (ugly) API reference are at the project's GitHub homepage: https://github.com/Abscissa/DAuth (DUB project name dauth)
Re: Interesting rant about Scala's issues
Walter Bright: Having special syntax for everything makes the language unusable. While there are ways to reach excesses in every design direction, and make things unusable, the risk discussed here seems remote to me. So do you have an example of this risk? Or examples of languages that have fallen in this trap? Perhaps Ada? Bye, bearophile
Re: Interesting rant about Scala's issues
Walter Bright, el 5 de April a las 21:15 me escribiste: On 4/5/2014 6:28 PM, Leandro Lucarella wrote: Walter Bright, el 5 de April a las 11:04 me escribiste: Of course, you can hide all this in a template. Well, you can emulate enums as they are now with structs too, so that doesn't change anything in the argument about why to provide syntax sugar for one and not the other. The argument for syntactic sugar is it must show a very large benefit over using a template. Having special syntax for everything makes the language unusable. What I mean is the current semantics of enum are as they are for historical reasons, not because they make (more) sense (than other possibilities). You showed a lot of examples that makes sense only because you are used to the current semantics, not because they are the only option or the option that makes the most sense. Is it better to redesign enum semantics now? Probably not, but I'm just saying :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- El techo de mi cuarto lleno de cometas
Re: Interesting rant about Scala's issues
On 4/6/2014 4:17 PM, Andrei Alexandrescu wrote: On 4/6/14, 10:52 AM, Walter Bright wrote: I use enums a lot in D. I find they work very satisfactorily. The way they work was deliberately designed, not a historical accident. Sorry, I think they ought to have been better. -- Andrei Sorry, yer wrong!
Issues With dblog.aldacron.net
Anyone visiting my D blog (The One With D) or the Derelict forums recently will likely (hopefully!) have seen a malware warning. The problem is coming from the blog, where Google detected some script injection going on. Using cURL, I was able to see where it's happening, but I've been unable to determine how. Twice I've taken the only steps I can (given that I don't own the server) and gotten it cleared from the blacklist only for it to come back again. Now, I've turned to my hosting provider for help. I opened a support request and they agreed to look into it and see if they can find out what's going on. If they are able to resolve the problem, then I will get the site cleared again and all will, hopefully, be back to normal. If not, I'll either look at a new solution for the blog or just drop it entirely. The Derelict forums appear to be clean, but get the blacklist treatment since they fall under the dblog subdomain. Regardless of what happens with the blog, I'm planning to move the forums to another URL. For now, everything is in the hands of my web host. I'll update here when I have more information.
Re: A very fast linker to replace gcc's ld
On Saturday, 5 April 2014 at 23:56:49 UTC, John Colvin wrote: On Saturday, 5 April 2014 at 22:30:28 UTC, Joakim wrote: on Arch that's gold. it is? Not for me, unless I'm missing something. Sorry, I made a mistake. Dmd simply invokes the system C compiler and the linker that it uses. I set CC to clang and build dmd trunk with it. Clang uses gold, which is what led me to assume it was the default. But I just checked and gcc, the default C compiler on Arch, uses bfd ld, so it depends on what you use as your C compiler. On Sunday, 6 April 2014 at 00:15:21 UTC, Asman01 wrote: On Saturday, 5 April 2014 at 22:30:28 UTC, Joakim wrote: Dmd already uses whatever the system linker is and on Arch that's gold. The Android NDK also uses gold by default, though they also provide the original bfd ld and a newer llvm-based linker started by MediaTek, mclinker: https://code.google.com/p/mclinker/ Well, as far I know, it does invoke gcc and gcc does use the ld. I see this with -v flag. What am I missing? I'll check out this llvm-based linker. If it's the linker which I've hear they are planing to replace gcc ld it's a big step. See above, I was wrong. As for llvm-based linkers, there are a couple going around. The one you're probably thinking of is lld: http://lld.llvm.org/
Re: Poll - How long have you been in D?
On 2014-04-05 21:06, Nick Sabalausky wrote: On 4/4/2014 8:51 PM, Simen Kjærås wrote: On 2014-04-04 02:10, dnewbie wrote: Please vote now! http://www.easypolls.net/poll.html?p=533e10e4e4b0edddf89898c5 See also results from previous years: - http://d.darktech.org/2012.png - http://d.darktech.org/2013.png These things make me feel old. Looking at the old changelog[0], I can remember changes all the way back to 0.91. That's not quite ten years yet, but give it a month and a half... [0]: http://www.digitalmars.com/d/1.0/changelog1.html#new091 -- Simen I remember watching the changelog and wondering if the next version after v0.99 was going to be v1.0. Yeah, I'd forgotten about that, but now you mention it, I think even there was a discussion on that topic. -- Simen
Re: Reviving YAGE
On 4/4/14, Ryan Voots simcop2...@simcop2387.info wrote: I started updating things so that the demos build seperately with dub but can't confirm anything about them building as expected yet. Yeah I've tried running dub --config=demo1 but I get back: Error executing command run: Unknown build configuration: demo1 I think subPackages should be renamed to configurations in the dub json file? Either way building tango seems to fail, but I don't know why, all I get back are warnings. I've tried with various recent versions of DMD.
Re: Dream Feature Regarding Default Arguments
On Sunday, 6 April 2014 at 01:26:21 UTC, Nick Sabalausky wrote:
Such a big mess for such a trivially simple API:
func( [optionalFoo], [optionalBar] )
It would be *fantastic* if D recognized the disambiguation of
using incompatible types and permitted this:
interface Foo {}
interface Bar {}
class FooBar : Foo, Bar {}
void func(Foo foo=someFoo, Bar bar=someBar) {...}
func(myFoo); // Unambiguous, OK
func(myBar); // Unambiguous, OK
func(myFooBar); // Ambiguous, ERROR
Wouldn't it be better to have named parameters like in Python or
C#? That way you could call the function like:
func(foo=myFoo) or func(bar=myBar) or func(foo=myFoo, bar=myBar)
and there would be no ambiguity.
How to tell if the GC is running?
I'm writing a logger/tracer that emits a line for every function entry/exit. It naturally makes use of the GC, as it manipulates strings (and calls to!string on arguments, etc). Traced functions may be called normally, but sometimes they are called from a destructor (during a collection). When the latter happens, it gets to my tracer's code, which tries to allocate memory, and dies with a SEGFAULT. It seems that it tried to raise an exception but failed: Program received signal SIGSEGV, Segmentation fault. 0x007f406d in _d_throwc () (gdb) bt #0 0x007f406d in _d_throwc () #1 0x00835ec8 in onInvalidMemoryOperationError () #2 0x00831296 in gc.gc.GC.mallocNoSync() () #3 0x00831207 in gc.gc.GC.malloc() () #4 0x007f2578 in gc_qalloc () #5 0x007f507a in _d_newarrayiT () #6 0x00546385 in std.array.__T9replicateTAyaZ.replicate() (n=2, s=...) at /usr/include/dmd/phobos/std/array.d:1313 #7 0x0067a3a7 in foo.runtime.tracing.__T9enterFuncTkZ.enterFunc() (_param_1=0, funcName=...) at ... ... #17 0x0055d9fd in main () First of all, the SEGFAULT seems to be a bug in the GC itself which probably deserves a ticket. I'd settle with simply disabling my tracer during GC, but there doesn't seem to be any way to tell if I'm in a collection or not. This is what I'm after: https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L440 Any help would be appreciated. -tomer
Re: Recommendation: Compile DMD with More Warnings
On 4/6/14, 2:49 AM, Nordlöw wrote: I recommend the lead developers of DMD to look into activating more warnings in the dmd/src/posix.mak. GCC 4.8.2 and especially Clang 3.4, both prepackage on Ubuntu 13.10/14.04 give a *lot* of warnings that seems to indicate potential bugs in the DMD source code. This setting gives useful warnings and at the same time avoid the annoying ones WARNINGS=-Wall -Wextra -Wno-deprecated -Wstrict-aliasing -Wno-unused-parameter -Wno-unused-variable -Wunused-function -Wno-unused-label -Wno-unknown-pragmas -Wno-sign-compare -Wno-overloaded-virtual -Wno-missing-braces -Wno-missing-field-initializers -Wno-logical-op-parentheses For example there a *lot* of -Wsometimes-uninitialized which IMHO seems like the most dangereous ones. This one is however Clang specific but I have not had any problems running a Clang compiled version of DMD. Further Clang compiles DMD about twices as fast as GCC. Good work developers on disabling use of STL in DMD! I can do a pull request if desired for the posix.make update if wanted. I'm not a regular core dmd dev but I'm already seeing warnings with clang on OSX and I think fixing them would be beneficial. I'd support a pull request. In all likelihood it would also need to fix the warnings themselves, so you may want to enable only a few warnings at a time so as to keep the pull request sizes manageable. -- Andrei
Re: How to tell if the GC is running?
Please post more of the stack trace, it looks like you're allocating while it is running the destructors / finalization (#11408.) https://d.puremagic.com/issues/show_bug.cgi?id=11408
Re: Recommendation: Compile DMD with More Warnings
On Sunday, 6 April 2014 at 16:27:50 UTC, Andrei Alexandrescu wrote: On 4/6/14, 2:49 AM, Nordlöw wrote: I recommend the lead developers of DMD to look into activating more warnings in the dmd/src/posix.mak. GCC 4.8.2 and especially Clang 3.4, both prepackage on Ubuntu 13.10/14.04 give a *lot* of warnings that seems to indicate potential bugs in the DMD source code. This setting gives useful warnings and at the same time avoid the annoying ones WARNINGS=-Wall -Wextra -Wno-deprecated -Wstrict-aliasing -Wno-unused-parameter -Wno-unused-variable -Wunused-function -Wno-unused-label -Wno-unknown-pragmas -Wno-sign-compare -Wno-overloaded-virtual -Wno-missing-braces -Wno-missing-field-initializers -Wno-logical-op-parentheses For example there a *lot* of -Wsometimes-uninitialized which IMHO seems like the most dangereous ones. This one is however Clang specific but I have not had any problems running a Clang compiled version of DMD. Further Clang compiles DMD about twices as fast as GCC. Good work developers on disabling use of STL in DMD! I can do a pull request if desired for the posix.make update if wanted. I'm not a regular core dmd dev but I'm already seeing warnings with clang on OSX and I think fixing them would be beneficial. I'd support a pull request. In all likelihood it would also need to fix the warnings themselves, so you may want to enable only a few warnings at a time so as to keep the pull request sizes manageable. -- Andrei If you want, I have the results of a static analysis of DMD that I could post, as processed in 23 hours and 58 minutes by Intel's C compiler, using 10gb of RAM the entire time. If I can figure out how to have it not skip any methods (there were still a significant number that it didn't analyze due to complexity limits) I'll run it again and post the full results. In my basic look over the results, there were a decent number of them that may actually be bugs. (buffer overruns, and even a few instances of accessing memory after it had been freed) On the topic of actual warnings, I would be careful with them, because compiling DMD with MSVC with the maximum warning level (essentially -Wall), it produces 150k lines of output, most of them about stuff being inlined, and quite a bit of other stuff that you quite simply, don't care about.
Re: Poll - How long have you been in D?
On Saturday, 5 April 2014 at 21:06:14 UTC, Nick Sabalausky wrote: On 4/4/2014 8:51 PM, Simen Kjærås wrote: On 2014-04-04 02:10, dnewbie wrote: I remember watching the changelog and wondering if the next version after v0.99 was going to be v1.0. Yes, yes! I remember that it was some discussion about the position of planet Mars or something! Everybody was disappointed to see 0.100... :(
Re: Recommendation: Compile DMD with More Warnings
Orvid King: On the topic of actual warnings, I would be careful with them, because compiling DMD with MSVC with the maximum warning level (essentially -Wall), it produces 150k lines of output, most of them about stuff being inlined, and quite a bit of other stuff that you quite simply, don't care about. I'd like dmd/ldc2 compilers to compile with warnings active on default, plus to have a switch to disable them. Bye, bearophile
Re: Specifying C++ symbols in C++ namespaces
On 4/6/2014 2:56 AM, Marc Schütz schue...@gmx.net wrote: And wouldn't it clash with D's std package? Yes. But D has numerous methods of disambiguation.
Re: mysql-native: newbie questions
On Tuesday, 18 February 2014 at 01:04:10 UTC, simendsjo wrote:
.. preamble
The rejectedsoftware repo is based on an earlier version of
mine which in turn is based on the original by Steve Teale
(britseye).
(... lots of compiler errors ...)
What you are seeing are missing dependencies. DMD won't figure
out dependencies you are using without you specifying it in
detail.
You should be using dub directly rather than dmd. Specify your
dependencies in the package.json file, and use dub run to run
the application.
I created a video tutorial a couple of days ago that might help
you get started using dub: http://youtu.be/8TV9ZZteYEU
Following Nick advice I've completed my project by using dmd and
specifying dependencies manually, it's a tiny project after all.
Everything seems to work fine. So...
After seen your tutorials (at youtube, by the way very useful
indeed) I'm now trying to port my code to use dub, again I have a
doubt.
In my code, at 'dub.json' file I've wrote:
dependencies: {
mysql-native : =0.0.12
}
When trying to build, I've got an error from mysql-native code:
$HOME/.dub/packages/mysql-native-0.0.12/source/mysql/connection.d(333):
Error: cannot implicitly convert expression (t % 24) of type int
to ubyte
But this error seems to be already solved in github repo for
mysql-native.
I manually copy the files from my cloned copy of mysql-native into
$HOME/.dub/packages/mysql-native-0.0.12/source/mysql/
and now everything works fine.
Am I making an error when specifying my dependencies??
Re: mysql-native: newbie questions
On 02/18/2014 01:29 PM, simendsjo wrote: On Tuesday, 18 February 201hanks for the nod. It's good to see that all those hours were not wast4 at 11:56:23 UTC, Steve Teale wrote: On Tuesday, 18 February 2014 at 01:04:10 UTC, simendsjo wrote: The rejectedsoftware repo is based on an earlier version of mine which in turn is based on the original by Steve Teale (britseye). Thanks for the nod. It's good to see that all those hours were not wasted. And this is a reminder that I should finish the rewrite to not let all those hours go to waste :) The code everyone uses is pretty much exactly your original code with many small refactorings like remove magic constants. So big thanks for doing all that work! Please do, a concise and performant ORM (Datamapper) for MySQL is a huge selling point. I remember some good ideas in http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/4526/.
Re: Recommendation: Compile DMD with More Warnings
On Sunday, 6 April 2014 at 17:39:38 UTC, bearophile wrote: Orvid King: On the topic of actual warnings, I would be careful with them, because compiling DMD with MSVC with the maximum warning level (essentially -Wall), it produces 150k lines of output, most of them about stuff being inlined, and quite a bit of other stuff that you quite simply, don't care about. I'd like dmd/ldc2 compilers to compile with warnings active on default, plus to have a switch to disable them. Bye, bearophile Could you give me a priority list of the typical warning types sorted an descending severity? /Per
Re: Specifying C++ symbols in C++ namespaces
On Saturday, 5 April 2014 at 23:26:30 UTC, Walter Bright wrote: I feel that C++ messed up namespace design because: 1. namespaces are not closed 2. they have no relationship with modules Namespaces are not as powerful as they could have been, but being able to add symbols to an external scope (like classes) is very useful if done right (e.g. cross-cutting enhancements, adding members to external classes like saveyourself, printyourself). which has wound up forcing the addition of Yet Another Design when imports and modules are added to C++. Unfortunately that seems to be years into the future? Although clang has begun implementing something: http://clang.llvm.org/docs/Modules.html I've got at feeling that if clang gets something working it will become a de-facto standard due to demand.
Re: Poll - How long have you been in D?
On 4/4/14, dnewbie r...@myopera.com wrote: Please vote now! http://www.easypolls.net/poll.html?p=533e10e4e4b0edddf89898c5 I remember trying D1 many years ago, but I got put off by the whole choose tango or phobos thing back then. I'm glad to see those days are behind us.
Re: Recommendation: Compile DMD with More Warnings
On Sunday, 6 April 2014 at 17:39:38 UTC, bearophile wrote: I'd like dmd/ldc2 compilers to compile with warnings active on default, plus to have a switch to disable them. LDC is actually built with -Wall -Wextra by default. The warnings are disabled for the DMD source files though, as leaving them on just floods the console output, making actual issues much harder to see. We will have to look into additionally adding warning push/pop pragmas around the frontend includes in the proper LDC source files though. Currently, we get quite a bit of log spam from them, and some of them are unlikely to be addressed in the upstream source. David
Re: Specifying C++ symbols in C++ namespaces
On 4/6/2014 12:39 PM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: On Saturday, 5 April 2014 at 23:26:30 UTC, Walter Bright wrote: I feel that C++ messed up namespace design because: 1. namespaces are not closed 2. they have no relationship with modules Namespaces are not as powerful as they could have been, but being able to add symbols to an external scope (like classes) is very useful if done right (e.g. cross-cutting enhancements, adding members to external classes like saveyourself, printyourself). It's seriously wrong to allow such. It makes a larger code base nearly impossible to reliably reason about, leading one to rely on conventions like don't add stuff to namespaces. D has closed scopes, and members can be added to external classes just fine, using CTFE.
Re: Specifying C++ symbols in C++ namespaces
On Sunday, 6 April 2014 at 20:17:09 UTC, Walter Bright wrote: It's seriously wrong to allow such. It makes a larger code base nearly impossible to reliably reason about, leading one to rely on conventions like don't add stuff to namespaces. Depends on how it is done. For BETA, there was a seperate fragment system that allowed AST specified extension points. This system was used for both extensions and for encapsulation/API definition. You basically defined slots in the syntax three where code could be injected (following the grammar of the slot) and what should be hidden etc. It was simplistic elegance IMO: http://www.cs.au.dk/~beta/Manuals/latest/beta/fragment.html The weakness was that they didn't allow for dynamic dispatch (required static resolution), but that was an implementation issue, I think.
Re: Specifying C++ symbols in C++ namespaces
Btw, cross-cutting programming is indeed meant to cater for programming in the large: http://en.wikipedia.org/wiki/Aspect-oriented_programming
Re: Recommendation: Compile DMD with More Warnings
Nordlöw: Could you give me a priority list of the typical warning types sorted an descending severity? I can't, I don't understand your question, and I don't understand why you want such list. Bye, bearophile
Re: mysql-native: newbie questions
On 4/6/2014 3:05 PM, salvari wrote:
Following Nick advice I've completed my project by using dmd and
specifying dependencies manually, it's a tiny project after all.
Everything seems to work fine. So...
After seen your tutorials (at youtube, by the way very useful indeed)
I'm now trying to port my code to use dub, again I have a doubt.
In my code, at 'dub.json' file I've wrote:
dependencies: {
mysql-native : =0.0.12
}
When trying to build, I've got an error from mysql-native code:
$HOME/.dub/packages/mysql-native-0.0.12/source/mysql/connection.d(333):
Error: cannot implicitly convert expression (t % 24) of type int to ubyte
But this error seems to be already solved in github repo for mysql-native.
I manually copy the files from my cloned copy of mysql-native into
$HOME/.dub/packages/mysql-native-0.0.12/source/mysql/
and now everything works fine.
Am I making an error when specifying my dependencies??
IMO, DUB really needs a way to specify a specific Git commit hash:
https://github.com/rejectedsoftware/dub/issues/51
I've tagged the current mysql-native HEAD as v0.0.13, so as soon as the
dub repository sees the update (check
http://code.dlang.org/packages/mysql-native ), you should be able to
just do: mysql-native : =0.0.13
Re: Specifying C++ symbols in C++ namespaces
On Sunday, 6 April 2014 at 20:17:09 UTC, Walter Bright wrote:
D has closed scopes, and members can be added to external
classes just fine, using CTFE.
You mean UFCS? As in, for example, front for arrays? It doesn't
work as well as advertised though. The issue is that the added
members are only visible if the *called* code knows to import the
*caller* code. This breaks as soon as you leave your own internal
ecosystem.
//
import a;
struct S //Some object
{
}
//Extend to make it a range.
bool empty(S);
int front(S);
void popFront(S);
//Try it.
void main()
{
S s;
foreach(e; s) //Error: invalid foreach aggregate s
writeln(s);
s.array(); //Error: template std.range.take cannot...
a.foo(s); //Error: no property 'popFront' for type 'S'
}
//
module a;
void foo(T)(T t)
{
t.popFront();
}
//
Well that horribly fails.
Because when calling a template, you are only importing the
passed argument, but not his ecosystem with it. The only way in D
to really extend an existing object, is to wrap it into a new
object. And even then, the wrapping is limited, because you can't
orthogonally wrap (eg the wrapping linearly stacks, whereas UCFS
*could* add two completely independent functionalities). Not to
mention issues with code bloat...
C++'s namespaces have their flaws, but they *are* scalable in a
way D's modules aren't, thanks to Koenig Lookup.
Re: Dream Feature Regarding Default Arguments
On 4/6/2014 10:47 AM, JN wrote: Wouldn't it be better to have named parameters like in Python or C#? That way you could call the function like: func(foo=myFoo) or func(bar=myBar) or func(foo=myFoo, bar=myBar) and there would be no ambiguity. Named parameters would be a good compliment to this (and I have always wanted named parameters in D), but even with them it would still be nice to be able have neat-n-tidy implementations of func([foo],[bar]) APIs that don't require the use of named params.
Re: How to tell if the GC is running?
On Sunday, 6 April 2014 at 16:34:02 UTC, safety0ff wrote: Please post more of the stack trace, it looks like you're allocating while it is running the destructors / finalization (#11408.) https://d.puremagic.com/issues/show_bug.cgi?id=11408 Yes, I know I'm allocating while the GC is collecting. I'm asking how to avoid this situation -- is there some way to tell that the GC is running? -tomer
Re: Recommendation: Compile DMD with More Warnings
I can't, I don't understand your question, and I don't understand why you want such list. Just so I know where I should begin digging ;)
Re: Specifying C++ symbols in C++ namespaces
On 4/6/2014 2:00 PM, monarch_dodra wrote:
On Sunday, 6 April 2014 at 20:17:09 UTC, Walter Bright wrote:
D has closed scopes, and members can be added to external classes just fine,
using CTFE.
You mean UFCS?
Yes, my mistake.
As in, for example, front for arrays? It doesn't work as well
as advertised though. The issue is that the added members are only visible if
the *called* code knows to import the *caller* code.
That's a feature of a modular system, not a bug. D does not have a global name
space, on purpose.
This breaks as soon as you
leave your own internal ecosystem.
//
import a;
struct S //Some object
{
}
//Extend to make it a range.
bool empty(S);
int front(S);
void popFront(S);
//Try it.
void main()
{
S s;
foreach(e; s) //Error: invalid foreach aggregate s
writeln(s);
s.array(); //Error: template std.range.take cannot...
a.foo(s); //Error: no property 'popFront' for type 'S'
}
//
module a;
void foo(T)(T t)
{
t.popFront();
}
//
Well that horribly fails.
That's based on a misunderstanding of how scoped lookup works in D, and how to
use it properly. In the particular instance above, there is simply no reason to
not put front() as a member of S, since they are in the same module.
Because when calling a template, you are only importing the passed argument, but
not his ecosystem with it. The only way in D to really extend an existing
object, is to wrap it into a new object. And even then, the wrapping is limited,
because you can't orthogonally wrap (eg the wrapping linearly stacks, whereas
UCFS *could* add two completely independent functionalities). Not to mention
issues with code bloat...
You're right in that if you try to do things the C++ way in D, things won't work
out so well. D can do all these things, but they are done in a different way - a
way that is much more robust.
The fault in the C++ method of extending namespaces is that two independently
developed modules had better not extend the same namespace with the same names.
You will not necessarily get a compiler error from violating this - code may
just wind up calling the wrong overload. I.e. it does not scale.
C++'s namespaces have their flaws, but they *are* scalable in a way D's modules
aren't, thanks to Koenig Lookup.
I've never seen anyone defend Koenig lookup as anything but a hack before :-)
Re: mysql-native: newbie questions
On 04/06/2014 09:05 PM, salvari wrote:
In my code, at 'dub.json' file I've wrote:
dependencies: {
mysql-native : =0.0.12
}
When trying to build, I've got an error from mysql-native code:
$HOME/.dub/packages/mysql-native-0.0.12/source/mysql/connection.d(333):
Error: cannot implicitly convert expression (t % 24) of type int to ubyte
But this error seems to be already solved in github repo for mysql-native.
You can use ~master to get the latest version of a package.
http://code.dlang.org/package-format#version-specs
Re: From next C#
On Saturday, 5 April 2014 at 21:17:53 UTC, bearophile wrote:
Upcoming features in C# (the text contains some extraneous
chars, like in the 0b0010\_1110; literal):
https://gist.github.com/anonymous/9997622
Declaring out arguments at the calling point is nice, but
returning a tuple as in Python/Haskell is better:
GetCoordinates(out var x, out var y);
Returning a tuple is nice, but isn't the D way to return an
anonymous struct(well, yes, it has a name, but that name is
only defined inside the function that returns it...)?
At any rate, I think that C# feature will be more useful with
control structures. Imagine using `TryParse` in the condition
expression of an `if` statement, declaring there an out parameter
that'll only be accessible in the scope of the `if` statement.
It's also nice the syntax to define struct/class members with
the same name as class arguments as in Scala/TypeScript. But in
D you can't use this syntax because those are template
arguments:
class Customer(string first, string last) {
A solution is to use two groups, as for functions (but the
default is the opposite for functions):
class Customer()(private const string first, private const
string last) {
Instead of this confusing syntax, how about making them regular
fields and marking them with a attribute that'll make the
compiler add them to the default constructor:
class Customer{
@default string first;
@default string last;
}
Re: Dream Feature Regarding Default Arguments
On Sunday, 6 April 2014 at 21:06:44 UTC, Nick Sabalausky wrote: On 4/6/2014 10:47 AM, JN wrote: Wouldn't it be better to have named parameters like in Python or C#? That way you could call the function like: func(foo=myFoo) or func(bar=myBar) or func(foo=myFoo, bar=myBar) and there would be no ambiguity. Named parameters would be a good compliment to this (and I have always wanted named parameters in D), but even with them it would still be nice to be able have neat-n-tidy implementations of func([foo],[bar]) APIs that don't require the use of named params. How bout func(,,x,,y) or func(default, default, x, default, default, y)? where default is a keyword that substitutes the default value.
Re: How to tell if the GC is running?
On 2014-04-06 5:20 PM, Tomer Filiba wrote: On Sunday, 6 April 2014 at 16:34:02 UTC, safety0ff wrote: Please post more of the stack trace, it looks like you're allocating while it is running the destructors / finalization (#11408.) https://d.puremagic.com/issues/show_bug.cgi?id=11408 Yes, I know I'm allocating while the GC is collecting. I'm asking how to avoid this situation -- is there some way to tell that the GC is running? -tomer If the GC is running you get a stack trace with fullcollect() like this: cache-d_d.exe!gc@gc@Gcx@mark(void * this, void * nRecurse, int ptop) Line 2266C++ cache-d_d.exe!gc@gc@Gcx@mark(void * this, void * ptop) Line 2249 C++ cache-d_d.exe!gc@gc@Gcx@fullcollect() Line 2454C++ cache-d_d.exe!gc@gc@GC@mallocNoSync(unsigned int this, unsigned int alloc_size, unsigned int * alloc_size) Line 458C++ cache-d_d.exe!gc@gc@GC@malloc(unsigned int this, unsigned int alloc_size, unsigned int * bits) Line 413C++
Re: Specifying C++ symbols in C++ namespaces
On 2014-04-05 22:42, Walter Bright wrote: 2. C++ namespaces are very low hanging fruit, with a significant payoff. It's worthwhile. I think it's very low hanging fruit to add support for basic C++ namespaces. Support for basically just set the mangled name in a somewhat nice way, a pragma for example. If we're talking about adding something more advanced like :: or extern (C++) template which my affect the current name look up rules then I don't think that's so low hanging fruit anymore. -- /Jacob Carlborg
Typo in Types page
In the page http://dlang.org/type.html I believe there is a typo stating that bool is 1 byte instead of 1 bit.
Re: Specifying C++ symbols in C++ namespaces
I think it's very low hanging fruit to add support for basic C++ namespaces. Support for basically just set the mangled name in a somewhat nice way, a pragma for example. I think it is more important to think in term of strategic positions than whether it takes 1 or 2 weeks to implement a feature. Assumption: It is desirable to make the eco system more attractive for commercial projects. Key requirements: - Long term stability of the dev environment. - Access to mature libraries with significant backing (basically C/C++ libraries). - Easy integration with existing technology and systems (basically C/C++). - No lock-in (basically C/C++ interop). - Predictable dev environment that enables precise cost estimates. - Lowering costs/faster development than the alternatives (more convinient than C/C++) If you cannot assume that you can utilize a C++ library from D or if you have to assume that using a C++ library might incur a significant interfacing overhead (in terms of programmer's time) then D looks like a more risky proposition. The key difference between a commercial project and a hobby project is that the hobby project can fully adapt the requirements to the dev environment. A hobbyist game project can settle for a less capable physics engine or create a custom one, for fun. A commercial project will view that as costs that cut into profit margins and a potential source of failure in the market. That's a good reason to go with C++ instead of D. From a strategic point of view it is important to fully support those features you claim to support. If you can claim that interfacing with C++, except for templates, is easy, then you communicate that it is relatively easy to assess project costs. If you only claim that it is possible to interface with some of C++, but that it is kind of difficult under certain vaguely specified circumstances then I think you should wait until you have a better solution. What you absolutely don't want is to trick people into thinking that interfacing with C++ is easy, if it isn't, and have them discover that they are better off dumping D and doing it all over in C++.
Recommendation: Compile DMD with More Warnings
I recommend the lead developers of DMD to look into activating more warnings in the dmd/src/posix.mak. GCC 4.8.2 and especially Clang 3.4, both prepackage on Ubuntu 13.10/14.04 give a *lot* of warnings that seems to indicate potential bugs in the DMD source code. This setting gives useful warnings and at the same time avoid the annoying ones WARNINGS=-Wall -Wextra -Wno-deprecated -Wstrict-aliasing -Wno-unused-parameter -Wno-unused-variable -Wunused-function -Wno-unused-label -Wno-unknown-pragmas -Wno-sign-compare -Wno-overloaded-virtual -Wno-missing-braces -Wno-missing-field-initializers -Wno-logical-op-parentheses For example there a *lot* of -Wsometimes-uninitialized which IMHO seems like the most dangereous ones. This one is however Clang specific but I have not had any problems running a Clang compiled version of DMD. Further Clang compiles DMD about twices as fast as GCC. Good work developers on disabling use of STL in DMD! I can do a pull request if desired for the posix.make update if wanted.
Re: Specifying C++ symbols in C++ namespaces
On Sunday, 6 April 2014 at 02:33:38 UTC, Walter Bright wrote: On 4/5/2014 6:26 PM, Michel Fortin wrote: What if you also have a C++ foo at global scope? It'll work exactly the same as import does. module cpptest; extern (C++) void foo(); extern (C++, namespace = A) void foo(); foo(); // ambiguous A.foo(); // works .foo(); // works? Yes. cpptest.foo(); // works? Yes. Does these two last lines make sense? Just as much sense as: module bar; void foo(); .foo(); // works bar.foo(); // works Namespace lookup rules would be exactly the same as for imports and mixin templates. My main reservation against the new suggestion is that one would be forced to open a new nested namespace even when it's detrimental, because in some cases the namespace structure is already reflected in the filesystem(just like for D:s module system). I can't assess how widespread this is globally, but at least some high-quality projects already have guidelines to use file/namespace mappings. A random example from boost: boost::asio::ip::multicast boost/asio/ip/multicast.hpp One can of course workaround this issue with an extra alias for every imported symbol, or use compile-time reflection to auto-generate all alias statements... (or heaven forbid, put entire boost in one file ;)) I assume the namespace = xxx syntax is some sort of named parameter, would it be possible to add another similar param, which only changes mangling and doesn't actually create a new scope?
Re: Typo in Types page
On Sunday, 6 April 2014 at 09:30:47 UTC, Gustavo wrote: In the page http://dlang.org/type.html I believe there is a typo stating that bool is 1 byte instead of 1 bit. I don't think it's a typo. Memory is typically byte-addressable and thus data types are either a byte or larger. Having a data type smaller than a byte means reading or writing to that variable will have to involve bit-twiddling operations which can make operations more expensive. There are bitfields[1] and BitArrays[2] if you really need control of a data type on the bit level. [1]: http://dlang.org/phobos/std_bitmanip.html#.bitfields [2]: http://dlang.org/library/std/bitmanip/BitArray.html
Re: Typo in Types page
On Sunday, 6 April 2014 at 09:30:47 UTC, Gustavo wrote: In the page http://dlang.org/type.html I believe there is a typo stating that bool is 1 byte instead of 1 bit. While a boolean is by definition a single bit, it is represented by programming languages as a byte for various reasons (including performance, data layout, and interfacing). You can verify that this is the case: http://dpaste.dzfl.pl/8129625be797 As far as I know, this is true for most, if not all, native programming languages. To actually store a value as a single bit, you will have to use bit manipulation.
Re: Dream Feature Regarding Default Arguments
On Sunday, 6 April 2014 at 01:33:36 UTC, Nick Sabalausky wrote:
On 4/5/2014 9:26 PM, Nick Sabalausky wrote:
It would be *fantastic* if D recognized the disambiguation of
using
incompatible types and permitted this:
interface Foo {}
interface Bar {}
class FooBar : Foo, Bar {}
void func(Foo foo=someFoo, Bar bar=someBar) {...}
func(myFoo); // Unambiguous, OK
func(myBar); // Unambiguous, OK
func(myFooBar); // Ambiguous, ERROR
Actually, that last line should be:
func(myFooBar); // Unambiguous, this is still interpreted
as the first parameter (with the second parameter left as
default) just as it is right now.
I think D is actually one of the better languages around in terms
of factoring this sort of thing out. Here's an example argument
parser that lets you define pairs of optional arguments:
http://pastebin.com/RaNfwH6X. It can be extended to allow
n-tuples of optional arguments.
Argument parsing is encapsulated so writers only have to declare
one function template, with a constraint that clearly expresses
intent:
void func(Args...)(Args args)
if (Pattern!(bool, AnyOf!(int, string)).matches!Args)
{
alias Parser = Pattern!(bool, AnyOf!(int, string));
auto parsedArgs = Parser.parse(tuple(args), tuple(false, 0,
0));
writeln(parsedArgs);
}
void main()
{
func(true); // true, 0, 0
func(true, 1); // true, 1, 0
func(true, 1);// true, 0, 1
func(true, 1, 1); // true, 1, 1
}
Re: Specifying C++ symbols in C++ namespaces
On Saturday, 5 April 2014 at 21:43:03 UTC, Walter Bright wrote:
On 4/5/2014 2:31 PM, Tove wrote:
How could this common pattern look?
std::string
boost::fun(std::string arg)
alias cpp= extern (C++, namespace = std);
alias boost = extern (C++, namespace = boost);
cpp.string
boost.fun(cpp.string arg)
?
extern (C++, namespace = std) {
struct string { ... }
}
extern (C++, namespace = boost) {
void fun(std.string arg);
}
What would std be here from D's point of view? A module? Or a new
kind of symbol?
And wouldn't it clash with D's std package?
Re: 2.065 compiler problem
Ty, you made my day.
Re: mysql-native: newbie questions
On Sunday, 6 April 2014 at 22:37:08 UTC, Martin Nowak wrote: You can use ~master to get the latest version of a package. http://code.dlang.org/package-format#version-specs I thought that was deprecated (according to the format description at code.dlang.org)
Re: Dream Feature Regarding Default Arguments
On Sunday, 6 April 2014 at 23:08:10 UTC, Frustrated wrote: How bout func(,,x,,y) That isn't too bad (VB6 had it IIRC), but the caller still has to care about the order of the params they're ignoring. Ie if you have func([foo],[bar]) then you can't just pass in a one-param foo-only or bar-only without worrying about the unimportant detail of the arbitrary ordering (unlike with the overload approach).
Re: Specifying C++ symbols in C++ namespaces
On 2014-04-06 19:39:31 +, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com said: Unfortunately that seems to be years into the future? Although clang has begun implementing something: http://clang.llvm.org/docs/Modules.html I've got at feeling that if clang gets something working it will become a de-facto standard due to demand. Modules are already in use on OS X for some system frameworks. It can result in slightly improved compile times. It has been enabled by default for new Xcode projects for some time. With modules enabled, clang interpret #includes as module imports for system frameworks having a module map. It's so transparent you probably won't notice anything has changed. The only thing that really changes with modules is you don't have access to symbols you don't have imported yourself. D already works like that. I think D can ignore those modules, just like it ignores header files. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: Poll - How long have you been in D?
On 4 April 2014 12:10, dnewbie r...@myopera.com wrote: Please vote now! http://www.easypolls.net/poll.html?p=533e10e4e4b0edddf89898c5 See also results from previous years: - http://d.darktech.org/2012.png - http://d.darktech.org/2013.png These results are a bit disappointing. Ideally you'd see a massive bias towards new users, but we see the opposite :( Perhaps this poll isn't public enough? On reddit and stuff?
Re: Poll - How long have you been in D?
On Monday, 7 April 2014 at 02:00:37 UTC, Manu wrote: On 4 April 2014 12:10, dnewbie r...@myopera.com wrote: Please vote now! http://www.easypolls.net/poll.html?p=533e10e4e4b0edddf89898c5 See also results from previous years: - http://d.darktech.org/2012.png - http://d.darktech.org/2013.png These results are a bit disappointing. Ideally you'd see a massive bias towards new users, but we see the opposite :( Perhaps this poll isn't public enough? On reddit and stuff? I don't imagine many new users read these forums frequently, and this is the only place it's been posted AFAIK. Also, that could be interpreted as users like D enough that they continue to use it for a long time, also nice. :P
Re: Poll - How long have you been in D?
On 7 April 2014 12:34, Kapps opantm2+s...@gmail.com wrote: On Monday, 7 April 2014 at 02:00:37 UTC, Manu wrote: On 4 April 2014 12:10, dnewbie r...@myopera.com wrote: Please vote now! http://www.easypolls.net/poll.html?p=533e10e4e4b0edddf89898c5 See also results from previous years: - http://d.darktech.org/2012.png - http://d.darktech.org/2013.png These results are a bit disappointing. Ideally you'd see a massive bias towards new users, but we see the opposite :( Perhaps this poll isn't public enough? On reddit and stuff? I don't imagine many new users read these forums frequently, and this is the only place it's been posted AFAIK. Also, that could be interpreted as users like D enough that they continue to use it for a long time, also nice. :P If you look at the past polls, the new users appear to be declining. I agree, most newbies probably don't get involved in the dev forum, hence suggesting it should probably be posted in some other places too.
Re: Recommendation: Compile DMD with More Warnings
On 6 Apr 2014 21:15, David Nadlinger c...@klickverbot.at wrote: On Sunday, 6 April 2014 at 17:39:38 UTC, bearophile wrote: I'd like dmd/ldc2 compilers to compile with warnings active on default, plus to have a switch to disable them. LDC is actually built with -Wall -Wextra by default. The warnings are disabled for the DMD source files though, as leaving them on just floods the console output, making actual issues much harder to see. We will have to look into additionally adding warning push/pop pragmas around the frontend includes in the proper LDC source files though. Currently, we get quite a bit of log spam from them, and some of them are unlikely to be addressed in the upstream source. You should have more abstraction in LDC between the two frontend layers. :)
Re: Recommendation: Compile DMD with More Warnings
Who could explain. AFAIK D was position as language without warnings. The idea was in that code maybe correct or wrong, without any intermediate state, and now I am reading about warnings.
Re: Recommendation: Compile DMD with More Warnings
On 7 Apr 2014 06:20, Suliman everm...@live.ru wrote: Who could explain. AFAIK D was position as language without warnings. The idea was in that code maybe correct or wrong, without any intermediate state, and now I am reading about warnings. This thread is talking about the compiler implementation (written in C++). As for D's stance on warnings, it's pretty much only used for features being removed, as part of our deprecate/warn/error process. Code that is considered incorrect is always an error.
Re: Recommendation: Compile DMD with More Warnings
On 4/6/2014 9:45 AM, Orvid King wrote: If you want, I have the results of a static analysis of DMD that I could post, as processed in 23 hours and 58 minutes by Intel's C compiler, using 10gb of RAM the entire time. If I can figure out how to have it not skip any methods (there were still a significant number that it didn't analyze due to complexity limits) I'll run it again and post the full results. In my basic look over the results, there were a decent number of them that may actually be bugs. (buffer overruns, and even a few instances of accessing memory after it had been freed) Yes, please post.
Re: Empty array and AA literals
On Sunday, 6 April 2014 at 03:28:50 UTC, dnspies wrote: On Sunday, 6 April 2014 at 03:23:17 UTC, Adam D. Ruppe wrote: You can just set it to null. Then, next time you add anything to it, a new one will be automatically created. What about if I have a 2D array (ie int[][]) and I want to append an empty int[] on the end? Will this work? int[][] nested; nested ~= null; ~ is overloaded, so how does it know what type I intend null to be? How can I specify it? For dynamic arrays you can use the new operator. nested ~= new int[]; Or in this case, you could just increment the length. ++nested.length;
CTFE log2 functions
Another one ctfe log2, integer and real versions:
[code]
module util.ctfelog2;
uint ctfe_ilog2(ulong arg) pure {
assert(arg != 0);
uint result = 0;
while(arg = 1)
result++;
return result;
}
ulong ctfe_log2(real arg, uint fracBits) pure {
import std.math : sqrt, SQRT2;
uint intPart = ctfe_ilog2(cast(ulong)arg);
ulong result = intPart;
if(fracBits == 0 || arg == (1 intPart))
return result fracBits;
real sq = arg / (1 intPart);
for(uint i = fracBits; i; i--) {
if(sq 2) {
result |= 1;
sq /= 2;
}
sq *= sq;
result = 1;
}
return result;
}
real ctfe_log2(real arg) pure {
return ctfe_log2(arg, 56) / cast(real)(1UL 56);
}
unittest {
import std.math : log2, abs;
for(real l = 1; l 256; l += 0.3) {
double d1 = ctfe_log2(l);
double d2 = log2(l);
assert(abs(d1 - d2) (cast(real)1.0)/(1UL 48));
}
}
[/code]
Re: Empty array and AA literals
On 04/06/2014 05:28 AM, dnspies wrote: int[][] nested; nested ~= null; ~ is overloaded, so how does it know what type I intend null to be? How can I specify it? (int[]).init
Re: Empty array and AA literals
On Sunday, 6 April 2014 at 09:52:04 UTC, monarch_dodra wrote: An Dynamic Array is merelly a fat pointer that holds both pointer and length. There is no need to create or new a Dynamic Array. new allows for setting the length immediately, though. auto arr = new int[](99); // arr.length = 99; // avoided this Does doing it in two steps allocate twice?
Re: Empty array and AA literals
On Sunday, 6 April 2014 at 19:48:37 UTC, JR wrote: On Sunday, 6 April 2014 at 09:52:04 UTC, monarch_dodra wrote: An Dynamic Array is merelly a fat pointer that holds both pointer and length. There is no need to create or new a Dynamic Array. new allows for setting the length immediately, though. Right, but what I'm getting at, in regards to the original question: What's the syntax for a new empty dynamic array You don't new the dynamic array. Technically, you just allocate memory, and then have your *slice* reference that memory. The slice itself is not newed. An empty slice is merely a slice that reference no data. It just exists and is not newed. This is in contrast to, say, classes, where you *must* do A a = new A(args) to initialize and use it. And yet even more in contrast to types that look like value types, but are secretly implemented as reference types, without the new keyword: Types that use reference semantic, but without the new keyword. These include: AA, Appender, Array, and a couple others. auto arr = new int[](99); // arr.length = 99; // avoided this Does doing it in two steps allocate twice? Nope. That's perfectly valid (and recomended).
Re: Query Context at Source File and Offset in DMD
The Lexer's constructor takes a Module as the first parameter [1]. A Module has the original argument name [2], I assume that's the filename. Just store the module/filename as an instance variable in the lexer and access it where you need it. [1] https://github.com/D-Programming-Language/dmd/blob/master/src/lexer.c#L245 [2] https://github.com/D-Programming-Language/dmd/blob/master/src/module.h#L76 Thx.
Re: templates, enums, CT reflection: compiler bug or not?
no one any ideas? well, i filed two bug reports for now: https://d.puremagic.com/issues/show_bug.cgi?id=12532 https://d.puremagic.com/issues/show_bug.cgi?id=12533
Re: Best way to convert and apply floor()
On Sunday, 6 April 2014 at 08:23:16 UTC, Daniele M. wrote: For example, is this the best way to perform a conversion + floor? Input 'x' is a floating point expression that is never big enough to justify usage of double or real type, but I picked real because I noticed that it was the implicit cast type. auto s = 3.14; int x = cast(int)floor(to!real(x)); (assuming you meant to!real(s) here) // x == 3 I'd advise you to avoid casts, especially when you're starting out with D. They're unsafe and you can easily blow your leg off with them. std.conv.to does safe conversions. So, use to!int instead of cast(int). Conversion to int drops the fractional part, so you don't really need floor. But if you think it makes the intent clearer, feel free to leave it in. With UFCS[1], dropped empty parentheses, and 'auto' for implicit typing: auto x = s.to!real.to!int; You could try to avoid the double conversion and parse directly to int. But that would be a lot more work and error-prone, if you want to support all the formats that to!real recognizes. I think two conversions are fine. [1] http://dlang.org/function.html#pseudo-member
Re: Empty array and AA literals
dnspies: What about if I have a 2D array (ie int[][]) and I want to append an empty int[] on the end? Will this work? int[][] nested; nested ~= null; ~ is overloaded, so how does it know what type I intend null to be? How can I specify it? You can increase by one of the length of the outer array, or you can append an empty one: nested.length++; or: nested ~= []; I don't remember if you can also append a null. Appending a null, if it works, could be more efficient. Take a look at the ASM. Bye, bearophile
Re: Best way to convert and apply floor()
On Sunday, 6 April 2014 at 09:23:21 UTC, anonymous wrote: Conversion to int drops the fractional part, so you don't really need floor. But if you think it makes the intent clearer, feel free to leave it in. Well, conversion to int drops the fractional part, rounding *towards* 0, whereas floor floor will reduce to the lower integral. It can make a difference for negatives: auto x = -3.5; floor(x); // = -4 cast(int)x; // = -3
Re: Empty array and AA literals
On Sunday, 6 April 2014 at 09:41:10 UTC, bearophile wrote: dnspies: What about if I have a 2D array (ie int[][]) and I want to append an empty int[] on the end? Will this work? int[][] nested; [...] You can increase by one of the length of the outer array, or you can append an empty one: [...] nested ~= []; That doesn't add an element. [] is interpreted to be an empty int[][]. You need to write [[]] which is an int[][] holding one empty int[].
Re: Empty array and AA literals
On Sunday, 6 April 2014 at 03:17:25 UTC, dnspies wrote: What's the syntax for a new empty dynamic array or associative array? Every time I want to set a AA, I have to say: (supposing I already have some variable int[int] aa which points to the wrong one) int[int] throwaway; aa = throwaway; What about for a normal dynamic array? AA's and Dynamic Arrays are different beasts. An Dynamic Array is merelly a fat pointer that holds both pointer and length. There is no need to create or new a Dynamic Array. An AA, on the other hand, is completely different. It's a pointer to an implementation, and the implementation does the actual work. The AA lazily initializes on the first operations. However, until initialized, an AA is pretty much just a null pointer. This can lead to interesting scenarios such as: // int[int] a; //null int[int] b = a; //both null assert(a is b); //They are both null a[1] = 1; //a gets initialized assert(a !is b); //but b remains null. int[int] c = a; //c points to the same implementation a[2] = 2; //a's implementation is changed assert(a is c); //and c sees it. // Is there a way to say something like: aa = new int[int] ? like I would with a class. Currently, no. However, you can force initialization with a dummy insertion: int[int] b = [1:1]; b.remove(1); //b is now an empty, but initialized, AA It's a bit dirty, but that's how it is.
Re: Empty array and AA literals
anonymous: You can increase by one of the length of the outer array, or you can append an empty one: [...] nested ~= []; That doesn't add an element. [] is interpreted to be an empty int[][]. You need to write [[]] which is an int[][] holding one empty int[]. Thank you catching my mistake. But adding a null increases the length by 1: a ~= null; This difference is another reason for me to desire the removal of null as array literal. Bye, bearophile
Re: running my program with shared libraries
On Sunday, 6 April 2014 at 02:49:15 UTC, Adam D. Ruppe wrote: On Sunday, 6 April 2014 at 00:12:00 UTC, Harpo wrote: Then in a runner script I have this. LD_LIBRARY_PATH=. ./main This kind of thing is common in Linux, in fact, a lot of Linux software consists of a runner script that sets LD_LIBRARY_PATH and a separate binary file and its library .so files that is the actual application. LD_LIBRARY_PATH tells it where to find the shared library files. Without it, the system only searches the global directories like /usr/lib. You can also use the linker flag -rpath to hard-code the search path in the executable. dmd your_file.d -L-rpath -L'$ORIGIN/.' The $ORIGIN (with quotation marks around it to keep it from being expanded) is important. It means the linker should interpret the path relative to the location of your executable, instead of relative to whatever the current directory happens to be. (The latter is a security risk, because an adversary might trick the user to run your executable from their own directory, where they have placed a manipulated copy of the shared library.)
Re: Set differences
Josh:
Can anyone please explain why this works:
auto numbers = sequence!(n)();
auto trimmed = setDifference(setDifference(numbers,
sequence!(n * a[0])(2)), sequence!(n * a[0])(3));
but this doesn't?
auto numbers = sequence!(n)();
auto trimmed = setDifference(numbers, sequence!(n *
a[0])(2));
trimmed = setDifference(trimmed, sequence!(n * a[0])(3));
This compiles:
void main() {
import std.stdio, std.algorithm, std.range;
auto numbers = sequence!(n)();
auto trimmed = setDifference(numbers, sequence!(n *
a[0])(2));
auto trimmed2 = setDifference(trimmed, sequence!(n *
a[0])(3));
pragma(msg, typeof(trimmed));
pragma(msg, typeof(trimmed2));
}
Output:
SetDifference!(a b, Sequence!(n, Tuple!()), Sequence!(n *
a[0], Tuple!int))
SetDifference!(a b, SetDifference!(a b, Sequence!(n,
Tuple!()), Sequence!(n * a[0], Tuple!int)), Sequence!(n *
a[0], Tuple!int))
The two trimmed have different type, because in D ranges are
template-based, so often things have different type, unless they
are identical.
Bye,
bearophile
Re: How to obtain a list of all the elements of an enum?
On Sunday, 6 April 2014 at 02:18:57 UTC, dnspies wrote:
If I have an enum:
enum x {A : 1, B : 2, C : 100};
How can I get a list of all of its elements?
x.get_list() (returns [A, B, C])
EnumMembers (http://dlang.org/phobos/std_traits.html#EnumMembers)
should do what you need. It will give you a compile-time tuple of
all the members of your tuple. Depending on what you are doing,
you may or may not want to place them into an array
[EnumMembers!x].
Re: execute commands in the terminal OSX
I've course I tried these things, but there doesn't seem to be some thing to do the same thing as 'system'. At least to clear the terminal. On Thursday, 3 April 2014 at 09:00:26 UTC, Gary Willoughby wrote: On Thursday, 3 April 2014 at 04:58:12 UTC, Joel wrote: It says in the Language Reference not to use system and gives other options. But the other options don't seem to work. I just have code system(clear); Try this: http://dlang.org/phobos/std_process.html#.executeShell
[Issue 11777] [ICE] dmd memory corruption as `Scope::pop` `free`s `fieldinit` used also in `enclosing`
https://d.puremagic.com/issues/show_bug.cgi?id=11777 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12523] wrong foreach argument type with ref and inout
https://d.puremagic.com/issues/show_bug.cgi?id=12523 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12523] wrong foreach argument type with ref and inout
https://d.puremagic.com/issues/show_bug.cgi?id=12523 --- Comment #3 from github-bugzi...@puremagic.com 2014-04-05 22:58:50 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/b8669836b696742709042aaa1b4cf4c8970bcc57 fix Issue 12523 - wrong type deduced for foreach ref argument - No need to change the storage class because the var type already has inferred modifiers. https://github.com/D-Programming-Language/dmd/commit/6d10394b33fea5e20a946b6f748239ee4a0e5076 Merge pull request #3424 from MartinNowak/fix12523 fix Issue 12523 - wrong type deduced for foreach ref argument -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12509] Compiler performance highly depends on declared array size - for struct with long static array of structs
https://d.puremagic.com/issues/show_bug.cgi?id=12509 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||performance, pull --- Comment #4 from Kenji Hara k.hara...@gmail.com 2014-04-05 23:20:11 PDT --- https://github.com/D-Programming-Language/dmd/pull/3425 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12526] New: DDox possible issue with case sensitive file names
https://d.puremagic.com/issues/show_bug.cgi?id=12526 Summary: DDox possible issue with case sensitive file names Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: websites AssignedTo: nob...@puremagic.com ReportedBy: c...@dawg.eu --- Comment #0 from Martin Nowak c...@dawg.eu 2014-04-06 07:17:12 PDT --- Not sure where this comes from (case insensitive file system?) but the documentation for TaskPool is missing. It's page is overwritten by the documentation for taskPool and the taskPool.html page doesn't exist. http://dlang.org/library/std/parallelism/taskPool.html http://dlang.org/library/std/parallelism/TaskPool.html -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12527] New: Cannot make @system function/delegate alias in a @safe section
https://d.puremagic.com/issues/show_bug.cgi?id=12527
Summary: Cannot make @system function/delegate alias in a @safe
section
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bugzi...@kyllingen.net
--- Comment #0 from Lars T. Kyllingstad bugzi...@kyllingen.net 2014-04-06
07:25:09 PDT ---
Consider the following:
@safe:
alias Fun = void function() @system;
pragma (msg, Fun.stringof);
alias Del = void delegate() @system;
pragma (msg, Del.stringof);
When compiling this, DMD prints:
void function() @safe
void delegate() @safe
In other words, the @safe: directive somehow prevents the @system attribute
from becoming part of the alias. Here is a test case which should compile, but
which doesn't:
@safe:
alias Fun = void function() @system;
@system void foo() { }
@trusted void bar(Fun fun) { fun(); }
void main() { bar(foo); }
This fails with the following error message:
bug.d(5): Error: function bug.bar (void function() @safe fun) is not callable
using argument types (void function() @system)
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12526] DDox possible issue with case sensitive file names
https://d.puremagic.com/issues/show_bug.cgi?id=12526 S�nke Ludwig slud...@outerproduct.org changed: What|Removed |Added CC||slud...@outerproduct.org --- Comment #1 from S�nke Ludwig slud...@outerproduct.org 2014-04-06 07:35:44 PDT --- Exactly, Andrei generates the website on an OS X box, which uses case insensitive HFS by default. AFAICS there is no way to talk the OS to still store files case sensitive (like there is on Windows) other than using a partition with a case sensitive FS, so there are only two options: find some alternative file name scheme that doesn't rely on case, or switch to a case sensitive file system when generating the documentation. Andrei's suggestion was to just aggregate everything under the all lower case version of the name. This would be an option, but requires some reorganization of how DDOX outputs the pages, breaks old links (probably still acceptable at this point?) and slightly waters the one entity == one page concept (which is of course already not working for function overloads). All the other schemes that came to mind (such as numbering pages with names of different case, or escaping upper case letters) are either ugly or would result in transient links. My favorite would obviously be to just switch the file system, but of course Andrei has the last call there - and it also wouldn't be the worst thing to have something that works on any OS/FS. Any other ideas how to solve this? If not, I'll look into the aggregation solution as soon as I get some time for that. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12526] DDox possible issue with case sensitive file names
https://d.puremagic.com/issues/show_bug.cgi?id=12526 --- Comment #2 from Martin Nowak c...@dawg.eu 2014-04-06 08:03:48 PDT --- Aggregation seems feasible because the two entities have a close relation, i.e. usually the lower case is a constructor using IFTI. http://dlang.org/library/std/range/outputRangeObject.html http://dlang.org/library/std/range/OutputRangeObject.html -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12179] [ICE](e2ir.c 1861) with array operation
https://d.puremagic.com/issues/show_bug.cgi?id=12179 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||diagnostic, ice, pull --- Comment #3 from Kenji Hara k.hara...@gmail.com 2014-04-06 08:12:41 PDT --- https://github.com/D-Programming-Language/dmd/pull/3427 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12528] New: foreach with inout ref argument cannot be interpreted at compile time
https://d.puremagic.com/issues/show_bug.cgi?id=12528
Summary: foreach with inout ref argument cannot be interpreted
at compile time
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: CTFE
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: c...@dawg.eu
--- Comment #0 from Martin Nowak c...@dawg.eu 2014-04-06 08:33:39 PDT ---
cat bug.d CODE
inout(T)[] dup(T)(inout(T)[] a)
{
inout(T)[] res;
foreach (ref e; a)
res ~= e;
return res;
}
enum works = dup([0]);
enum trigger = dup([0, 1]);
CODE
dmd -c bug.d
bug.d(5): Error: Cannot interpret res ~= e at compile time
bug.d(10):called from here: dup([0, 1])
Probably some issue when reassigning the foreach argument because it's only
triggered when the array has more than one element.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12528] [CTFE] cannot append elements from one inout array to another inout array
https://d.puremagic.com/issues/show_bug.cgi?id=12528 --- Comment #1 from Martin Nowak c...@dawg.eu 2014-04-06 09:25:29 PDT --- workaround: foreach (ref e; a) res ~= [e]; -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12312] Regression (2.064): Diagnostic for void static arrays has gone bad
https://d.puremagic.com/issues/show_bug.cgi?id=12312 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||diagnostic, pull Version|unspecified |D2 --- Comment #2 from Kenji Hara k.hara...@gmail.com 2014-04-06 09:54:04 PDT --- https://github.com/D-Programming-Language/dmd/pull/3428 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12529] New: Function/delegate type alias picks up @safe attribute from surrounding scope
https://d.puremagic.com/issues/show_bug.cgi?id=12529
Summary: Function/delegate type alias picks up @safe attribute
from surrounding scope
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bugzi...@kyllingen.net
--- Comment #0 from Lars T. Kyllingstad bugzi...@kyllingen.net 2014-04-06
11:48:27 PDT ---
Consider:
@safe:
alias F = void function();
This wrongly makes F an alias of void function() @safe rather than void
function().
Here is a test case which should compile, but which fails to do so:
void foo() { }
@safe:
alias F = void function();
@trusted void bar(F f) { f(); }
void main() { bar(foo); }
DMD says:
bug.d(6): Error: function bug.bar (void function() @safe f) is not callable
using argument types (void function())
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12527] Cannot make @system function/delegate alias in a @safe section
https://d.puremagic.com/issues/show_bug.cgi?id=12527 --- Comment #1 from Lars T. Kyllingstad bugzi...@kyllingen.net 2014-04-06 11:55:52 PDT --- Actually, I think the test case should compile even without the explicit @system attribute. I've filed a separate report about this, see issue 12529. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12530] New: uniform initialization for type tuples too
https://d.puremagic.com/issues/show_bug.cgi?id=12530 Summary: uniform initialization for type tuples too Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: monarchdo...@gmail.com --- Comment #0 from monarchdo...@gmail.com 2014-04-06 12:14:28 PDT --- Not sure if enhancement request or bug, but filing as EH. I think these should work: // auto a = TypeTuple!(int, int, int)(); //(0, 0, 0) auto b = TypeTuple!(int, int, int)(1); //(1, 1, 1) //auto c = TypeTuple!(int, int, int)(1, 2); //Should fail auto d = TypeTuple!(int, int, int)(1, 2, 3); //(1, 2, 3) // Currently they all produce: Error: function expected before (), not (int, int, int) of type (int, int, int) In particular, I think this should work: // TypeTuple!(int, int, int) a = ...; TypeTuple!(int, int, int) b = TypeTuple!(int, int, int)(a); // Though arguably, it's the exactly the same as the d case above. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
