VisualD now on github.com/d-programming-language
https://github.com/D-Programming-Language/visuald Congratulations to Rainer Schuetze and collaborators for this great work!
Re: VisualD now on github.com/d-programming-language
On Tuesday, 10 September 2013 at 06:42:06 UTC, Walter Bright wrote: https://github.com/D-Programming-Language/visuald Congratulations to Rainer Schuetze and collaborators for this great work! Horray! Great news. Some initial nit-picking: According to http://www.dsource.org/projects/visuald/wiki/Installation Visual Studio Shell 2012 is supported. But https://github.com/D-Programming-Language/visuald only mentions: * Supported Visual Studio versions - VS.NET 2003 (some limitations apply) - VS 2005 - VS 2008 - VS 2010 1) I assume that the full non express 2012 is supported also? 2) VS Shell 2010 link @ http://www.dsource.org/projects/visuald/wiki/Installation is broken. 3) Preferably the two links to The Visual Studio Shell 2012 should be visible in the github readme.
Re: VisualD now on github.com/d-programming-language
Indeed, massive thanks! On 10 Sep 2013 16:45, Walter Bright newshou...@digitalmars.com wrote: https://github.com/D-**Programming-Language/visualdhttps://github.com/D-Programming-Language/visuald Congratulations to Rainer Schuetze and collaborators for this great work!
Re: D simple web server
Hi, I added websocket support to the server. This is the link to the git repo: https://github.com/gedaiu/DSWS Thanks, Bogdan
Re: [OT] My C++ talk at GoingNative 2013
On Monday, 9 September 2013 at 16:43:54 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/1m1izv/goingnative_2013_writing_quick_code_in_c_quickly/ Andrei So I'll jump in as I've seen the conf before that post. It is really worthwhile to watch. Quite informative on the technical side (funilly, I did implement the solution presented in the devirtualization part on a platform where virtual function were not available because of crappy compiler, but had no idea it was worthwhile for speed, it wasn't the goal so I never measured, and it also may not the case on the given plateform). Many discussed subject apply as well to D. By the way, what is the state of std.bitmanip in comparison to what is presented in the conf ? Also, Andrei, did you try LLVM/clang ? Related to going native, Chandler the discussion on signess of integers and I really wonder if we should follow the rule that make unsigned spread like a virus, as C does.
Re: VisualD now on github.com/d-programming-language
On Tuesday, 10 September 2013 at 06:42:06 UTC, Walter Bright wrote: https://github.com/D-Programming-Language/visuald Congratulations to Rainer Schuetze and collaborators for this great work! Do you have plans for changing the homepage for VisualD? The one on dsource is more related to the old repository.
Re: [OT] My C++ talk at GoingNative 2013
First of all, I very much enjoyed the talk. It was as interesting as it was entertaining. I do have a question regarding the talk's section on devirtualization. As a language that imposes virtual methods for classes, how well does D play when it comes to devirtualization? And on a side note, does D have a different way of implementing virtual methods than most C++ compilers do? Thanks, O. On Monday, 9 September 2013 at 16:43:54 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/1m1izv/goingnative_2013_writing_quick_code_in_c_quickly/ Andrei
Re: [OT] My C++ talk at GoingNative 2013
On 10 September 2013 13:54, Olivier Grant olivier.gr...@gmail.com wrote: First of all, I very much enjoyed the talk. It was as interesting as it was entertaining. I do have a question regarding the talk's section on devirtualization. As a language that imposes virtual methods for classes, how well does D play when it comes to devirtualization? And on a side note, does D have a different way of implementing virtual methods than most C++ compilers do? All class methods are virtual by default in D, unless declared 'final'. Devirtualisation is not something done by the front-end, but recent updates and interest from compiler back-ends may provide a solution. -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: [OT] My C++ talk at GoingNative 2013
On 10 September 2013 11:10, deadalnix deadal...@gmail.com wrote: On Monday, 9 September 2013 at 16:43:54 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/1m1izv/goingnative_2013_writing_quick_code_in_c_quickly/ Andrei So I'll jump in as I've seen the conf before that post. It is really worthwhile to watch. Quite informative on the technical side (funilly, I did implement the solution presented in the devirtualization part on a platform where virtual function were not available because of crappy compiler, but had no idea it was worthwhile for speed, it wasn't the goal so I never measured, and it also may not the case on the given plateform). Interestingly enough, gcc recently added (about a month before Andrei did the talk) a new interprocedural analysis pass that sets all methods that can be devirtualised. I expect that LLVM have something cooking up for this too. As of yet, I haven't ran any tests which show that this works though... -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: [OT] My C++ talk at GoingNative 2013
On Tuesday, 10 September 2013 at 13:20:18 UTC, Iain Buclaw wrote: On 10 September 2013 11:10, deadalnix deadal...@gmail.com wrote: On Monday, 9 September 2013 at 16:43:54 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/1m1izv/goingnative_2013_writing_quick_code_in_c_quickly/ Andrei So I'll jump in as I've seen the conf before that post. It is really worthwhile to watch. Quite informative on the technical side (funilly, I did implement the solution presented in the devirtualization part on a platform where virtual function were not available because of crappy compiler, but had no idea it was worthwhile for speed, it wasn't the goal so I never measured, and it also may not the case on the given plateform). Interestingly enough, gcc recently added (about a month before Andrei did the talk) a new interprocedural analysis pass that sets all methods that can be devirtualised. I expect that LLVM have something cooking up for this too. As of yet, I haven't ran any tests which show that this works though... The main problem with devirtualization is that you can only have full benefits when targeting VM based environments. With native generated code, it is only possible to apply devirtualization on static linked code. -- Paulo
Re: DCD: Autocomplete without the IDE
I just tried it with the Kate and it's working like a charm! All contributors keep up the good work :-) I really like the client/server approach because it enables everyone to use his or hers favourite editor. Is there a blog or changelog which allows to follow the further progress? Cheers André On Sunday, 1 September 2013 at 10:58:28 UTC, Brian Schott wrote: * What is it? DCD is a client and server program that work together to provide autocomplete suggestions and function call tips to almost any text editor that supports scripting or plugins. * Who is it for? People who would like autocomplete, but don't want to give up their favorite editor for an IDE. * Where is it? GitHub! https://github.com/Hackerpilot/DCD * What does it look like? There's a short demo video on Youtube: http://www.youtube.com/watch?v=Vo2POmn2_9U * What editors does it work with? Textadept, Kate/KDevelop, Vim, and Emacs. The Textadept integration script is the reference implementation. * This sounds a lot like GoCode It does, doesn't it? * Does it work? Yes and no. DCD is fairly new, and not all of the features you'd expect from a D autocompletion engine are present. I do feel that it's enough of an improvement over not having autocomplete to make this alpha announcement. * Should I file bug reports in this announcement thread? No. Add them here: https://github.com/Hackerpilot/DCD/issues?state=open
Re: vibe.d 0.7.17 released
On Monday, 9 September 2013 at 08:03:46 UTC, Sönke Ludwig wrote: Major changes: - Compiles on DMD 2.063.2 and DMD HEAD - Deprecates/removes a lot of non-conforming parts of the API (resp. naming convention) - New TaskLocal!T for more efficient and type safe task local storage - New TaskPipe class for stream based inter-fiber communication (can be used to connect classic blocking I/O with asynchronous I/O using a separate thread) - New SyslogLogger class by Jens Mueller - A bunch of smaller fixes/additions Full change log: http://vibed.org/blog/posts/vibe-release-0.7.17 Download: http://vibed.org/download GitHub: https://github.com/rejectedsoftware/vibe.d Thanks for the great work! Do you think you are closer to feeling comfortable including in some benchmark sites (e.g. maybe add to http://www.techempower.com/benchmarks/#section=data-r5)? Thanks Dan
Re: VisualD now on github.com/d-programming-language
On 10.09.2013 12:24, develop32 wrote: On Tuesday, 10 September 2013 at 06:42:06 UTC, Walter Bright wrote: https://github.com/D-Programming-Language/visuald Congratulations to Rainer Schuetze and collaborators for this great work! Do you have plans for changing the homepage for VisualD? The one on dsource is more related to the old repository. It is planned to move the homepage to dlang.org. It might take some time to convert the wiki pages to some other format which can be used to generate the pages (ddoc?). Easiest would probably be to add it to wiki.dlang.org, but I'm unsure whether this is appropriate.
Re: VisualD now on github.com/d-programming-language
On 10.09.2013 11:50, Tove wrote: On Tuesday, 10 September 2013 at 06:42:06 UTC, Walter Bright wrote: https://github.com/D-Programming-Language/visuald Congratulations to Rainer Schuetze and collaborators for this great work! Horray! Great news. Some initial nit-picking: According to http://www.dsource.org/projects/visuald/wiki/Installation Visual Studio Shell 2012 is supported. But https://github.com/D-Programming-Language/visuald only mentions: * Supported Visual Studio versions - VS.NET 2003 (some limitations apply) - VS 2005 - VS 2008 - VS 2010 1) I assume that the full non express 2012 is supported also? 2) VS Shell 2010 link @ http://www.dsource.org/projects/visuald/wiki/Installation is broken. 3) Preferably the two links to The Visual Studio Shell 2012 should be visible in the github readme. Thanks for pointing these out. The README didn't receive a lot of attention lately, most of the documentation and news is on the web site. I agree, with it being displayed on the front github page it should be updated.
Re: vibe.d 0.7.17 released
On Tuesday, 10 September 2013 at 17:13:09 UTC, Daniel Davidson wrote: Thanks for the great work! Do you think you are closer to feeling comfortable including in some benchmark sites (e.g. maybe add to http://www.techempower.com/benchmarks/#section=data-r5)? Thanks Dan I think I can safely answer this question in absence of Sonke as someone subscribed to vibe.d commit log :) It was asked and answered: forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/1670 - not much has changed since then. Basically, almost all popular benchmarks tends to focus on speed of utility modules, not speed of HTTP server / application router itself. That is something that has never been tested or put serious efforts into. Area where vibe.d truly shines performance-wise is core request handling framework and I am not aware of any public benchmark game in that domain. Now, if someone takes the time to run those tests manually and tell how bad situation really is - that stuff would have been really interesting to learn :)
Re: vibe.d 0.7.17 released
On Tuesday, 10 September 2013 at 17:37:21 UTC, Dicebot wrote: I think I can safely answer this question in absence of Sonke as someone subscribed to vibe.d commit log :) Thanks It was asked and answered: forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/1670 - not much has changed since then. Basically, almost all popular benchmarks tends to focus on speed of utility modules, not speed of HTTP server / application router itself. That is something that has never been tested or put serious efforts into. In that thread Sonke said: Agreed, I'd say we should start to prepare the benchmark cases and see how they actually compare against the others. I can understand reservations about not wanting to publish benchmarks too early before some chance at optimization. OTOH, if it is utility modules that distort the numbers then maybe they need attention and data is the best way to draw it. And, just maybe, you and Sonke are too pessimistic? For example, shouldn't Json serialization be a win for D with its compile time approach? Area where vibe.d truly shines performance-wise is core request handling framework and I am not aware of any public benchmark game in that domain. I bet you are correct. But then, how can you know if there is no public benchmark game in that domain :-) Maybe the best approach is to find a way to work more sophisticated tests into the benchmark that show where vibe/D shines. Without benchmarks it is all guesswork... but I'll bet the compile time diet templates shine. Other guesses? Now, if someone takes the time to run those tests manually and tell how bad situation really is - that stuff would have been really interesting to learn :) Agreed!
Re: vibe.d 0.7.17 released
On 9/9/13 1:03 AM, Sönke Ludwig wrote: [snip] http://www.reddit.com/r/programming/comments/1m4eon/vibed_web_application_toolkit_in_d_0717_has_been/ VOTE UP!!! Andrei
Re: DCD: Autocomplete without the IDE
On Tuesday, 10 September 2013 at 16:15:55 UTC, André wrote: I just tried it with the Kate and it's working like a charm! All contributors keep up the good work :-) I really like the client/server approach because it enables everyone to use his or hers favourite editor. Is there a blog or changelog which allows to follow the further progress? Cheers André On Sunday, 1 September 2013 at 10:58:28 UTC, Brian Schott wrote: * What is it? DCD is a client and server program that work together to provide autocomplete suggestions and function call tips to almost any text editor that supports scripting or plugins. * Who is it for? People who would like autocomplete, but don't want to give up their favorite editor for an IDE. * Where is it? GitHub! https://github.com/Hackerpilot/DCD * What does it look like? There's a short demo video on Youtube: http://www.youtube.com/watch?v=Vo2POmn2_9U * What editors does it work with? Textadept, Kate/KDevelop, Vim, and Emacs. The Textadept integration script is the reference implementation. * This sounds a lot like GoCode It does, doesn't it? * Does it work? Yes and no. DCD is fairly new, and not all of the features you'd expect from a D autocompletion engine are present. I do feel that it's enough of an improvement over not having autocomplete to make this alpha announcement. * Should I file bug reports in this announcement thread? No. Add them here: https://github.com/Hackerpilot/DCD/issues?state=open https://github.com/Hackerpilot/DCD/commits/master
Re: vibe.d 0.7.17 released
On Tuesday, 10 September 2013 at 18:10:40 UTC, Daniel Davidson wrote: I can understand reservations about not wanting to publish benchmarks too early before some chance at optimization. OTOH, if it is utility modules that distort the numbers then maybe they need attention and data is the best way to draw it. And, just maybe, you and Sonke are too pessimistic? For example, shouldn't Json serialization be a win for D with its compile time approach? Well, we don't know. Now one has been ever benchmarking this. Ever. Someone needs to step up and provide the data. I will do it eventually, but that will happen later rather than sooner. Area where vibe.d truly shines performance-wise is core request handling framework and I am not aware of any public benchmark game in that domain. I bet you are correct. But then, how can you know if there is no public benchmark game in that domain :-) I've done some testing on my own ;) https://github.com/Dicebot/web-performance-tests - unfortunately, I was not able to get meaningful results for high concurrency cases because of h/w limits generic crappy laptop network cards have (should probably delete existing ones as they are mostly useless), but it provides all the tools for one to try and see :P Maybe the best approach is to find a way to work more sophisticated tests into the benchmark that show where vibe/D shines. Without benchmarks it is all guesswork... but I'll bet the compile time diet templates shine. Other guesses? There is always an option to create your own benchmarking game :P All you need is production-grade networking hardware and pair of PC's (with client being considerably more powerful than server).
Re: VisualD now on github.com/d-programming-language
On 9/10/2013 11:18 AM, Rainer Schuetze wrote: It is planned to move the homepage to dlang.org. It might take some time to convert the wiki pages to some other format which can be used to generate the pages (ddoc?). Easiest would probably be to add it to wiki.dlang.org, but I'm unsure whether this is appropriate. The main documentation should be in ddoc and part of dlang.org. The wiki is for user-supplied supplemental information. I know this will be a fair amount of work, and will take time. I'm sure Rainer could use some help from anyone who wants to step up!
Re: VisualD now on github.com/d-programming-language
On Tuesday, 10 September 2013 at 18:10:33 UTC, Rainer Schuetze wrote: Thanks for pointing these out. The README didn't receive a lot of attention lately, most of the documentation and news is on the web site. I agree, with it being displayed on the front github page it should be updated. No problem, I thought of one additional idea to enhance first impressions... Is this stable enough to be made default enabled in future releases? Use Alexander Bothe's D parsing engine for semantic analysis writing '.' I only found it because I remember reading about it on this very forum, it is my fear that other new users won't find it and hence consider the intellisense-experience lacking. After enabling this tiny checkbox,... wow, I love it! Thanks again!
Re: VisualD now on github.com/d-programming-language
Does VisualD work with VS2013?
Re: [OT] My C++ talk at GoingNative 2013
On Monday, 9 September 2013 at 16:43:54 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/1m1izv/goingnative_2013_writing_quick_code_in_c_quickly/ Andrei This talks are amazing. I learned a lot. Thank you all guys for your dedication and pedagogy. BTW, I really liked your face during the 'Ask us anything' panel, when STL talked about Garbage Collection! Congratulations for resisting the need to shout 'D does already solves this problem' at least a dozen of times. Too bad Native means C++ in Microsoft speak.
Re: Move VisualD to github/d-programming-language ?
On 09/09/13 21:26, Flamaros wrote: Personally I think that phobos contains some parts that are in Qt base, so a wrapper isn't a perfect solution for D. It's certainly the fastest way to extend the D framework and add a GUI library, but Qt phylosophy doesn't match perfectly with D. Just take a look to moc, in D it's possible and preferable to do without it. That why we started DQuick to create a complete adaption of QtQuick to D, this is much hard to do but DQuick has the potential to be much more suitable for D. I've just had a read through your DQuick announcement thread. It looks like a really nice project -- I wish you a lot of success with this. Now, that said, while Qt may have some issues with respect to D, supporting it isn't just a matter of wanting a GUI solution. It's not just a graphical toolkit -- it's THE most important cross-platform toolkit, and has been chosen as a first-class SDK component by various platforms. I'd say that makes good and up-to-date QtD bindings a very important strategic goal.
Re: new DIP47: Outlining member functions of aggregates
On 09/09/13 23:45, Ettienne Gilbert wrote:
Ahh, ok. I see where you are coming from - you were evaluating the implications
of what Jacob Carlborg proposed if mixed in with Walter's DIP47, right?
The code that Jacob proposed is currently legit D code and that isn't going to
change -- and if that solution works for you (or other people), great. However,
I don't think it completely address the requirements the DIP is attempting to
meet. In my previous email I was simply trying to show that implementing new
functionality to allow class functions to be defined outside the class
declaration, wouldn't be incompatible with writing code like Jacob's (although I
don't see why anyone would mix the approaches in this way).
In terms of where I'm coming from, it's more in line with Dicebot -- I think
both of us have been focused on the simultaneous usefulness and necessity of
being able to check declaration against definition for class member functions
that are declared and defined separately.
If you mix the 2 I agree with you for the most part. But the real question for
me (and I suspect Jacob) is this:
Is this...
[ ... snip code ...]
...really so much better than this?
[ ... snip again ...]
Granted, this sacrifices some flexibility from DIP47. But these are of such
dubious quality/use/potential pitfalls (as discussed in this thread), that I
hardly think DIP47 is worth implementing as a result. Especially since, what we
currently have (as shown by Carl,) already gives you arguably 90%+ (IMHO) of
Manu's request for (I quote) You don't need to see the function bodies in the
class definition, you want to quickly see what a class has and does. Does it
really matter that the function definitions are also present inside the class
definition, as long as you can also see what a class has and does in the
declarations list at the top?
The point is about being able to check that your declaration list has a
one-to-one match with your definition list. If you just decide to place
declarations at the top of the class definition, and definitions lower down, you
run the risk of accidentally missing one of the defined functions out of the
declaration list:
class Foo
{
// Declarations
void foo();
void bar();
// Definitions
void foo() { ... }
void bar() { ... }
void goo() { ... } // Whoops! This is part of the class API but
// we forgot to include it in our declaration
// list ...
}
But Andrej Mitrovic has suggested a means to implement those kind of
introspective checks at compile-time, so maybe it's not as urgent as I first
thought. (My one caveat is that I think solutions based on programmer virtue,
like remembering to insert a line: mixin VerifyDeclarations; into a class, are
generally less nice than solutions where the compiler does your checking for you
without you having to ask.)
Of course fixing the current issues with .di generation is important as a
separate issue.
Yes, absolutely.
Re: Move VisualD to github/d-programming-language ?
On 07.09.2013 21:04, Walter Bright wrote: Recent threads here have made it pretty clear that VisualD is a critical piece of D infrastructure. (VisualD integrated D usage into Microsoft Visual Studio.) Andrei, myself and Rainer (VisualD's champion) are all in agreement on this. What do you think? Thanks everyone for supporting this move. I have just transferred the repository to the D-Programming-Language organization and it can now be found at https://github.com/D-Programming-Language/visuald I'm planning to move the issues from the dsource bug database to bugzilla. Does anyone have experience with converting trac issues to bugzilla? There are currently 60 open reports (half of them enhancement requests), so it should also be possible to do this manually. The documentation and downloads are also going to move to dlang.org, but until this is sorted out, I'll leave it at dsource.org. If you want to get your hands dirty and try building Visual D yourself, see http://www.dsource.org/projects/visuald/wiki/Build_from_source. There is also a build project in the solution to help with the pre-compilation-steps. Please note, that the current github HEAD compiler has a bad bug when it comes to COM interfaces, but there is already a pull to the rescue (https://github.com/D-Programming-Language/dmd/pull/2537). Using the released dmd 2.063 should work. The releases are built with a patched compiler and runtime to support precise garbage collection, though. Rainer
Re: new DIP47: Outlining member functions of aggregates
On 09/09/13 21:35, H. S. Teoh wrote: Auto-generation of .di files solves this problem. (Provided we fix the mess that is the current implementation of .di generation, of course.) Maybe you'll think I'm being too picky, but I don't think that generated files of any kind (whether .di or Ddoc) really help with the situations Manu was describing. If you want to be able to look at the latest diff and see at a glance how the class API has changed, a generated file doesn't help (unless you store that generated file in the VCS, but I've always understood that to be bad practice).
Re: new DIP47: Outlining member functions of aggregates
On 10/09/13 04:09, Michel Fortin wrote: Is the D module system file-granular or module-granular? I always thought the later. Putting the implementation of functions in the .d file while the declarations are in the corresponding .di does not change things much: it's still one module, but it's one module split over two files. It also helps solve another problem: the problem where you're shipping a library and want to force some things to not be inlined. This is needed if the library is to be swapped for another version without having to recompile all client code. You can do this currently by hand-crafting .di files, but it's a pain to keep it manually in sync with the .d file. Is it possible to manually craft some parts of the .di file, while being able to rely on the compiler to automatically add any module contents that aren't manually declared? If so it might be the best solution to everyone's concerns.
Re: Move VisualD to github/d-programming-language ?
On Tuesday, 10 September 2013 at 06:18:16 UTC, Joseph Rushton Wakeling wrote: On 09/09/13 21:26, Flamaros wrote: Personally I think that phobos contains some parts that are in Qt base, so a wrapper isn't a perfect solution for D. It's certainly the fastest way to extend the D framework and add a GUI library, but Qt phylosophy doesn't match perfectly with D. Just take a look to moc, in D it's possible and preferable to do without it. That why we started DQuick to create a complete adaption of QtQuick to D, this is much hard to do but DQuick has the potential to be much more suitable for D. I've just had a read through your DQuick announcement thread. It looks like a really nice project -- I wish you a lot of success with this. Now, that said, while Qt may have some issues with respect to D, supporting it isn't just a matter of wanting a GUI solution. It's not just a graphical toolkit -- it's THE most important cross-platform toolkit, and has been chosen as a first-class SDK component by various platforms. I'd say that makes good and up-to-date QtD bindings a very important strategic goal. All parts of Qt that are non about GUI, like strings, io, network, regexp,... are or certainly will be in phobos. So for D applications started from ground I don't really see the benefits. But if D is compatible with Qt/C++ existing code, it will be great win. In this case QtD is clearly a strategic goal.
Re: Move VisualD to github/d-programming-language ?
On Monday, 9 September 2013 at 16:12:00 UTC, Brian Rogoff wrote: On Sunday, 8 September 2013 at 11:48:06 UTC, Paulo Pinto wrote: Am 08.09.2013 13:24, schrieb Russel Winder: On Sun, 2013-09-08 at 00:35 +0200, Paulo Pinto wrote: […] To make it more clear, the ML family of languages, Pascal family of languages, even JVM and .NET environments have native compilers available. You just have to look for them. IMO, D has more potential as a native code compilation target than Java, C#, and ML, at least in theory, because I should be able to control and even disable garbage collection. So, even users of managed languages may want to examine D. -- Brian I really hate the term managed language coined by Microsoft with .NET's introduction. What makes a language managed? A GC? Then D is also managed. Compiling to a VM? Then Java is native when I use the Excelsior JET compiler. Strong typing? Then Ada is managed. One type of consulting projects we do is port C++ code to .NET/JVM environments. I can assure that given the proper expertise how to code in a GC friendly way, GC is no a bottleneck than having to write special tuned versions of malloc()/free(). In D's case it is currently an issue, given that the current implementation is not as advanced as what is available in other runtimes. -- Paulo
Re: On inlining in D libraries
On 2013-09-10 06:02, Jonathan M Davis wrote: The compiler should definitely be able to look at non-templated functions and inline them where appropriate. I expect that it will really hurt performance in general if it doesn't - especially with stuff like getters or setters. I don't know what the best way would be for the compiler to go about doing that and have no idea how the inliner currently works, but I don't think that there's any question that it needs to. I agree. -- /Jacob Carlborg
Re: Move VisualD to github/d-programming-language ?
On 2013-09-09 12:47, Nick Sabalausky wrote: Huh? What are you talking about? I'm not grouping anyone with anything. When non-Windows users go saying things like Windoze or M$ or anything like that, it makes non-Windows users look bad. Makes it a lot easier for people to be dismissive of OSS (or anything non-MS) when we've trained them to associate it with immaturity like that. Sorry, I might have misunderstood what you wrote. -- /Jacob Carlborg
Re: Move VisualD to github/d-programming-language ?
On 2013-09-09 17:16, Walter Bright wrote: No. I just added the component. Do we have an API for the D bugzilla so we can easily migrate the issues? -- /Jacob Carlborg
Re: Move VisualD to github/d-programming-language ?
On 2013-09-10 08:49, Rainer Schuetze wrote: I'm planning to move the issues from the dsource bug database to bugzilla. Does anyone have experience with converting trac issues to bugzilla? There are currently 60 open reports (half of them enhancement requests), so it should also be possible to do this manually. Bugzilla has an REST API: https://wiki.mozilla.org/Bugzilla:REST_API Don't know if the D bugzilla has that enabled. -- /Jacob Carlborg
Re: Move VisualD to github/d-programming-language ?
On 9/10/2013 12:44 AM, Jacob Carlborg wrote: On 2013-09-09 17:16, Walter Bright wrote: No. I just added the component. Do we have an API for the D bugzilla so we can easily migrate the issues? Rainer is working on it, as he writes elsewhere in this thread.
Re: new DIP47: Outlining member functions of aggregates
On 2013-09-09 23:45, Ettienne Gilbert wrote: Ahh, ok. I see where you are coming from - you were evaluating the implications of what Jacob Carlborg proposed if mixed in with Walter's DIP47, right? My points though was specifically on the implications of Jacob Carlborg's proposal in isolation i.e. as an acceptable alternative to DIP47. And, AFAICS, Jacob posed the question to Manu this way as well (I think - but maybe Jacob can confirm/deny). Yes, my suggestion would be an alternative to DIP47. -- /Jacob Carlborg
Re: new DIP47: Outlining member functions of aggregates
On 2013-09-09 22:01, Andrej Mitrovic wrote:
You could use compile-time introspection where the API would look like:
class C
{
void foo();
void foo() { }
void bar() { } // missing declaration
mixin VerifyDeclarations;
}
And this would statically assert if there's a missing declaration for
a definition. I think this might even be doable with the current
introspection features, although I'm not sure whether we have a way to
determine if something is a declaration or a definition. Certainly
such a trait could easily be added to the compiler.
A mixin should not be necessary. RTInfo can be used for that:
https://github.com/D-Programming-Language/druntime/blob/master/src/object.di#L575
The compiler will instantiate RTInfo once for each user defined type.
The only downside is that you need to modify druntime.
--
/Jacob Carlborg
Re: Move VisualD to github/d-programming-language ?
On 2013-09-10 09:45, Walter Bright wrote: Rainer is working on it, as he writes elsewhere in this thread. Rainer was asking if anyone have experience with migrating Trac issues to bugzilla. Bugzilla does have an API. The question is it enabled for the D bugzilla. -- /Jacob Carlborg
Re: new DIP47: Outlining member functions of aggregates
On 2013-09-10 08:49, Joseph Rushton Wakeling wrote: (My one caveat is that I think solutions based on programmer virtue, like remembering to insert a line: mixin VerifyDeclarations; into a class, are generally less nice than solutions where the compiler does your checking for you without you having to ask.) That shouldn't be necessary, see my reply to Andrej: http://forum.dlang.org/thread/l0fm2o$2uat$1...@digitalmars.com?page=14#post-l0mjh4:2418bp:241:40digitalmars.com -- /Jacob Carlborg
Re: LLVM progress
On Monday, 9 September 2013 at 15:56:17 UTC, Flamaros wrote: On Monday, 9 September 2013 at 10:29:56 UTC, Chris wrote: Not to mention the importance of ARM support. It's an evidence that is a major target today. :-) I work only on ARM compatible application for my day job, that why DQuick is tough to be easy to port those devices. We'll need ARM support too for our applications, sooner or later.
Re: new DIP47: Outlining member functions of aggregates
On 10/09/13 09:59, Jacob Carlborg wrote: A mixin should not be necessary. RTInfo can be used for that: https://github.com/D-Programming-Language/druntime/blob/master/src/object.di#L575 The compiler will instantiate RTInfo once for each user defined type. The only downside is that you need to modify druntime. Can you explain a bit more about how that works? As long as it can provide a guarantee that everything declared has a definition, and everything defined has a declaration -- and that they match! -- then I think this is probably the solution required. What I mean is -- it needs to ensure that the issue identified in a couple of my earlier posts will be flagged and prevented: http://forum.dlang.org/post/mailman.1104.1378795749.1719.digitalmar...@puremagic.com However, I'm suspicious of anything that would require the programmer to be virtuous and manually ensure that those checks take place, rather than the checks simply being a natural part of the compilation process.
Re: Move VisualD to github/d-programming-language ?
On 9/10/2013 1:02 AM, Jacob Carlborg wrote: Rainer was asking if anyone have experience with migrating Trac issues to bugzilla. Bugzilla does have an API. The question is it enabled for the D bugzilla. I don't know. Brad Roberts runs Bugzilla. I'll forward this to him.
Re: On inlining in D libraries
On 09/09/13 16:34, Dmitry Olshansky wrote: 09-Sep-2013 18:26, Joseph Rushton Wakeling пишет: On 09/09/13 15:01, Dmitry Olshansky wrote: While investigating std.regex performance in Phobos I've found that a lot of stuff never gets inlined (contrary to my expectations). Is that just with dmd, or with gdc and ldc as well? For DMD and LDC confirmed. Would be interesting to test GDC but I bet it's the same (does LTO work here btw?). It used to, back in the gcc4.6 days. Right now gdc LTO is broken (unless things changed in the last couple of months). So you have the choice of using an old frontend with LTO or a reasonably recent one without (with no cross-module inlining). The fact that it is effectively impossible to use both gdc versions (ie the old LTO-enabled one just for release builds) makes the situation even worse (the language accepted by gdc was changed in a backward incompatible way; pragma-gcc- -attributes became errors). artur
Re: On inlining in D libraries
On 10/09/13 11:57, Artur Skawina wrote: It used to, back in the gcc4.6 days. Right now gdc LTO is broken (unless things changed in the last couple of months). What happened to break it?
Re: On inlining in D libraries
On 09/10/13 12:12, Joseph Rushton Wakeling wrote: On 10/09/13 11:57, Artur Skawina wrote: It used to, back in the gcc4.6 days. Right now gdc LTO is broken (unless things changed in the last couple of months). What happened to break it? The changes to gcc lto post-4.6. http://forum.dlang.org/thread/5139cf92.4070...@gmail.com http://bugzilla.gdcproject.org/show_bug.cgi?id=61 artur
Re: new DIP47: Outlining member functions of aggregates
On 09/10/2013 06:59 AM, Walter Bright wrote: The trouble with eschewing private access for member functions is then arguably the member functions do not belong in the class at all - they should be UFCS functions. Functions are placed inside classes for convenient scoping and vtables.
Re: review queue: next?
On Monday, 9 September 2013 at 20:24:43 UTC, Robert Schadek wrote: On 09/09/2013 04:21 PM, Dicebot wrote: While Jacob is working on improving std.serialization, there is some time to do more reviews. Review manager role does not seem to be very stressing, so I can step up as one for any of the projects currently in queue as soon as their authors express the desire to do so. put some concrete destroying in my logger You should add it to http://wiki.dlang.org/Review_Queue then, there is also a link to an old review thread of `std.log` by Jose Armando Garcia which may be of interest to you as people are likely to ask similar questions :)
Re: review queue: next?
On Monday, 9 September 2013 at 20:52:09 UTC, Brian Schott wrote: On Monday, 9 September 2013 at 14:21:17 UTC, Dicebot wrote: While Jacob is working on improving std.serialization, there is some time to do more reviews. Review manager role does not seem to be very stressing, so I can step up as one for any of the projects currently in queue as soon as their authors express the desire to do so. Personally, I'd love to move forward with std.d.lexer - Brian, what is your opinion on this? Other than some unit test coverage, I think the lexer is ready. Good! I'll start a review thread within a day.
Re: review queue: next?
On 09/10/2013 01:43 PM, Dicebot wrote: You should add it to http://wiki.dlang.org/Review_Queue then, there is also a link to an old review thread of `std.log` by Jose Armando Garcia which may be of interest to you as people are likely to ask similar questions :) done and done (the design of my logger is based on what I distilled from the old discussion)
Re: new DIP47: Outlining member functions of aggregates
On 2013-09-10 10:49, Joseph Rushton Wakeling wrote:
Can you explain a bit more about how that works?
The object module, part of druntime defines a template with the name
RTInfo. That template will be instantiated with each user defined type.
Currently RTInfo doesn't do anything:
template RTInfo(T)
{
enum RTInfo = cast(void*)0x12345678;
}
https://github.com/D-Programming-Language/druntime/blob/master/src/object.di#L575
If you replace that template with something like:
template RTInfo(T)
{
enum RTInfo = verifyDeclarations!(T);
}
verifyDeclarations would look something like this, in pseudo code:
void* verifyDeclarations (T) ()
{
static if (is(T == class))
{
foreach (member ; methods!(T))
{
static if (!hasDefinition!(member))
static assert (false, The member '
fullyQualifiedName!(T) ~ . ~ member.stringof ~ ' doesn't have a
definition);
}
}
return null;
}
As long as it can provide a guarantee that everything declared has a
definition, and everything defined has a declaration -- and that they
match! -- then I think this is probably the solution required.
What I mean is -- it needs to ensure that the issue identified in a
couple of my earlier posts will be flagged and prevented:
http://forum.dlang.org/post/mailman.1104.1378795749.1719.digitalmar...@puremagic.com
However, I'm suspicious of anything that would require the programmer to
be virtuous and manually ensure that those checks take place, rather
than the checks simply being a natural part of the compilation process.
The idea is then you build a tool that compiles all your files which
uses druntime with the above implementation of RTInfo.
--
/Jacob Carlborg
Re: new DIP47: Outlining member functions of aggregates
Main issue of .di files that make them useless for anything but providing declarations for blobs is that there is absolutely zero compiler control of .d and .di relation. Fixing this either implies providing good control of how .di is generated via compiler flags (and prohibiting manual modifications) or implementing good part of DIP47 restricted to .di/.d combo (all the signature verifications). Also it does not seem defined in spec how lookup should happen if both .d and .di are present, and, for example, .di has only declaration. Will compiler check .d for possible inlining if it is present? I think that .di should always contain only declarations and be _always_ auto-generated by compiler with strict 1-to-1 matching signatures. Then .d are also queried if implementation is needed/considered - but those are not mandatory (aside from templates). Blob bindings distributed may then simply have a stripped down version of .d file (similar to what is now generated by dmd -H). Key point here is that .di needs _always_ to be there, with hard guarantees that it is in sync with actual code. Add even one more extra step of getting those and it becomes considerably less convenient than C++-like overview.
Re: new DIP47: Outlining member functions of aggregates
On 10/09/13 14:12, Jacob Carlborg wrote:
verifyDeclarations would look something like this, in pseudo code:
void* verifyDeclarations (T) ()
{
static if (is(T == class))
{
foreach (member ; methods!(T))
{
static if (!hasDefinition!(member))
static assert (false, The member ' fullyQualifiedName!(T) ~
. ~ member.stringof ~ ' doesn't have a definition);
}
}
return null;
}
But the problem that I identified wasn't the possibility of members that are
declared but not defined. It was the possibility of members that are defined
but not included in the top-of-the-class list of separate declarations. The
whole point is that both the author and the recipient of the code should be able
to verify at compile-time that the list of declarations is an accurate summary
of the class.
I imagine you could define a verifySeparateDeclarations that would indeed
enforce that (for every declaration a definition, and for every definition a
separate declaration) but that would have its own issues.
Re: new DIP47: Outlining member functions of aggregates
On 9/10/13, Jacob Carlborg d...@me.com wrote: A mixin should not be necessary. RTInfo can be used for that: https://github.com/D-Programming-Language/druntime/blob/master/src/object.di#L575 The mixin was demonstrated for convenience so you don't have to manually type in the class name (or use typeof(this)).
Re: new DIP47: Outlining member functions of aggregates
On 9/10/13, Dicebot pub...@dicebot.lv wrote: Main issue of .di files that make them useless for anything but providing declarations for blobs is that there is absolutely zero compiler control of .d and .di relation. Yeah, I think we could attempt to provide an alternative to DIP47 by adding a compiler flag that verifies .d implementations match .di declarations. We don't even have to make the .d files explicitly import the .di files like Andrei proposed.
Re: new DIP47: Outlining member functions of aggregates
On Tuesday, 10 September 2013 at 13:32:14 UTC, Andrej Mitrovic wrote: On 9/10/13, Dicebot pub...@dicebot.lv wrote: Main issue of .di files that make them useless for anything but providing declarations for blobs is that there is absolutely zero compiler control of .d and .di relation. Yeah, I think we could attempt to provide an alternative to DIP47 by adding a compiler flag that verifies .d implementations match .di declarations. We don't even have to make the .d files explicitly import the .di files like Andrei proposed. Please, no compiler flags. It should be default behavior. We are speaking about fundamental binary-level application sanity here.
extern(C) declaration inside function
When you declare an extern(C) function inside a D function it
seems to continue to use D's name mangling, which is unexpected
for me. For instance:
void main()
{
extern(C) void foo(int);
foo(42);
}
Undefined symbols for architecture x86_64:
__D4test4mainFZv3fooUiZv, referenced from:
__Dmain in test.o
Is this a bug?
Re: new DIP47: Outlining member functions of aggregates
Walter Bright: Outlining of member functions is the practice of placing the declaration of a member function in the struct/class/union, and placing the definition of it at global scope in the module or even in another module. http://wiki.dlang.org/DIP47 I was away and very busy, I have read only part of the answers in this thread. I don't like this DIP. If this DIP passes I am probably not going to use this feature in my code. Go and Python show that it's good to minimize the number of trivially different ways to write code in a language. This DIP does the opposite. or even in another module. This is not a good idea. If you rely on tools to make the code _readable_, In my opinion this DIP makes the code less readable, and makes the code less DRY. 3. Parameter names need not match. This seems bad. What's the rationale for this? (One perhaps acceptable solution is to put no parameter names in the signature inside the class). Generally I suggest to fix the biggest module system bugs before modifying the design of related features, like the ones discussed in DIP47. - Daniel Murphy: Let's solve a documentation issue with documentation improvements. This seems one better solution to the problem. But I also suggest people here to read and discuss about the post written by Andrei that touches deeper issues. The module system is currently significantly buggy, and it needs a principled design before trying to add DIP47. - Manu: People make claims like write better code, split it up better, document your code better, The D compiler could be modified a bit to generate a bare bones documentation even with not even a comment written in the code. Bye, bearophile
Re: review queue: next?
On Tuesday, 10 September 2013 at 12:09:42 UTC, Robert Schadek wrote: On 09/10/2013 01:43 PM, Dicebot wrote: You should add it to http://wiki.dlang.org/Review_Queue then, there is also a link to an old review thread of `std.log` by Jose Armando Garcia which may be of interest to you as people are likely to ask similar questions :) done and done (the design of my logger is based on what I distilled from the old discussion) Thanks! You will be next after Brian then (pardon me for wanting std.d.lexer so much :P)
overloaded extern(C) called without error
I know that extern(C) functions cannot be legally overloaded, but
not issuing an error in the following situation seems wrong / a
bug:
extern(C) void foo(int);
extern(C) void foo() {}
void main()
{
foo(42);
}
Re: overloaded extern(C) called without error
I just realized I wasn't clear -- it calls the (wrong) overloaded
function:
extern(C) void foo(int);
extern(C) void foo() { writeln(yes, this is called); }
void main()
{
foo(42);
}
outputs:
yes, this is called
Re: new DIP47: Outlining member functions of aggregates
On Tuesday, 10 September 2013 at 13:49:21 UTC, bearophile wrote: Walter Bright: clip 3. Parameter names need not match. This seems bad. What's the rationale for this? (One perhaps acceptable solution is to put no parameter names in the signature inside the class). I am sure there is a good reason for having no parameter names in a declaration, but to me this doesn't make much sense. If people want separate declaration/definition so that they can get an idea of what a class does, then for non-trivial functions if the variable names are omitted then your more or less have to look at the definition anyway. I must admit whenever I come across such declarations in code I am reading I always find them kind of irritating. Apart from functions with say variadic parameter lists, is this really all that useful? clip The D compiler could be modified a bit to generate a bare bones documentation even with not even a comment written in the code. Bye, bearophile I agree on this last point.
Re: new DIP47: Outlining member functions of aggregates
Craig Dillabaugh: Apart from functions with say variadic parameter lists, is this really all that useful? There are rare situations when you need to add a certain argument to the function signature, but you don't need to use that argument inside the method/function. This happens for example because of code evolution. In such cases not giving a name to the argument is good, you avoid introducing a useless and unused variable name, making the code simpler, safer, and more clear. Bye, bearophile
Re: overloaded extern(C) called without error
On Tuesday, 10 September 2013 at 14:07:18 UTC, Luís Marques wrote:
I just realized I wasn't clear -- it calls the (wrong)
overloaded function:
extern(C) void foo(int);
extern(C) void foo() { writeln(yes, this is called); }
void main()
{
foo(42);
}
outputs:
yes, this is called
This is why mixing ABI and mangling in one entity is bad. And why
overloading extern(C) functions is compile-time error in C++.
Re: new DIP47: Outlining member functions of aggregates
On Tuesday, 10 September 2013 at 14:15:19 UTC, bearophile wrote: Craig Dillabaugh: Apart from functions with say variadic parameter lists, is this really all that useful? There are rare situations when you need to add a certain argument to the function signature, but you don't need to use that argument inside the method/function. This happens for example because of code evolution. In such cases not giving a name to the argument is good, you avoid introducing a useless and unused variable name, making the code simpler, safer, and more clear. Bye, bearophile It is never the case in the declaration though. You always want parameter names there, to reference them in DDOC comment at the very least.
Re: new DIP47: Outlining member functions of aggregates
On Tuesday, 10 September 2013 at 14:15:19 UTC, bearophile wrote: Craig Dillabaugh: Apart from functions with say variadic parameter lists, is this really all that useful? There are rare situations when you need to add a certain argument to the function signature, but you don't need to use that argument inside the method/function. This happens for example because of code evolution. In such cases not giving a name to the argument is good, you avoid introducing a useless and unused variable name, making the code simpler, safer, and more clear. Bye, bearophile I think using calling the variable 'dummy' would likely do the trick in those instances, but this makes sense.
Re: new DIP47: Outlining member functions of aggregates
On 09/09/13 16:29, Dicebot wrote: On Monday, 9 September 2013 at 14:22:15 UTC, Joseph Rushton Wakeling wrote: Then it simply becomes a question of deciding if the manual labour of writing separate outlines and definitions is worth it. I guess this is probably somewhere where a tool really _can_ be useful, to ensure that the definitions and the outline stay in sync. Writing D code in this way should probably be disapproved of in the D style guidelines, but with the proviso that it's there for the circumstances where it really is useful. Very well spoken, this is exactly how I see it. Thank you! :-)
Re: overloaded extern(C) called without error
On Tuesday, 10 September 2013 at 14:04:58 UTC, Luís Marques wrote:
extern(C) void foo(int);
extern(C) void foo() {}
I agree that this should not be legal. LDC detects this in the
glue layer (we would have to add a workaround for the
corresponding LLVM restriction otherwise):
---
$ ldc2 test.d
test.d(4): Error: Function type does not match previously
declared function with the same mangled name: foo
---
David
Re: Move VisualD to github/d-programming-language ?
On Saturday, 7 September 2013 at 19:05:03 UTC, Walter Bright wrote: Recent threads here have made it pretty clear that VisualD is a critical piece of D infrastructure. (VisualD integrated D usage into Microsoft Visual Studio.) Andrei, myself and Rainer (VisualD's champion) are all in agreement on this. What do you think? Since it's official I think it'd be nice to add to the Windows Installer. I'll get started adding it if you or Andrei give me the go ahead. Once dub is a bit more mature I think it too should be added to the installer.
Re: Move VisualD to github/d-programming-language ?
On 9/10/13 2:46 AM, Walter Bright wrote: On 9/10/2013 1:02 AM, Jacob Carlborg wrote: Rainer was asking if anyone have experience with migrating Trac issues to bugzilla. Bugzilla does have an API. The question is it enabled for the D bugzilla. I don't know. Brad Roberts runs Bugzilla. I'll forward this to him. I believe so.. it's part of the standard install. The only issue might be that the version we're running is significantly out of date.
Re: Move VisualD to github/d-programming-language ?
On 9/10/13 9:31 AM, Brad Anderson wrote: On Saturday, 7 September 2013 at 19:05:03 UTC, Walter Bright wrote: Recent threads here have made it pretty clear that VisualD is a critical piece of D infrastructure. (VisualD integrated D usage into Microsoft Visual Studio.) Andrei, myself and Rainer (VisualD's champion) are all in agreement on this. What do you think? Since it's official I think it'd be nice to add to the Windows Installer. I'll get started adding it if you or Andrei give me the go ahead. Yes please. Make it an opt-out choice. Once dub is a bit more mature I think it too should be added to the installer. That should probably be in all installers. Andrei
Not with the scene…
Perhaps I am late to the party, but clearly all the meta-data associated with packages managed by Dub are Dub Records. Groan. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: review queue: next?
On Tuesday, 10 September 2013 at 13:45:37 UTC, Dicebot wrote: On Tuesday, 10 September 2013 at 12:09:42 UTC, Robert Schadek wrote: On 09/10/2013 01:43 PM, Dicebot wrote: You should add it to http://wiki.dlang.org/Review_Queue then, there is also a link to an old review thread of `std.log` by Jose Armando Garcia which may be of interest to you as people are likely to ask similar questions :) done and done (the design of my logger is based on what I distilled from the old discussion) Thanks! You will be next after Brian then (pardon me for wanting std.d.lexer so much :P) https://github.com/Hackerpilot/phobos/tree/master/std/d I'll work on increasing the test coverage later this evening.
Re: Move VisualD to github/d-programming-language ?
On 9/10/13 11:37 AM, Jonathan M Davis wrote: On Tuesday, September 10, 2013 18:31:11 Brad Anderson wrote: Once dub is a bit more mature I think it too should be added to the installer. I would expect that to only happen if it became the official package manager, which AFAIK hasn't even been discussed recently let alone actually happened. But its usage is on the rise, and I could definitely see it becoming the official package manager at some point. Maybe the time has come to discuss that. Should we make dub the official package manager for D? Andrei
Re: Move VisualD to github/d-programming-language ?
On Tuesday, September 10, 2013 18:31:11 Brad Anderson wrote: Once dub is a bit more mature I think it too should be added to the installer. I would expect that to only happen if it became the official package manager, which AFAIK hasn't even been discussed recently let alone actually happened. But its usage is on the rise, and I could definitely see it becoming the official package manager at some point. - Jonathan M Davis
Re: Move VisualD to github/d-programming-language ?
On Tuesday, 10 September 2013 at 18:54:10 UTC, Andrei Alexandrescu wrote: On 9/10/13 11:37 AM, Jonathan M Davis wrote: On Tuesday, September 10, 2013 18:31:11 Brad Anderson wrote: Once dub is a bit more mature I think it too should be added to the installer. I would expect that to only happen if it became the official package manager, which AFAIK hasn't even been discussed recently let alone actually happened. But its usage is on the rise, and I could definitely see it becoming the official package manager at some point. Maybe the time has come to discuss that. Should we make dub the official package manager for D? Andrei I asked Sönke about this back when dub was called VPM (so a lot of the answer is out of date now). His reply: http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/post/79 It'd be nice if he could update with what he thinks is left before it'd be ready to be the official package manager. I've hit a bug here or there in my own usage of dub but overall I find it to be very good (and Sönke usually fixes things I've hit in less than a day). There is a potential package format switch to Simple Declarative Language that should probably come before dub is official and some general final polishing but overall it feels really close to being ready to me.
Re: Move VisualD to github/d-programming-language ?
10-Sep-2013 22:54, Andrei Alexandrescu пишет: On 9/10/13 11:37 AM, Jonathan M Davis wrote: On Tuesday, September 10, 2013 18:31:11 Brad Anderson wrote: Once dub is a bit more mature I think it too should be added to the installer. I would expect that to only happen if it became the official package manager, which AFAIK hasn't even been discussed recently let alone actually happened. But its usage is on the rise, and I could definitely see it becoming the official package manager at some point. Maybe the time has come to discuss that. Should we make dub the official package manager for D? Good idea, seeing as it's the only one being actively worked. Plus it seems to have really caught on. -- Dmitry Olshansky
Re: Move VisualD to github/d-programming-language ?
On Tuesday, 10 September 2013 at 18:54:10 UTC, Andrei Alexandrescu wrote: On 9/10/13 11:37 AM, Jonathan M Davis wrote: On Tuesday, September 10, 2013 18:31:11 Brad Anderson wrote: Once dub is a bit more mature I think it too should be added to the installer. I would expect that to only happen if it became the official package manager, which AFAIK hasn't even been discussed recently let alone actually happened. But its usage is on the rise, and I could definitely see it becoming the official package manager at some point. Maybe the time has come to discuss that. Should we make dub the official package manager for D? Andrei Well, it has almost become one de-facto.
Re: Move VisualD to github/d-programming-language ?
On Tuesday, 10 September 2013 at 19:48:58 UTC, Joseph Rushton Wakeling wrote: On 10/09/13 20:54, Andrei Alexandrescu wrote: Maybe the time has come to discuss that. Should we make dub the official package manager for D? Question from a complete non-user of dub -- how does it determine which D compiler(s) to install libraries for/with? I almost never use DMD for anything apart from work on Phobos, but I alternate frequently between GDC and LDC. I'd need a package manager that would play nice with that kind of switching and swapping. --compiler=gdc/ldc is all you need to do to use compilers other than dmd. It doesn't normally install packages into the compiler's existing library/source search paths but rather specifies the path to dependencies during building. Packages are normally installed to somewhere in your user directory (I can't remember where exactly, somewhere like ~dub/packages). You can also install packages as a directory in the current directory (--local) or system wide (--system). I find the default behavior works just fine for me though.
Re: Move VisualD to github/d-programming-language ?
On 10/09/13 20:54, Andrei Alexandrescu wrote: Maybe the time has come to discuss that. Should we make dub the official package manager for D? Question from a complete non-user of dub -- how does it determine which D compiler(s) to install libraries for/with? I almost never use DMD for anything apart from work on Phobos, but I alternate frequently between GDC and LDC. I'd need a package manager that would play nice with that kind of switching and swapping.
Re: dub: should we make it the de jure package manager for D?
On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei Alexandrescu wrote: We've been experimenting with http://code.dlang.org for a while and things are going well. In particular Sönke has been very active about maintaining and improving it, which brings further confidence in the future of the project. We're considering making dub the official package manager for D. What do you all think? Andrei I vote yes but only if Sönke feels it is ready. I suspect he has a few things he'll probably want done before this happens (the potential switch from JSON to SDL comes to mind).
Re: Not with the scene…
On Tue, 10 Sep 2013 16:34:47 -0400 Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: On Tue, 10 Sep 2013 19:26:48 +0100 Russel Winder rus...@winder.org.uk wrote: Perhaps I am late to the party, but clearly all the meta-data associated with packages managed by Dub are Dub Records. Groan. Heh, took me awhile to release what you were saying here. s/release/realize --- apparently needs coffee But don't worry, as long as it isn't Bro Step.
Re: Not with the scene…
On Tue, 10 Sep 2013 19:26:48 +0100 Russel Winder rus...@winder.org.uk wrote: Perhaps I am late to the party, but clearly all the meta-data associated with packages managed by Dub are Dub Records. Groan. Heh, took me awhile to release what you were saying here. But don't worry, as long as it isn't Bro Step.
Re: Move VisualD to github/d-programming-language ?
On Tuesday, September 10, 2013 11:54:10 Andrei Alexandrescu wrote: Maybe the time has come to discuss that. Should we make dub the official package manager for D? Fine with me, though we should probably create a new thread for that as a lot of people wouldn't notice it in this thread, which is already fairly long. - Jonathan M Davis
Re: Not with the scene…
On 9/10/13, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: s/release/realize --- apparently needs coffee Realize the kraken!
Re: dub: should we make it the de jure package manager for D?
Am 10.09.2013 22:48, schrieb Andrei Alexandrescu: We've been experimenting with http://code.dlang.org for a while and things are going well. In particular Sönke has been very active about maintaining and improving it, which brings further confidence in the future of the project. We're considering making dub the official package manager for D. What do you all think? Andrei I think it is a good idea. Even if there are rough edges, it can be improved later on based on the community experience with it. -- Paulo
Re: dub: should we make it the de jure package manager for D?
On Tue, 10 Sep 2013 23:01:12 +0200 Brad Anderson e...@gnuk.net wrote: I vote yes but only if Sönke feels it is ready. I suspect he has a few things he'll probably want done before this happens (the potential switch from JSON to SDL comes to mind). I assume that would be a backwards-compatible change. Make SDL the preferred, but keep JSON in service.
dub: should we make it the de jure package manager for D?
We've been experimenting with http://code.dlang.org for a while and things are going well. In particular Sönke has been very active about maintaining and improving it, which brings further confidence in the future of the project. We're considering making dub the official package manager for D. What do you all think? Andrei
Re: Not with the scene…
On Tuesday, 10 September 2013 at 21:11:37 UTC, Jonathan M Davis wrote: On Tuesday, September 10, 2013 16:34:47 Nick Sabalausky wrote: On Tue, 10 Sep 2013 19:26:48 +0100 Russel Winder rus...@winder.org.uk wrote: Perhaps I am late to the party, but clearly all the meta-data associated with packages managed by Dub are Dub Records. Groan. Heh, took me awhile to release what you were saying here. Whereas I have absolutely no idea... :( - Jonathan M Davis http://en.wikipedia.org/wiki/Dub_(music) http://en.wikipedia.org/wiki/LP_record
Re: Not with the scene…
On Tuesday, September 10, 2013 23:14:15 Brad Anderson wrote: On Tuesday, 10 September 2013 at 21:11:37 UTC, Jonathan M Davis wrote: On Tuesday, September 10, 2013 16:34:47 Nick Sabalausky wrote: On Tue, 10 Sep 2013 19:26:48 +0100 Russel Winder rus...@winder.org.uk wrote: Perhaps I am late to the party, but clearly all the meta-data associated with packages managed by Dub are Dub Records. Groan. Heh, took me awhile to release what you were saying here. Whereas I have absolutely no idea... :( - Jonathan M Davis http://en.wikipedia.org/wiki/Dub_(music) http://en.wikipedia.org/wiki/LP_record I know about LPs, but I didn't know that dub was a genre of music. - Jonathan M Davis
Re: dub: should we make it the de jure package manager for D?
On 09/10/2013 04:48 PM, Andrei Alexandrescu wrote: We've been experimenting with http://code.dlang.org for a while and things are going well. In particular Sönke has been very active about maintaining and improving it, which brings further confidence in the future of the project. We're considering making dub the official package manager for D. What do you all think? Andrei votes++ over here From my usage of it, it still has a couple of things that are in development (a bit more of a user manual would be nice but I can attempt to make one in my free time), but it's in a state now where it's definitely usable for projects. A friend and I are planning on making a little project for a game jam this weekend, we'll try using dub and see what happens, but so far I'd definitely say yes -Matt Soucy signature.asc Description: OpenPGP digital signature
Re: dub: should we make it the de jure package manager for D?
How ready is it? 1) bus factor.. what happens if Sonke disappears? 2) backups? 3) scaleability? etc? On 9/10/13 1:48 PM, Andrei Alexandrescu wrote: We've been experimenting with http://code.dlang.org for a while and things are going well. In particular Sönke has been very active about maintaining and improving it, which brings further confidence in the future of the project. We're considering making dub the official package manager for D. What do you all think? Andrei
Re: Not with the scene…
On Tuesday, September 10, 2013 16:34:47 Nick Sabalausky wrote: On Tue, 10 Sep 2013 19:26:48 +0100 Russel Winder rus...@winder.org.uk wrote: Perhaps I am late to the party, but clearly all the meta-data associated with packages managed by Dub are Dub Records. Groan. Heh, took me awhile to release what you were saying here. Whereas I have absolutely no idea... :( - Jonathan M Davis
Re: Not with the scene…
Am 10.09.2013 23:17, schrieb Jonathan M Davis: On Tuesday, September 10, 2013 23:14:15 Brad Anderson wrote: On Tuesday, 10 September 2013 at 21:11:37 UTC, Jonathan M Davis wrote: On Tuesday, September 10, 2013 16:34:47 Nick Sabalausky wrote: On Tue, 10 Sep 2013 19:26:48 +0100 Russel Winder rus...@winder.org.uk wrote: Perhaps I am late to the party, but clearly all the meta-data associated with packages managed by Dub are Dub Records. Groan. Heh, took me awhile to release what you were saying here. Whereas I have absolutely no idea... :( - Jonathan M Davis http://en.wikipedia.org/wiki/Dub_(music) http://en.wikipedia.org/wiki/LP_record I know about LPs, but I didn't know that dub was a genre of music. - Jonathan M Davis Really?!? It is quite popular in Europe.
Re: Not with the scene…
On Tuesday, 10 September 2013 at 21:17:23 UTC, Jonathan M Davis wrote: On Tuesday, September 10, 2013 23:14:15 Brad Anderson wrote: On Tuesday, 10 September 2013 at 21:11:37 UTC, Jonathan M Davis wrote: On Tuesday, September 10, 2013 16:34:47 Nick Sabalausky wrote: On Tue, 10 Sep 2013 19:26:48 +0100 Russel Winder rus...@winder.org.uk wrote: Perhaps I am late to the party, but clearly all the meta-data associated with packages managed by Dub are Dub Records. Groan. Heh, took me awhile to release what you were saying here. Whereas I have absolutely no idea... :( - Jonathan M Davis http://en.wikipedia.org/wiki/Dub_(music) http://en.wikipedia.org/wiki/LP_record I know about LPs, but I didn't know that dub was a genre of music. - Jonathan M Davis Think slow reggae with loads of echo
Re: Not with the scene…
On Tuesday, 10 September 2013 at 21:05:25 UTC, Andrej Mitrovic wrote: On 9/10/13, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: s/release/realize --- apparently needs coffee Realize the kraken! Always associated this http://www.krakenrum.com/ for me =)
Re: Move VisualD to github/d-programming-language ?
On 9/9/2013 11:35 AM, Russel Winder wrote:
C++11 has revitalized C++ in ways that are only just showing themselves.
That's true.
This is a threat to D gaining traction.
I'm less sure about that. I think it presents an opportunity for us. Driving the
C++ resurgence is:
1. demand for high performance computing
2. turning back towards native languages
3. recognition of the value of functional-style programming techniques
4. recognition of the value of safety, encapsulation, etc.
But regarding the latter two points, I don't buy that the new C++ delivers. The
classic is a oneliner Andrei wrote:
void fun() noexcept { throw so sue me; }
noexcept means the function doesn't throw any exceptions. But it doesn't check!
The above code compiles, and then fails at runtime. The opportunity for D is to
deliver what C++ has promised.
Re: Should we make dub the official package manager for D?
On Tuesday, 10 September 2013 at 21:51:07 UTC, Walter Bright wrote: Please discuss here, not in the VisualD thread. Andrei made a dedicated thread here: http://forum.dlang.org/post/l0o0jq$gvp$1...@digitalmars.com
Re: Not with the scene…
On Tue, 10 Sep 2013 23:23:48 +0200 Paulo Pinto pj...@progtools.org wrote: Really?!? It is quite popular in Europe. Europe has good taste in music. Example: Almost anytime I watch Top Gear, I notice them using great songs that I recognize from my own collection that you almost never hear played here in the US. Stuff like Prodigy or Crystal Method, for example.
Should we make dub the official package manager for D?
Please discuss here, not in the VisualD thread.
Re: Move VisualD to github/d-programming-language ?
On 9/10/2013 11:54 AM, Andrei Alexandrescu wrote: Maybe the time has come to discuss that. Should we make dub the official package manager for D? Akk, please start a new thread for that!
