finally using D at work
As a long time D fanboy I was known to say That is quite simple in D a lot at work! Now I was finally able to convience my boss (our CTO) to take a serious look at D as a replacement for the parts of our infrastructure that use nodejs right now. After my series of blog posts about this topic and a short presentation I did in the office he finally announced quite publicly today that we are in fact going to use D: https://twitter.com/Mavwarf/status/432962351059316736 So our next online game will be powered by some parts in D ;) Yay! Exciting times!
Re: finally using D at work
On Monday, 10 February 2014 at 19:56:57 UTC, extrawurst wrote: As a long time D fanboy I was known to say That is quite simple in D a lot at work! Now I was finally able to convience my boss (our CTO) to take a serious look at D as a replacement for the parts of our infrastructure that use nodejs right now. After my series of blog posts about this topic and a short presentation I did in the office he finally announced quite publicly today that we are in fact going to use D: https://twitter.com/Mavwarf/status/432962351059316736 So our next online game will be powered by some parts in D ;) Yay! Exciting times! Congrats, and let us know what bindings are missing ;)
Re: finally using D at work
On 2/10/2014 11:56 AM, extrawurst wrote: As a long time D fanboy I was known to say That is quite simple in D a lot at work! Now I was finally able to convience my boss (our CTO) to take a serious look at D as a replacement for the parts of our infrastructure that use nodejs right now. After my series of blog posts about this topic and a short presentation I did in the office he finally announced quite publicly today that we are in fact going to use D: https://twitter.com/Mavwarf/status/432962351059316736 So our next online game will be powered by some parts in D ;) Yay! Exciting times! Yes, this is great news! Thanks for letting us know.
Re: finally using D at work
On 02/10/2014 02:56 PM, extrawurst wrote: So our next online game will be powered by some parts in D ;) Cool!
Re: finally using D at work
Am 10.02.2014 20:56, schrieb extrawurst: As a long time D fanboy I was known to say That is quite simple in D a lot at work! Now I was finally able to convience my boss (our CTO) to take a serious look at D as a replacement for the parts of our infrastructure that use nodejs right now. After my series of blog posts about this topic and a short presentation I did in the office he finally announced quite publicly today that we are in fact going to use D: https://twitter.com/Mavwarf/status/432962351059316736 So our next online game will be powered by some parts in D ;) Yay! Exciting times! Congratulations! Good luck!
Re: dmd 2.065 beta 3
I gave beta 3 on my win32 dev machine a try today and noticed that building vibe.d (a dependancy in almost all my projects) takes noticeably longer to built. observing the process shows that beta3 consumes almost 1.5GB of RAM while dmd 2.064 'just' uses 1GB.
Re: finally using D at work
On 02/10/2014 11:56 AM, extrawurst wrote: So our next online game will be powered by some parts in D ;) Congratulations! Please consider updating the following page http://wiki.dlang.org/Current_D_Use Ali
Re: finally using D at work
Can you share the D presentation material you used at work? It would be great to also share this with other game development companies that are interested.
Re: dmd 2.065 beta 3
On 02/10/2014 10:24 PM, extrawurst wrote: I gave beta 3 on my win32 dev machine a try today and noticed that building vibe.d (a dependancy in almost all my projects) takes noticeably longer to built. observing the process shows that beta3 consumes almost 1.5GB of RAM while dmd 2.064 'just' uses 1GB. Is this optimized? I had the impression that compiling diet templates in optimized builds now takes much longer, but I might be wrong.
early alpha of D REPL
Barely running but already fun and a little useful.
Example:
D import std.algorithm, std.array, std.file;
= std
D auto name(T)(T t) {
| return t.name;
| }
= name
D dirEntries(., SpanMode.depth).map!name.join(, )
= ./drepl_sandbox
D
https://github.com/MartinNowak/drepl
http://drepl.dawg.eu/
Re: early alpha of D REPL
On Tuesday, 11 February 2014 at 04:46:41 UTC, Martin Nowak wrote:
Barely running but already fun and a little useful.
Example:
D import std.algorithm, std.array, std.file;
= std
D auto name(T)(T t) {
| return t.name;
| }
= name
D dirEntries(., SpanMode.depth).map!name.join(, )
= ./drepl_sandbox
D
https://github.com/MartinNowak/drepl
http://drepl.dawg.eu/
As I understand it, you are executing dmd in the background to
repl. Simple and clever :D
Re: early alpha of D REPL
On Tuesday, 11 February 2014 at 08:15:55 UTC, Martin Nowak wrote:
On Tuesday, 11 February 2014 at 05:37:45 UTC, Andrei
Alexandrescu wrote:
As I understand it, you are executing dmd in the background
to repl.
Simple and clever :D
But then how is it saving context?
Andrie
It's using shared libraries to do so. Each new deck/stmt/expr
is compiled in a shared library. This library imports and links
against all previous libraries to make the context available.
I still need to implement a few rewrites, i.e. `auto var =
val;` should become `typeof(val) var; shared static this() {
var = val; }` too support runtime initialization.
Thats a nifty trick!
Re: early alpha of D REPL
On Tuesday, 11 February 2014 at 08:49:56 UTC, extrawurst wrote:
On Tuesday, 11 February 2014 at 08:15:55 UTC, Martin Nowak
wrote:
On Tuesday, 11 February 2014 at 05:37:45 UTC, Andrei
Alexandrescu wrote:
As I understand it, you are executing dmd in the background
to repl.
Simple and clever :D
But then how is it saving context?
Andrie
It's using shared libraries to do so. Each new deck/stmt/expr
is compiled in a shared library. This library imports and
links against all previous libraries to make the context
available.
I still need to implement a few rewrites, i.e. `auto var =
val;` should become `typeof(val) var; shared static this() {
var = val; }` too support runtime initialization.
Thats a nifty trick!
Did I just kill it ?
After playing around the site is not responding anymore :( I am
sorry
Re: early alpha of D REPL
On 2/10/14, 9:01 PM, deadalnix wrote:
On Tuesday, 11 February 2014 at 04:46:41 UTC, Martin Nowak wrote:
Barely running but already fun and a little useful.
Example:
D import std.algorithm, std.array, std.file;
= std
D auto name(T)(T t) {
| return t.name;
| }
= name
D dirEntries(., SpanMode.depth).map!name.join(, )
= ./drepl_sandbox
D
https://github.com/MartinNowak/drepl
http://drepl.dawg.eu/
As I understand it, you are executing dmd in the background to repl.
Simple and clever :D
But then how is it saving context?
Andrie
Re: early alpha of D REPL
On Tuesday, 11 February 2014 at 05:37:45 UTC, Andrei Alexandrescu
wrote:
As I understand it, you are executing dmd in the background to
repl.
Simple and clever :D
But then how is it saving context?
Andrie
It's using shared libraries to do so. Each new deck/stmt/expr is
compiled in a shared library. This library imports and links
against all previous libraries to make the context available.
I still need to implement a few rewrites, i.e. `auto var = val;`
should become `typeof(val) var; shared static this() { var = val;
}` too support runtime initialization.
Re: finally using D at work
On Monday, 10 February 2014 at 23:03:15 UTC, Ali Çehreli wrote: On 02/10/2014 11:56 AM, extrawurst wrote: So our next online game will be powered by some parts in D ;) Congratulations! Please consider updating the following page http://wiki.dlang.org/Current_D_Use Ali Done, thanks for the hint!
Re: early alpha of D REPL
Have you seen Dabble? https://github.com/callumenator/dabble Just found out its author added Linux support. I was able to build an x86 version but it didn't work properly in a 64 bit system: it assumes dmd makes x86 binaries by default while it really makes 64-bit ones. And for 64 bits Dabble doesn't compile: as it often happens, it's too easy to forget that array.length is not always uint.
Re: finally using D at work
Congrats! I'm green with envy. Atila On Monday, 10 February 2014 at 19:56:57 UTC, extrawurst wrote: As a long time D fanboy I was known to say That is quite simple in D a lot at work! Now I was finally able to convience my boss (our CTO) to take a serious look at D as a replacement for the parts of our infrastructure that use nodejs right now. After my series of blog posts about this topic and a short presentation I did in the office he finally announced quite publicly today that we are in fact going to use D: https://twitter.com/Mavwarf/status/432962351059316736 So our next online game will be powered by some parts in D ;) Yay! Exciting times!
Re: DDT 0.9.0 released - GDB debugging integration
Hi Bruno,
First off, I wanted to share my appreciation for working on D
support in Eclipse and especially for introducing the debugging
capabilities with DDT - really awesome!
I started playing around with the CDT debugger for D programs and
so far got a question about D dynamic arrays.
Actually they're already supported by GDB out of box, and
indeed debugging with GDB 7.6.2 allows for the following array's
output:
code line int[] a = [7, 5];
(gdb) print a
$1 = {7, 5}
but still, if debugging the same code in Eclipse (CDT), I see:
a struct _Array_int {...}
lengthunsigned long 2
ptr int * 0x77ecdfd0
While it is definitely possible to implement some custom pretty
printers for this (and it shouldn't be that hard), I wanted to
first ask whether you have some clue about how can the D-style
array output be forced in CDT. Thanks!
Re: Scriptlike: New lib to aid in writing script-like programs
On Tuesday, 11 February 2014 at 11:38:06 UTC, Nick Sabalausky wrote: I've released a little one-module utility, Scriptlike, to help simplify writing shell script-like programs in D: https://github.com/Abscissa/scriptlike Sounds very nice and handy. I tend to write my scripts in D these days, often migrating them from Ruby, and this lib might be helpful. Thanks for putting it up!
Re: finally using D at work
On Mon, 10 Feb 2014 19:56:55 +, extrawurst wrote: As a long time D fanboy I was known to say That is quite simple in D a lot at work! Now I was finally able to convience my boss (our CTO) to take a serious look at D as a replacement for the parts of our infrastructure that use nodejs right now. After my series of blog posts about this topic and a short presentation I did in the office he finally announced quite publicly today that we are in fact going to use D: https://twitter.com/Mavwarf/status/432962351059316736 So our next online game will be powered by some parts in D ;) Yay! Exciting times! Cheers from the folks at EMSI! Justin
Re: ACCU: Wednesday, February 12 - Amaury Séchet, Multi-core Software Development Challenges and How D Helps
Reminder... Ali On 02/05/2014 09:48 PM, Ali Çehreli wrote: When: Wednesday, February 12, 2014 Topic: Multi-core Software Development Challenges and How D Helps Speaker: Amaury Séchet Time: 6:30pm doors open 7:00pm meeting begins Where: Symantec VCAFE building 350 Ellis Street (near E. Middlefield Road) Mountain View, CA 94043 Map: http://tinyurl.com/334rv5 Directions: VCAFE is accessible from the semicircular courtyard between Symantec buildings http://tinyurl.com/2dccgc Cost: Free More Info: http://www.meetup.com/SFBay-Association-of-C-C-Users/events/159565312/ Multi-core CPUs have become the norm. Most system languages predate this hardware evolution and provide poor solutions to problems that developers encounter using multi-core CPUs. The first part of this talk will introduce how multi-core CPUs work, what they are good at, and the conditions that may affect their performance negatively. The second part will look at how one system programming language takes advantage of multi-core CPUs. The D programming language learns from the mistakes of its predecessors and provides a much safer and comfortable environment to exploit multi-core machines by its default thread-local storage; immutable and shared data attributes; and parallelism, concurrency and fiber modules. Amaury Séchet is the main developer of SDC, a project aiming at providing a D compiler as a library. He currently works at Facebook as a software engineer. Upcoming ACCU meetings - Wednesday, February 26 2014 Workshop Wednesday, March 12, 2014 Sumant Tambe Fun with Functions The C++14-style Wednesday, March 26, 2014 Workshop - The ACCU meets twice monthly. Meetings are always open to the public and are free of charge. To suggest topics and speakers please email Ali Cehreli via acehr...@yahoo.com
Re: Scriptlike: New lib to aid in writing script-like programs
On Tuesday, 11 February 2014 at 11:38:06 UTC, Nick Sabalausky wrote: I've released a little one-module utility, Scriptlike, to help simplify writing shell script-like programs in D: https://github.com/Abscissa/scriptlike It looks like you've covered a lot of the short comings for doing some cmdln scripting. It also sounds like it would fit right into what I was doing (I hand only covered the user input portion) https://github.com/JesseKPhillips/JPDLibs/tree/cmdln (I really probably should move it into its own project, maybe I should instead submit mine to yours? Though I use Boost License). [OT] I also want to thank those behind std.process, std.path, and std.algorithms these things have been really awesome and I use heavily (great improvements). Current Features: - A thin wrapper over std.path and std.file that provides a dedicated Path type specifically designed for managing file paths in a simple, reliable, cross-platform way. No more dealing with slashes, paths-with-spaces, calling buildPath, normalizing, or getting paths mixed up with ordinary strings. Personally I've found the new std.path makes this much easier, I'm not user how you can address paths-with-spaces as this depends on who you call, internally I don't need to worry. But maybe this simplifies it more and is still worth it. - Optionally enable automatic command echoing (including shell commands, changing/creating directories and deleting/copying/moving/linking/renaming both directories and files) by setting one simple flag: bool scriptlikeTraceCommands Command echoing, and dry run are both valuable. - Most typical Phobos modules automatically imported. Who needs rows and rows of standard lib imports for a mere script? - Less-pedantic filesystem operations for when you don't care whether it exists or not: existsAsFile, existsAsDir, existsAsSymlink, tryRename, trySymlink, tryCopy, tryMkdir, tryMkdirRecurse, tryRmdir, tryRmdirRecurse, tryRemove: All check whether the source path exists and return WITHOUT throwing if there's nothing to do. This is my biggest gripe with the current available functions! - One simple call, runShell, to run a shell command script-style (ie, synchronously with forwarded stdout/in/err) from any working directory. (Also automatically works around DMD #10863 without waiting for v2.066 - BTW, thanks all involved who fixed that.) Aside from the bug, I don't understand what this provides over execute. - One simple function, fail(string msg), to help you exit with an error message in an exception-safe way. (Does require some minor boilerplate added to your main().) I've just been using exceptions, Fail should take a return code too.
Re: early alpha of D REPL
On Tuesday, 11 February 2014 at 13:11:06 UTC, The Guest wrote:
On Tuesday, 11 February 2014 at 04:46:41 UTC, Martin Nowak
wrote:
Barely running but already fun and a little useful.
Example:
D import std.algorithm, std.array, std.file;
= std
D auto name(T)(T t) {
| return t.name;
| }
= name
D dirEntries(., SpanMode.depth).map!name.join(, )
= ./drepl_sandbox
D
https://github.com/MartinNowak/drepl
http://drepl.dawg.eu/
http://dpaste.dzfl.pl/1969487a
Works for me when playing around.
Not sure we'll ever see a real D repl.
SDC is capable to JIT whatever D it support. That mean you can
create a REPL fairly easily. This has been in my TODO list for a
while, but supporting more feature is higher priority.
Feel free to contact me is that is of interest for you (Martin,
please do as well if you think it is worth it).
Re: Scriptlike: New lib to aid in writing script-like programs
On 2/11/2014 1:52 PM, Jesse Phillips wrote: On Tuesday, 11 February 2014 at 11:38:06 UTC, Nick Sabalausky wrote: I've released a little one-module utility, Scriptlike, to help simplify writing shell script-like programs in D: https://github.com/Abscissa/scriptlike It looks like you've covered a lot of the short comings for doing some cmdln scripting. It also sounds like it would fit right into what I was doing (I hand only covered the user input portion) https://github.com/JesseKPhillips/JPDLibs/tree/cmdln (I really probably should move it into its own project, maybe I should instead submit mine to yours? Though I use Boost License). Oh yea, I hadn't even thought of user input :P. I guess I got in the habit of avoiding it in CLI apps. I remember seeing your lib for that a while back and rather liked it. I think that would fit very well into Scriptlike, as long as you don't mind it all being in the same module as the rest of scriptlike, and preferably using same formatting style (not that that's strictly important, but consistency is nice of course). As for the license, if you don't mind switching to zlib then great, just go ahead and submit a pull request if you'd like to. But I'm not married to zlib license or anything. My reasons for using zlib license are relatively minor, and I'm not opposed to switching to Boost, especially since it's already the Phobos license after all. What are your thoughts? [OT] I also want to thank those behind std.process, std.path, and std.algorithms these things have been really awesome and I use heavily (great improvements). ///ditto - A thin wrapper over std.path and std.file that provides a dedicated Path type specifically designed for managing file paths in a simple, reliable, cross-platform way. No more dealing with slashes, paths-with-spaces, calling buildPath, normalizing, or getting paths mixed up with ordinary strings. Personally I've found the new std.path makes this much easier, Yea, it *definitely* does. But at the same time, I've found I still end up mucking with slashes and such anyway for a couple reasons: 1. In simpler situations, calling buildPath sometimes just seems to make what should be trivial become more verbose than I'd like. So I don't always like to use it even when I know I should. But with Scriptlike's Path type, it's just a simple partA~partB and slashes are handled behind-the-scenes (internally via buildNormalizedPath). Can't get much less verbose than that :) Maybe not the most efficient strategy, but this is intended for shell-like scripts, so it's unlikely to be anything near a problematic bottleneck. 2. std.path (and buildPath in particular) likes to use / on Posix and \ on Windows. While this makes a lot of sense in certain ways, I find that when I do deal with paths, having all my code internally operate on forward-slashes-only often leads to much, much simpler code. The downside is that not only do I have to sanitize all my inputs to forward-slash-only, I also have to do the same for many paths I get back from std.path. And then I have to convert back to backslashes on windows if I want to display it to the user in a nice OS-correct way, or pass it to certain WinAPI functions. So with Scriptlike, I'm hoping to avoid the need to ever deal with slashes at all, because all the clutter and meticulous care of always doing it the proper std.path-way is (hopefully) hidden behind-the-scenes via the Path type. I'm not user how you can address paths-with-spaces as this depends on who you call, internally I don't need to worry. But maybe this simplifies it more and is still worth it. Path.toString() automatically quotes paths correctly when they contain spaces. So you can just pass it off to spawnShell or whatever and it's automatically all ready-to-go. Don't even need to call the std.path.escape*() funcs (which I've had trouble with on windows anyway, although DMD #10863 is apparently fixed in master now, so that should at least help). Of course, if for any reason you need to keep the path un-quoted, there's Path.toRawString() for that. Command echoing, and dry run are both valuable. Oh, dry run, of course, I didn't think of that! Some scripts may still have to take extra care to handle dry runs correctly, for example if one step relies on the result of an earlier step *actually* being executed. But Scriptlike could probably help with at least some of the work. I've added a ticket for that: https://github.com/Abscissa/scriptlike/issues/8 Do you think enabling dry run should automatically enable command echoing? - Less-pedantic filesystem operations for when you don't care whether it exists or not: existsAsFile, existsAsDir, existsAsSymlink, tryRename, trySymlink, tryCopy, tryMkdir, tryMkdirRecurse, tryRmdir, tryRmdirRecurse, tryRemove: All check whether the source path exists and return WITHOUT throwing if there's nothing to do. This is my
Re: Scriptlike: New lib to aid in writing script-like programs
On Wednesday, 12 February 2014 at 00:07:42 UTC, Nick Sabalausky wrote: As for the license, if you don't mind switching to zlib then great, just go ahead and submit a pull request if you'd like to. But I'm not married to zlib license or anything. My reasons for using zlib license are relatively minor, and I'm not opposed to switching to Boost, especially since it's already the Phobos license after all. What are your thoughts? I've been using Boost to be compatible Phobos. I haven't released anything which I feel needs a more restrictive license (zlib I think is permissive). So with Scriptlike, I'm hoping to avoid the need to ever deal with slashes at all, because all the clutter and meticulous care of always doing it the proper std.path-way is (hopefully) hidden behind-the-scenes via the Path type. Any hard coded paths I'll use / and buildPath for everything else. My experience so far has been positive on Windows (but maybe I still have some legacy conversions from the old days). Path.toString() automatically quotes paths correctly when they contain spaces. So you can just pass it off to spawnShell or whatever and it's automatically all ready-to-go. Don't even need to call the std.path.escape*() funcs (which I've had trouble with on windows anyway, although DMD #10863 is apparently fixed in master now, so that should at least help). Of course, if for any reason you need to keep the path un-quoted, there's Path.toRawString() for that. Ah, I use execute(char[][]) and pipeProcess(char[][]) these bypass the shell (it seems) and require that the arguments aren't quoted. I prefer these because: auto cmd = [dmd]; cmd ~= file.d;//... Is just a nice way to build a command. Do you think enabling dry run should automatically enable command echoing? Yes, I can't think of a reason I wouldn't want it to. - Less-pedantic filesystem operations for when you don't care whether it exists or not: existsAsFile, existsAsDir, existsAsSymlink, tryRename, trySymlink, tryCopy, tryMkdir, tryMkdirRecurse, tryRmdir, tryRmdirRecurse, tryRemove: All check whether the source path exists and return WITHOUT throwing if there's nothing to do. This is my biggest gripe with the current available functions! Yea, I'm constantly making wrappers for those things in my scripts. Finally decided to just toss them into a common lib. I *do* think std.file's pedantic behavior with those does make a lot of sense in the general case. I'm not sure that I'd even want std.file to relax those checks by default. But for simple shell-script-like stuff, it does tend to be more bother than benefit. Yeah, going back to being strict is harder. - One simple call, runShell, to run a shell command script-style (ie, synchronously with forwarded stdout/in/err) from any working directory. (Also automatically works around DMD #10863 without waiting for v2.066 - BTW, thanks all involved who fixed that.) Aside from the bug, I don't understand what this provides over execute. First of all, spawn(Process|Shell)().wait() is a better comparison for runShell than execute(Process|Shell). The execute functions, at least by default, hide the child's stdout/stderr. Granted, execute does capture the child's stdout, so you *could* output it yourself afterwords, but then the user doesn't see the output in real-time (and forget about anything interactive), so that's not a good solution. Hmm, I've been needing to retain the output and do things with it quite a bit. Haven't played with it, but you may be able to get interaction by using pipeProcess, but then there is just more work to make it act like spawn. - runShell optionally takes a Path to use as the initial working directory to launch the process from (and then uses scope(exit) to automatically chdir back when the process finishes). Nothing in std.process does that right now, although there is a request in bugzilla for it: http://d.puremagic.com/issues/show_bug.cgi?id=11363 That is likely quite useful. Plus there's the automatic command echoing (not that I couldn't do that in some more direct std.process wrappers, like I do for certain std.file functions). I wonder if a generic wrapper could be created to handle this.
Re: Scriptlike: New lib to aid in writing script-like programs
On Wednesday, 12 February 2014 at 00:07:42 UTC, Nick Sabalausky wrote: I think that would fit very well into Scriptlike, as long as you don't mind it all being in the same module as the rest of scriptlike, and preferably using same formatting style (not that that's strictly important, but consistency is nice of course). Forgot that I wanted to say, I think considering the goals of the files it may be reasonable to have them separate. Solving the extra import can be done with something like package.d, but maybe you also want to reduce file count for some reason?
Re: finally using D at work
On 11 February 2014 05:56, extrawurst step...@extrawurst.org wrote: As a long time D fanboy I was known to say That is quite simple in D a lot at work! Now I was finally able to convience my boss (our CTO) to take a serious look at D as a replacement for the parts of our infrastructure that use nodejs right now. After my series of blog posts about this topic and a short presentation I did in the office he finally announced quite publicly today that we are in fact going to use D: https://twitter.com/Mavwarf/status/432962351059316736 So our next online game will be powered by some parts in D ;) Yay! Exciting times! Congrats! Looking forward to your dconf talk next year! ;)
Re: Scriptlike: New lib to aid in writing script-like programs
On 2/11/2014 8:01 PM, Jesse Phillips wrote:
On Wednesday, 12 February 2014 at 00:07:42 UTC, Nick Sabalausky wrote:
As for the license, if you don't mind switching to zlib then great,
just go ahead and submit a pull request if you'd like to. But I'm not
married to zlib license or anything. My reasons for using zlib license
are relatively minor, and I'm not opposed to switching to Boost,
especially since it's already the Phobos license after all. What are
your thoughts?
I've been using Boost to be compatible Phobos. I haven't released
anything which I feel needs a more restrictive license (zlib I think is
permissive).
zlib's about as permissive (and easy to read) as it gets without going
all the way to the Do WTF You Want license (which I actually use for
REALLY trivial things)
It's basically like a re-worded MIT license:
http://opensource.org/licenses/Zlib
So with Scriptlike, I'm hoping to avoid the need to ever deal with
slashes at all, because all the clutter and meticulous care of always
doing it the proper std.path-way is (hopefully) hidden
behind-the-scenes via the Path type.
Any hard coded paths I'll use / and buildPath for everything else. My
experience so far has been positive on Windows (but maybe I still have
some legacy conversions from the old days).
Yea, I like to use hardcoded / too, it's visually pleasant,
minimally-verbose and Windows usually does accept it just fine. Problem
is I can't always *rely* on paths always having / without being careful
to sanitize my inputs.
Ah, I use execute(char[][]) and pipeProcess(char[][]) these bypass the
shell (it seems) and require that the arguments aren't quoted. I prefer
these because:
Oh, that's right, it's execute, not executeProcess. I overlooked
that naming detail. And it's possible I misunderstood pipeProcess when I
looked at it before, I'll have to look again.
The *Shell ones are nice because I know I can do anything I can do on
the cmdline, like piping and redirecting and such, in just the same way
as I would the command line. Luckily it works pretty much the same on
both Windows and Bash. Although come to think of it, BSD's default shell
(which I actually quite like in certain ways - specifically, searching
through the command history) handles redirecting differently.
auto cmd = [dmd];
cmd ~= file.d;//...
Is just a nice way to build a command.
Hmm, yea, that's a good point.
In any case, I didn't necessarily intend to leave Scriptlike's process
features limited to just the current runShell, so this is all good
stuff to think about.
Do you think enabling dry run should automatically enable command
echoing?
Yes, I can't think of a reason I wouldn't want it to.
The only downside I can think of is if there *were* some reason to do
dry-run without echoing, there'd be no way to do it. Then again, I
already intended to allow a custom OutputRange sink for the echoing, so
if someone really wanted to squelch the echoing, they could just pass in
a do-nothing OutputRange. Ok, I'll do it that way then.
Hmm, I've been needing to retain the output and do things with it quite
a bit. Haven't played with it, but you may be able to get interaction by
using pipeProcess, but then there is just more work to make it act like
spawn.
Yea, that parsing the output can definitely be useful in certain cases.
I haven't really done it much yet because the old std.process couldn't
really handle it well, and since then, I either haven't needed to or
maybe I've just gotten used to avoiding it.
Actually, I've been really wanting to make a D equivalent of...I forget
the name offhand, but it's fairly well-established tcl lib specifically
designed for automating interactive text-based sessions. expect, I
think? I may do that soon, it'd fit well in Scriptlike.
- runShell optionally takes a Path to use as the initial working
directory to launch the process from (and then uses scope(exit) to
automatically chdir back when the process finishes). Nothing in
std.process does that right now, although there is a request in
bugzilla for it: http://d.puremagic.com/issues/show_bug.cgi?id=11363
That is likely quite useful.
Yea, I've needed to do that SOOO many times. I've gotten really tired of
cluttering my scripts with:
{
auto saveDir = getcwd();
chdir(somePath);
scope(exit) chdir(saveDir);
...
}
Thank goodness it's D though, otherwise that'd be much worse. Scope
guards are one of my favorite features of D. Brilliant solution.
Re: Scriptlike: New lib to aid in writing script-like programs
On 2/11/2014 8:10 PM, Jesse Phillips wrote: On Wednesday, 12 February 2014 at 00:07:42 UTC, Nick Sabalausky wrote: I think that would fit very well into Scriptlike, as long as you don't mind it all being in the same module as the rest of scriptlike, and preferably using same formatting style (not that that's strictly important, but consistency is nice of course). Forgot that I wanted to say, I think considering the goals of the files it may be reasonable to have them separate. Solving the extra import can be done with something like package.d, but maybe you also want to reduce file count for some reason? Honestly, I had a hard time deciding whether to do single-file or package.d. Package.d is great, but the (minor) downsides are: 1. If you download the source files manually (maybe someone who isn't onboard with git or dub yet?), there's more to do: Either download more than one file, or download one file and unzip. Versus just download this file and use it. 2. You still have to either pass all the files to DMD, or add an extra -Ipath to your RDMD call. Normally I'd consider both of those trivialities and wouldn't worry about them, but scripts are usually just trivial single-files anyway, so just adding any dependency at all to a script is a potential deterrent. Even if only a subconscious one. So I wanted to keep it as trivial as possible. Ordinarily, separate source files and maybe a package.d would definitely be the way to go. But the idea of expecting people to add a dependency to typically zero-dependency scripts seems like it's already a battle against inertia right from the start. So a whole package instead of one file just seems like needlessly hurting things even more. However, maybe I could get the best of both worlds... What if it was maintained as separate source files, with a package.d, but then I had a pre-commit hook to run a script that combined it all into one file (just stripping out the module ; statements)? Pre-commit hooks, unfortunately, can't be included in the repository, so it wouldn't run for contributors (unless they went to the bother of setting it up), but I wouldn't mind doing it myself after merging pull requests. Then again, maybe *that* complication could scare people off (esp. contributors), and maybe I'm worrying too much about the subconscious (or conscious) resistance to including external dependencies into trivial scripts?
Re: early alpha of D REPL
On 02/11/2014 04:24 PM, Martin Nowak wrote: No problem :), it's the most important TODO right now to prevent this. https://github.com/MartinNowak/drepl/blob/master/examples/server.d#L34 I wish SELinux was simpler, but it isn't. So instead of using a TCP socket, I quickfixed this issue by polling non-blocking process pipes https://github.com/MartinNowak/drepl/commit/1aef9acedb4ee4ee7cdcceda56796aba6d460cbe.
Re: Scriptlike: New lib to aid in writing script-like programs
Personally the biggest problem I have are libraries which depend on other libraries. A few of my scripts ended up growing a library I chopped off, but I haven't come up with a way to segregate it from needing XML/ini/cmdln libraries too. On Wednesday, 12 February 2014 at 02:15:38 UTC, Nick Sabalausky wrote: 1. If you download the source files manually (maybe someone who isn't onboard with git or dub yet?), there's more to do: Either download more than one file, or download one file and unzip. Versus just download this file and use it. Personally pulling in one file or many is the same to me. If it comes in a zip, that seems reasonable for those not gitting (git provides zipping a folder, not subfolders). 2. You still have to either pass all the files to DMD, or add an extra -Ipath to your RDMD call. That is true with the single file, so I don't see why this would be relevant. What is nice about keeping them separate is that people will be able to choose what type of script they will write. And I doubt there will be any common helper functions between these to modules.
Re: early alpha of D REPL
On Tuesday, 11 February 2014 at 11:33:53 UTC, thedeemon wrote: Have you seen Dabble? https://github.com/callumenator/dabble Just found out its author added Linux support. I was able to build an x86 version but it didn't work properly in a 64 bit system: it assumes dmd makes x86 binaries by default while it really makes 64-bit ones. And for 64 bits Dabble doesn't compile: as it often happens, it's too easy to forget that array.length is not always uint. I don't have a 64-bit tool-chain to play with, could submit those 64 bit build errors on github?
Re: Scriptlike: New lib to aid in writing script-like programs
On 2/11/2014 10:42 PM, Jesse Phillips wrote: On Wednesday, 12 February 2014 at 02:15:38 UTC, Nick Sabalausky wrote: 2. You still have to either pass all the files to DMD, or add an extra -Ipath to your RDMD call. That is true with the single file, so I don't see why this would be relevant. With DMD it's just more additional files vs fewer additional files. But that probably is an irrelevent concern after all since RDMD can just as easily be used instead. You're right of course about RDMD, not sure what I was thinking there. What is nice about keeping them separate is that people will be able to choose what type of script they will write. And I doubt there will be any common helper functions between these to modules. With scripts, I'm not sure there's much benefit to importing part of a lib vs the whole thing. But I may well just be paranoid about multiple files being a problem. Unless there's objections (don't seem to be so far) I may go ahead and split it up with a package.d. If it turns out to be an issue, I could just deal with it then.
Re: Scriptlike: New lib to aid in writing script-like programs
On Wednesday, 12 February 2014 at 04:59:11 UTC, Nick Sabalausky wrote: But I may well just be paranoid about multiple files being a problem. Unless there's objections (don't seem to be so far) I may go ahead and split it up with a package.d. If it turns out to be an issue, I could just deal with it then. Ok, I'll work on a pull request following your formatting as a separate file. You can take the merging/not merging from there.
Re: Scriptlike: New lib to aid in writing script-like programs
On 2/12/2014 12:13 AM, Jesse Phillips wrote: following your formatting as a separate file. Done, it's all separate files with a package.d now.
Re: Capturing keystrokes
Brilliant, thanks. It completely escaped me that ncurses was in the Deimos repo. Note that NCurses needs ncurses library, while Adam's terminal introduces no dependency, and is pretty much usable on both POSIX and Windows environments.
Re: Associative array mutation of a value
On Friday, 7 February 2014 at 20:22:54 UTC, Idan Arye wrote: I'm always for little helper functions, but I don't think Erlang's idiom of using maps as records is good for D. That model works well with dynamic typing, where record types are meaningless and only their structure is important(JavaScript is fine example). With static typing it's better to declare a type for the record, so whether the field you are trying to set exists or not can be checked at compile-time. The thing is, you don't always have those key at compile time.. Anyway, the discussion here is about map not record and IMHO it is a good idea to have two short functions for 'replace an existing value' and 'add a new key' then a long one for 'do both' because users tend to use short names and from a maintainability point of view, it's much better to know what was the exact intended meaning of the one who wrote the code, instead of having to guess, he wrote array[key] = value did he want to add the key or did to replace an existing key? BR, renoX
Re: Idea #1 on integrating RC with GC
On Monday, 10 February 2014 at 14:24:06 UTC, Ola Fosheim Grøstad wrote: No, I don't think it is only a matter of resources. For instance, if I had the time I would most certainly consider writing a pack-rat parser for a modified subset a D that builds an AST for clang. if I had the time. This exactly is the difference and reason why resources matter a lot.
Re: Testing some singleton implementations
On 2/10/14, Daniel Murphy yebbliesnos...@gmail.com wrote: Don't forget that __gshared static and static __gshared do different things! wat.
Re: Capturing keystrokes
On Monday, 10 February 2014 at 14:32:44 UTC, Dejan Lekic wrote: Brilliant, thanks. It completely escaped me that ncurses was in the Deimos repo. Note that NCurses needs ncurses library, while Adam's terminal introduces no dependency, and is pretty much usable on both POSIX and Windows environments. I know, but now I have the choice. Whatever suits better for the task at hand.
Re: Testing some singleton implementations
On Monday, 10 February 2014 at 16:53:35 UTC, Andrej Mitrovic wrote: On 2/10/14, Daniel Murphy yebbliesnos...@gmail.com wrote: Don't forget that __gshared static and static __gshared do different things! wat. To be more specific: WATWATWAT
One more question - an untapped audience.
What can be done to capture the attention of young people in the developing world? Probably the most effective thing would be if it were possible to edit, compile, and run D programs on a cheap Android ARM phone. Is this within the bounds of possibility? There are millions of unemployed, bored, restless, and ambitious young men out there, who have saved their all to buy a cheap smartphone. Any other ideas? Steve
Re: Idea #1 on integrating RC with GC
On Monday, 10 February 2014 at 14:47:15 UTC, Dicebot wrote: if I had the time. This exactly is the difference and reason why resources matter a lot. Yes, but there are enough people in these forums claiming that they desire a real time, production quality, better-than-c++ compiler to pull it off. But not for me alone. Lack of clear planning, communication of visions and establishing short term and long term measurable goals is not really a resource issue. It is a matter of taking those issue seriously. Basically a management issue. To me it would be reasonable to have: 1. short term goal: production level stability for what D is being used for today 2. long term goal: low latency, real time features/runtime Then work on 1 while planning milestones for point 2. I guess D1 was supposed to address 1, but nobody would start a project from scratch using D1 today.
Re: External dependencies for dmd tests
My original question still hasn't been answered.
Re: Two Questions
On Sunday, 9 February 2014 at 21:12:57 UTC, Jonathan M Davis wrote: so it's nice to have a lot of overhead (and with memory being as cheap as it is, I don't see much reason not to put as much memory in the box as it can Jonathan, you live in a different world. Memory is not cheap everywhere - maybe not even available, and not everyone - probably a minority in fact in world terms, has a recent processor, or even enough memory slots.
Re: One more question - an untapped audience.
On Monday, 10 February 2014 at 18:11:38 UTC, Steve Teale wrote: What can be done to capture the attention of young people in the developing world? Probably the most effective thing would be if it were possible to edit, compile, and run D programs on a cheap Android ARM phone. Is this within the bounds of possibility? There are millions of unemployed, bored, restless, and ambitious young men out there, who have saved their all to buy a cheap smartphone. Any other ideas? Steve A D compiler that targets JVM or Dalvik directly is my personal dream...
Re: Testing some singleton implementations
On Monday, 10 February 2014 at 14:15:58 UTC, Daniel Murphy wrote: Andrej Mitrovic wrote in message news:mailman.111.1392039607.21734.digitalmar...@puremagic.com... Yes you're right. I'm beginning to really dislike the 20 different meanings of static. :) Don't forget that __gshared static and static __gshared do different things! Care to elaborate?
Re: One more question - an untapped audience.
On Monday, 10 February 2014 at 18:11:38 UTC, Steve Teale wrote: What can be done to capture the attention of young people in the developing world? Probably the most effective thing would be if it were possible to edit, compile, and run D programs on a cheap Android ARM phone. Is this within the bounds of possibility? There are millions of unemployed, bored, restless, and ambitious young men out there, who have saved their all to buy a cheap smartphone. Any other ideas? Steve I am only 20 and am still in university so I feel like I can answer this with at least my own experiences. Personally I think D would capture the attention of more young people if it was simply easier to use. The first real language I really got into was C#(about 5-6 years ago) and I think the main reason is that it was so flipin easy to learn and get started. All I had to do to set it up was download Visual Studio and I was done... period ... The documentation was fantastic and everything was named in very intuitive ways. Most of the time when I was learning I would just ctrl+space and start scrolling through the auto-complete reading the documentation of all the functions right there in visual studio. It was soo easy. In my opinion the biggest thing holding D back by a long shot is the tooling and documentation... it is simply terrible. But thats just my opinion so I don't want anyone taking offense. Also something that would help get younger people into D was if the std lib was a little bit more expansive. Look at java and c# in my opinion they are both so popular because their std lib is so large. Younger people don't like to have to deal with non standard libraries as they just make it so much more difficult to do things especially as they are still trying to learn. The lack of a real GUI library is also a hindrance. Young people like to see results on the screen other than just text. That is why web and mobile development is so popular with young people. tldr; Tools suck, documentation sucks, std lib is small and no std GUI lib...
Re: One more question - an untapped audience.
On Monday, 10 February 2014 at 18:14:26 UTC, Dejan Lekic wrote: A D compiler that targets JVM or Dalvik directly is my personal dream... Mine too!
Re: Phobos for Review: std.buffer.scopebuffer
On Monday, 10 February 2014 at 19:31:50 UTC, Walter Bright wrote: I cannot agree with following rules to the point of throwing common sense out the window. If following the rules requires throwing common sense out of the window, perhaps it's time to change the rules.
Lists Allowing for Switching Values
Is there a way in D to have a list that allows you to shift around values? I'm creating a cache and I would like to keep a log of when an item was last accessed so when the cache shrinks or is about to overflow I can delete the items that haven't been accessed in a while. I would like to be able to push to the back and pop from the front. Do note that I would like to pop from the front, and not from the back, as I want the oldest items to be popped out. I would like the be able to search if the item is actually in the list. If no such functionality exists yet I could alternatively implement it myself; it's not crucial. I would like to be able to switch items around. This allows me when an item already in the list is accessed, I can put it back at the back, where the most recent items reside. Does such a feature exist already in D, is there perhaps a better approach about doing this?
Re: One more question - an untapped audience.
On Monday, 10 February 2014 at 19:03:22 UTC, Tofu Ninja wrote: tldr; Tools suck, documentation sucks, std lib is small and no std GUI lib... I do agree to a certain degree. std lib is not really that small, but sure it is never enough. Lack of std GUI lib, I honestly I'm perfectly fine with it. Tools on the other hand, do suck. The only way I could debug my prototype code involving std.concurrency and some OpenGL code was learning to use GDB from the command line, because GUI debuggers would fail horribly. Editors are so-so, compiler-as-a-library needs some extra time before work on it starts. Documentation is just not good enough. Perhaps I can start doing some pulls for the docs, since I'm still a n00b of the language but at least not a complete beginner anymore. Thanks God we have at least DUB. BTW: we really need to get a BIG link to dub package registry in the home page, or at least on the side bar.
Re: Phobos for Review: std.buffer.scopebuffer
On Monday, 10 February 2014 at 19:36:40 UTC, Francesco Cattoglio wrote: On Monday, 10 February 2014 at 19:31:50 UTC, Walter Bright wrote: I cannot agree with following rules to the point of throwing common sense out the window. If following the rules requires throwing common sense out of the window, perhaps it's time to change the rules. Exactly. And it should be done in a separate proposal and with own discussion. Which can possibly reveal that common senses differ a lot and thus is necessary. I personally will vote No for any new proposal that looks obviously alien from existing Phobos code, despite it being possibly very useful and desired and backed by sound reasoning.
Re: Phobos for Review: std.buffer.scopebuffer
On 2/10/2014 4:24 AM, Dicebot wrote: In general, proposal to standard library is a place where defining common rules (and conforming to them) has higher priority over any common sense. I cannot agree with following rules to the point of throwing common sense out the window.
Re: External dependencies for dmd tests
On 2/10/2014 9:51 AM, Benjamin Thaut wrote: My original question still hasn't been answered. 1. you'll need a license to redistribute any Microsoft binaries 2. you can use Digital Mars' dumpobj program which will pretty-print the CV8 info in the .obj file. I used it to develop the CV8 code.
Re: One more question - an untapped audience.
On Monday, 10 February 2014 at 18:11:38 UTC, Steve Teale wrote: What can be done to capture the attention of young people in the developing world? Probably the most effective thing would be if it were possible to edit, compile, and run D programs on a cheap Android ARM phone. Is this within the bounds of possibility? There are millions of unemployed, bored, restless, and ambitious young men out there, who have saved their all to buy a cheap smartphone. Any other ideas? Steve Don't forget the young women :) But yes, good ARM and android support would be awesome, although native code isn't exactly something that's heavily encouraged on android unfortunately. As an aside: Africa is heavily dominated by smartphones, due to the relative ease of building a mobile infrastructure v.s. a landline based model, as well as good resilience to poor/unreliable power supply.
Re: External dependencies for dmd tests
Am 10.02.2014 20:38, schrieb Walter Bright: 2. you can use Digital Mars' dumpobj program which will pretty-print the CV8 info in the .obj file. I used it to develop the CV8 code. I didn't know that, I will take a look at it.
Re: Lists Allowing for Switching Values
Also posted on SO: http://stackoverflow.com/questions/21686962/lists-allowing-for-pushing-popping-switching-values
Re: One more question - an untapped audience.
On Mon, 10 Feb 2014 11:03:19 -0800, Tofu Ninja emmo...@purdue.edu wrote: On Monday, 10 February 2014 at 18:11:38 UTC, Steve Teale wrote: What can be done to capture the attention of young people in the developing world? Probably the most effective thing would be if it were possible to edit, compile, and run D programs on a cheap Android ARM phone. Is this within the bounds of possibility? There are millions of unemployed, bored, restless, and ambitious young men out there, who have saved their all to buy a cheap smartphone. Any other ideas? Steve I am only 20 and am still in university so I feel like I can answer this with at least my own experiences. Personally I think D would capture the attention of more young people if it was simply easier to use. The first real language I really got into was C#(about 5-6 years ago) and I think the main reason is that it was so flipin easy to learn and get started. All I had to do to set it up was download Visual Studio and I was done... period ... The documentation was fantastic and everything was named in very intuitive ways. Most of the time when I was learning I would just ctrl+space and start scrolling through the auto-complete reading the documentation of all the functions right there in visual studio. It was soo easy. In my opinion the biggest thing holding D back by a long shot is the tooling and documentation... it is simply terrible. But thats just my opinion so I don't want anyone taking offense. Also something that would help get younger people into D was if the std lib was a little bit more expansive. Look at java and c# in my opinion they are both so popular because their std lib is so large. Younger people don't like to have to deal with non standard libraries as they just make it so much more difficult to do things especially as they are still trying to learn. The lack of a real GUI library is also a hindrance. Young people like to see results on the screen other than just text. That is why web and mobile development is so popular with young people. tldr; Tools suck, documentation sucks, std lib is small and no std GUI lib... I wholeheartedly agree with this sentiment, although I am a little older and got my start in a combination of VB6 and C++98. But C# is what made me want to get up everyday and write code. It is fantastically easy to learn, you can write code that does useful things very quickly. Download the IDE, install, write 50 lines and you've got a tool that does useful work, even if trivial. And the .NET Framework or Java Frameworks. I know that the linux-heads scoff at the idea of shipping a large standard library, Download the library that works best for you they cry! Well, that answer is unacceptable for newbies, mostly because they don't actually know which library will work for them, or with D, or on the operating system they are using. Big standard libraries provide a new user with all the tools that they need to write many programs. This isn't to say that the standard library needs to include everything one might need to build any app every. I still use third-party libraries. I just don't use them to fill in common functionality. For example, I have a library that provides special types of inputboxes, but WPF (a big part of the .NET Framework) provides a generic inputbox. Then we use EntityFramework, .NET provides the generic interface that is used by EntityFramework, LINQ, but EF itself extends the framework in specialized ways. The framework should absolutely include as many general tools as possible. Not having an IDE is more tangential, but no less important. Here we have two integrations with popular IDE's, Visual Studio and Mono. However, these integrations suffer from the lack of tooling for D. DMD can't be used as libary, so these integrations have had to produce their own parsing engines and they are always behind DMD itself so they never parse the current DMD language quite correctly. This means that you can't turn on the really cool features that we in the C#/Java community have become used to. D's integration with IDE's is similar to the situation with IDE integration for C++. Yes D is easier to parse than C++, but since we can't use the canonical parser, we don't have any parsers that match D in it's current form so the AST's are almost always broken or plain incorrect. Building a new IDE won't solve this problem. Here we need to focus on building better tools for D, turning DMD itself into a library or Compiler-as-a-Service in the current lingo, since libraries are now services. D needs to make great strides in tooling to be relevant, we need first-class debugging, and they need to support more than the terminal. We need D as library, we need better IDE integrations. We need a broader standard library. We need more bindings for existing libraries. We need more new
Re: Idea #1 on integrating RC with GC
Le 09/02/2014 11:16, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com a écrit : On Sunday, 9 February 2014 at 10:06:12 UTC, Manu wrote: I don't think you've mage a game recently. Pointless comment. Most big games are multi-year projects with teams numbering well in the Most games are not big. Most games fail in the marketplace. I didn't say they should be a focus, I'm saying they must however be supported. Must is a strong word, but since D is focusing on separate compilation it probably is a focus. Why are most comments about the application domain for D centered on prestigious projects such as AAA games, high volume trading system and safety critical appliations? The most likely application domain is a lot less exciting: tools and simple servers. Get down to earth, plz. Maybe if performances are not really critical, developers can already use Java or C# with a GC? IMO D have to target all applications have to be written in C/C++, where performances or portability, scalability,... are critical. Java and C# developers already have a lot of good tools that C/C++ developers doesn't have, we need love too :-) D claims to be a system language so it's normal to expect to be able to use it on critical ways easily, and maybe lesser for simple applications can already done with actual proven technologies. D is already more complicate to use than Java or C#, just take a look of keywords,... but it's not surprising for a system language with advanced features than other languages doesn't support. IMO D programmers want have a great control on memory even if it can be a pain. We can let D satisfy ego of few developers doesn't already have the need of a such language on some points since it is already much less error prone than C++. :-)
Re: Idea #1 on integrating RC with GC
Am 10.02.2014 22:23, schrieb Xavier Bigand: Le 09/02/2014 21:15, francesco cattoglio a écrit : However, the last point was directed to the D community. The language needs to be more focused on being very good at some key areas, not cover everything. I totally agree on this, but the problem here is that there are game developers out there, willing to use D. I also see lots of movement from hobbysts. We can't ignore them completely. Undefinedly long pauses are really bad for them, and something needs to be done. Be it in user code, library solution or as core part of the language. I agree that AAA titles are not the main right now, but this doesn't mean indie projects shouldn't be doable. After all, 150 milliseconds pauses are really annoying for pretty much any first person game. With a pause of 150ms, you just can't play an animation of any kind. A lot of sample application like a movie play will require to use threads just cause of a GC? I don't find that simple. It's the same for GUI application, having 150ms of pause after a button hit can be horrible, again I don't think it has to be necessary to thread all UI applications even if it's simpler with a language like D. A bit off topic, but can you still get new single core chips?
Re: Idea #1 on integrating RC with GC
On Monday, 10 February 2014 at 21:17:22 UTC, Xavier Bigand wrote: Maybe if performances are not really critical, developers can already use Java or C# with a GC? Or javascript actually, if you use the animation capabilities of the browser engine… IMO D have to target all applications have to be written in C/C++, where performances or portability, scalability,... are critical. Java and C# developers already have a lot of good tools that C/C++ developers doesn't have, we need love too :-) D claims to be a system language so it's normal to expect to be able to use it on critical ways easily, and maybe lesser for simple applications can already done with actual proven technologies. I share your views actually… so I trying to take the view that D is not a C++ replacement, but a compiled C#. That makes it much easier to accept the current state. :-) I am no longer sure if I am able to view D as a system language. Too many features that are not really important on the low level. Too big runtime. And no strategy that points towards whole program optimization. I'd personally much prefer less features, more performance control and whole program optimization. I distinctly remember doing profiling based whole program optimization of c-programs on unix machines in the 1990s. Seriously, that's 18+ years ago.
Re: One more question - an untapped audience.
On Monday, 10 February 2014 at 18:11:38 UTC, Steve Teale wrote: What can be done to capture the attention of young people in the developing world? What young people and how young exactly? It is a very varying crowd..
Re: Idea #1 on integrating RC with GC
Le 09/02/2014 21:15, francesco cattoglio a écrit : However, the last point was directed to the D community. The language needs to be more focused on being very good at some key areas, not cover everything. I totally agree on this, but the problem here is that there are game developers out there, willing to use D. I also see lots of movement from hobbysts. We can't ignore them completely. Undefinedly long pauses are really bad for them, and something needs to be done. Be it in user code, library solution or as core part of the language. I agree that AAA titles are not the main right now, but this doesn't mean indie projects shouldn't be doable. After all, 150 milliseconds pauses are really annoying for pretty much any first person game. With a pause of 150ms, you just can't play an animation of any kind. A lot of sample application like a movie play will require to use threads just cause of a GC? I don't find that simple. It's the same for GUI application, having 150ms of pause after a button hit can be horrible, again I don't think it has to be necessary to thread all UI applications even if it's simpler with a language like D.
Re: Phobos for Review: std.buffer.scopebuffer
On Monday, 10 February 2014 at 22:42:30 UTC, Jonathan M Davis wrote: That would be _encouraging_ the use of importing whole packages at once, which I don't think that we're looking to do. If some folks want to do that with their own projects, fine, but the feature was introduced specifically in order to split of larger modules into packages, not to treat packages as modules. Prohibiting alternative is not discouraging, it is prohibiting. Discouraging is providing both options and clearly stating which one is recommended. So far D has been a very permissive language in terms of user choice, it is strange to suddenly start making restrictions here.
Re: Phobos for Review: std.buffer.scopebuffer
On Monday, February 10, 2014 12:24:24 Dicebot wrote: On Monday, 10 February 2014 at 00:59:00 UTC, Walter Bright wrote: 2. May need buffer.package.d to import all common buffers (there is only one now, but with time...). I do not like the idea of kitchen sink importing. The package.d thing was designed so that we can split up the existing kitchen sink modules without breaking user code. It may be discouraged but in the end it is up to user to decide. I think all packages in Phobos must mandatory provide package.d That would be _encouraging_ the use of importing whole packages at once, which I don't think that we're looking to do. If some folks want to do that with their own projects, fine, but the feature was introduced specifically in order to split of larger modules into packages, not to treat packages as modules. And on top of that, as has come a number of times previously when this sort of thing has been discussed, Phobos was not designed with the idea that you would import entire packages at once, and it could cause some entertaining symbol conflicts, which people would then complain about if we tried to support importing Phobos packages in general. Also, even if there weren't any conflicts now, we'd have to worry about additional conflicts every time that we added a symbol to Phobos. At the extreme, if std had a package.d file that imported _everything_ so that you could just import std; and have all of Phobos, then adding any symbol to any module in all of Phobos where there was another symbol with that same name in another, unrelated module would then break existing code. I'm with Walter on this one. We shouldn't be adding any package.d files to Phobos except when splitting up existing modules. And even then, down the line, we might want to consider deprecating the imports in the package.d files that we introduce when splitting up modules so that existing code moves towards importing the new modules directly. But at minimum, we don't want to be introducing package.d files for existing packages. That's just asking for trouble. - Jonathan M Davis
Re: One more question - an untapped audience.
On Monday, 10 February 2014 at 20:32:03 UTC, Adam Wilson wrote: I wholeheartedly agree with this sentiment, although I am a little older and got my start in a combination of VB6 and C++98. Same for me when I first started learning to program. I did a VB6 course in highschool, followed by a Java course, as well as teaching myself C++ on my own to hack on my Nintendo DS. Looking back, good tutorials were the biggest help. I didn't know anything about anything, and I don't know if I would ever have been able to figure out C++ without sites like cplusplus.com. Bartosz Milewski's C++ in Action book was a huge help too. I'm glad he decided to publish it for free on the web. And the .NET Framework or Java Frameworks. I know that the linux-heads scoff at the idea of shipping a large standard library, Download the library that works best for you they cry! Well, that answer is unacceptable for newbies, mostly because they don't actually know which library will work for them, or with D, or on the operating system they are using. Big standard libraries provide a new user with all the tools that they need to write many programs. This isn't to say that the standard library needs to include everything one might need to build any app every. I still use third-party libraries. I just don't use them to fill in common functionality. For example, I have a library that provides special types of inputboxes, but WPF (a big part of the .NET Framework) provides a generic inputbox. Then we use EntityFramework, .NET provides the generic interface that is used by EntityFramework, LINQ, but EF itself extends the framework in specialized ways. The framework should absolutely include as many general tools as possible. I absolutely agree with that. Phobos should strive to be as batteries included as possible while minimizing (ideally eliminating) third party dependencies. Building a new IDE won't solve this problem. Here we need to focus on building better tools for D, turning DMD itself into a library or Compiler-as-a-Service in the current lingo, since libraries are now services. D needs to make great strides in tooling to be relevant, we need first-class debugging, and they need to support more than the terminal. We need D as library, we need better IDE integrations. We need a broader standard library. We need more bindings for existing libraries. We need more new libraries (like the Aurora library I am working on). But most importantly we need to stop whining about the problems and start doing something about them. There are plenty of projects in these areas that are being run by a single person that could use any help. For example, I know that Rainer Schutze of VisualD fame is quite open to pull requests. If you use a library from a language other than D and have a D binding for it, get it in Deimos. I've come to agree that good IDE integration is a must. I use C# at work, and Visual Studio makes refactoring and code generation near-effortless. I agree with Walter that we definitely shouldn't need an IDE to use D, but there is no competition when it comes to the productivity that a good IDE enables.
Re: Phobos for Review: std.buffer.scopebuffer
On Monday, 10 February 2014 at 22:42:30 UTC, Jonathan M Davis wrote: And on top of that, as has come a number of times previously when this sort of thing has been discussed, Phobos was not designed with the idea that you would import entire packages at once, and it could cause some entertaining symbol conflicts, which people would then complain about if we tried to support importing Phobos packages in general. Also, even if there weren't any conflicts now, we'd have to worry about additional conflicts every time that we added a symbol to Phobos. At the extreme, if std had a package.d file that imported _everything_ so that you could just import std; and have all of Phobos, then adding any symbol to any module in all of Phobos where there was another symbol with that same name in another, unrelated module would then break existing code. I absolutely hate getting symbol conflicts when importing multiple Phobos modules, but I don't think importing an entire package as a module is all that unreasonable. That's basically what we're doing right now, as Phobos is so flat. Your example of importing all of std is a bit extreme, but if we can't even support reasonable cases, then either D's module system, its design, or both have failed in this regard. One of the worst things about the module system currently is the private symbol conflicts, and fixing that would go a long way to allowing some real modularity in Phobos, as well as splitting up the different packages and factoring out any common functionality into privately-imported modules.
Re: Idea #1 on integrating RC with GC
On 2/10/14, 12:48 AM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: On Monday, 10 February 2014 at 04:22:32 UTC, Andrei Alexandrescu wrote: Your thoughts are appreciated (all 6 of them in as many sentences). There is something to be said, however, about armchair quarterbacking and holier-than-thou kibitzing on what others should be doing. This community is as close as it gets to a meritocracy, so if you think you know what's good, you do good. If you want your stupendously many I thinks to carry weight, follow them with some I dos as well. Hop on github. This endless walk through your knowledge base just isn't useful. Good job, my initial response to Manu was a critique of going Ad Hominem and you as a person time and time again fail in that regard in many discussions. Totally. For the most part I take posts one at a time and at face value only, it's just that sometimes larger patterns develop themselves. But as I told Walter, for better or (sometimes definitely) worse, our character flaws make history inside the D community. You do however deserve a round of ad hominem because you as one of the two people who are in a position to communicate the project vision and set forth MEASURABLE goals that can be tracked and evaluated, but you refuse to do so. A fresh perspective is always good to take under consideration. It's also a good opportunity to bring more transparency to what we're doing, as I'll do below. All talk of meritocracy is essentially hypocrisy because all projects need to establish boundaries and a goal post, and you fail miserably in that regard. That's why D is a slow mover. This endless walk through [my] knowledgebase is of course not a walk through my knowledgebase, it is an assessment of the project that YOU FAIL to attempt to do. It is my attempt to try to figure out where this project is heading. You are right, I should not have to do it. YOU SHOULD DO IT. AND PRESENT IT. That way people won't be let down. I have done so. Several times. Two very simple examples from recent history: 1. I stressed that good work on bugs with bounties is a gesture of good will with Facebook that will bring more support from the company. It's the trifecta: the bugs are not harder than those people work on anyway, it's good impact on the future of the language, and it's even non-negligible money. E.g. I wrote on 2014-01-11: My hope is to convince that the message Facebook is conveying here is much stronger than the actual sums involved; it's an initiation of cooperation and involvement with a community, and it would be awesome to respond in kind. Taking a look at https://www.bountysource.com/trackers/383571-d-programming-language, however, reveals that there's little attention to those bugs, in SPITE of the fact that contributions on HARDER problems on the SAME project continued as furiously as ever, if not more. 2. I said many times our inability to review github contributions at the rate they arrive is an important problem we're facing. We currently have 216 open pull requests across our projects. I think this bottleneck very concretely limits the growth speed of D. This is a typical problem. Reviewing contributions is hard and thankless work. I know how we solved it at Facebook for our many open-sourced projects: we created a team for it, with a manager, tracking progress, the works. This is _exactly_ the kind of thing that can't be done in a volunteer community. The reality is that on a volunteer-driven project, it's not easy to tell people what to do. They're by definition in it for working what _they_ want to work on. Applying classic management techniques naively is unlikely to work because all management techniques are using resources toward goals and assume the appropriately qualified human resources will work on what the project requires be done. So I wasn't glib when I sent you to github. In a very concrete sense, you'd be helping there a ton more in a fraction of the time you spend posting. I like the initial vision Walter Bright put forth years ago, that is to make a better C++. That has somehow evolved into making a compiled C#. Can you please ASSESS that. I think D must not define itself in relation to any other language. You and Walter Bright are leads. I expect any project and you to put forth: 1. A clear vision that establish a firm boundary. 2. A small set of clear measurable goals that give the project direction. 3. A list of points stating what the project is not going to address in the immediate future. Some of these are useful to put together at least as (a) thoughts on what I believe would be high-impact topics, (b) things that I plan personally to work on. This endless walk through what is wrong with D project management just isn't useful, because you don't want to listen. Honestly, as one who's been at this for a long time and has done and witnessed a number of such attempts, I think you're
Re: Idea #1 on integrating RC with GC
On 2/10/14, 4:04 AM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: One hobby of mine is to read Intel/AMD CPU docs, raytracing papers and compiler stuff, and discussing those aspects and improving my understanding of those areas is fun. I am loosing hope in that direction for D, because I don't think D has anyone with a strong interest in project management that can drive it in that direction. The responses from the D leads shows signs, not of a lack of skills, but a lack of interest in project management theory (and unfortunately, that is an area where I know the theory quite well since I majored in that area). Terrific. The challenge here is to adapt project management theory to the realities of a volunteer project. Instead of A.A. and W.B. going defensive (and yes it is painful to see your child get a needle in the foot at the doctor to get that vaccine that will keep the child healthy in the long term) they should try to get someone into the team of leads that has an interest in software development process and software process improvement. We're not getting defensive here. Clearly we could and should move faster than we do, and there must be ways to be better at that. I'm all ears on advice on how to do better. I just have difficulty seeing how more management would help. Andrei
Re: One more question - an untapped audience.
On Monday, 10 February 2014 at 19:40:46 UTC, MattCoder wrote: On Monday, 10 February 2014 at 18:14:26 UTC, Dejan Lekic wrote: A D compiler that targets JVM or Dalvik directly is my personal dream... Mine too! Same here. Mobile platforms are immensely important. If you can't cater for them, people will soon ask questions (users don't understand why xyz is not available for mobiles, and they don't need to). So the lack of support for ARM and the like is really a big big drawback. One of the applications we are developing will need a web based solution for mobile phones, tablets etc. It would be nicer, and users will finally want an app they can install locally without having to refer to the cloud (mind you, the network is not always available). I think the importance of this cannot be underestimated, and coming back to the point, this will put young people off, because a lot of young people are into (mobile) app development.
Re: Idea #1 on integrating RC with GC
Le 10/02/2014 09:59, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com a écrit : On Monday, 10 February 2014 at 04:26:10 UTC, Manu wrote: The only company I know of that has made a commercial commitment to D is a AAA games company... Unfortunately a AAA games company is not setting down the goal post for D. As long as the leads for the project have as their primary interests: non-real-time stuff and STL-like-libraries things won't develop in your (and mine and Fransescos) direction. It won't happen until the leads of the project COMMIT to a MEASURABLE goal and a major effort is made to meet that goal. That means putting other goals aside until that measurable goal has been met. Sorry, I obviously mean, the only *games* company... Yeah, but that games company needs to commit to taking a lead role so that the goal post and vision changes in that direction. And people seem to forget promptly after every single time I repeat myself: * The GC frequency of execution is directly proportional to the amount of _free memory_. In console games; NONE. * The length of the associated pause is directly proportional to the amount of memory currently in use. In console games; all of it. This doesn't only describe games, it describes any embedded environment. I've already stated that I don't believe in using D for anything multi-media. So in these case I will forget D, and cry all the tears of my body. It will just a shame for a system language. And it's certainly kind of applications actually miss for D, to improve his visibility. Just take a look around you all applications are interactive, with more animations,... It is not part of the project vision to be good at that from what I am seeing, and I am not going to believe it is going to be good for that until the project leads commit to measurable goals. The leads believe in meritocracy, that means the project will flail around in any direction that is fun. That means there are no rails. There is no reason to pull or push a train that is not on rails. To get D to be a true better C++ you need a concerted effort.
Re: Idea #1 on integrating RC with GC
On Monday, 10 February 2014 at 23:12:08 UTC, Dicebot wrote: deadalanix has been working on SDC for quite a while - alternative implementation of D frontend using LLVM for code gen. Ah ok, I didn't suggest implementing D, but a subset that maps directly to C++. Then you can map directly to the AST.
Re: Idea #1 on integrating RC with GC
Le 10/02/2014 13:04, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com a écrit : On Monday, 10 February 2014 at 09:36:53 UTC, Manu wrote: I'm confused. A couple of posts ago, you seemed to be annoyed at me for consistently raising games as a target application space that was unrealistic, or not 'down to earth', or some fairly niche and irrelevant target workload. Sorry about that. I have been following D since 2005, on and off, and kept waiting for the better C++ to materialize so I can use it to do fun stuff with it (audio, 3D, raytracing etc). One hobby of mine is to read Intel/AMD CPU docs, raytracing papers and compiler stuff, and discussing those aspects and improving my understanding of those areas is fun. I am loosing hope in that direction for D, because I don't think D has anyone with a strong interest in project management that can drive it in that direction. The responses from the D leads shows signs, not of a lack of skills, but a lack of interest in project management theory (and unfortunately, that is an area where I know the theory quite well since I majored in that area). On the fun side I want what you want. I would love to see you be the third lead on D, to get a person that falls to sleep thinking real time into that position would make me believe in the project. On the pay for bread side I am looking at D from the perspective of having an alternative to Go on the server side. I guess that has made me janus-faced in this discussion. What would make me tilt in favour of Go instead of D, is that it has corporate backing and therefore give priority to production level stability. Even though I like the semantics of D better. Stability is important to me since I personally pay the price (literally) for technical flaws since I offer fixed priced solutions. Instead of A.A. and W.B. going defensive (and yes it is painful to see your child get a needle in the foot at the doctor to get that vaccine that will keep the child healthy in the long term) they should try to get someone into the team of leads that has an interest in software development process and software process improvement. Or at the very least, one person with real time focus. (Please note that I found it quite amusing that you claimed that I was ignorant of long running games, since I studied Anarchy Online from inception to end in a qualitative manner while trying to figure out the design properties of the design domain, from a system development perspective. You don't have to convince me, I do understand where you are coming from and enjoy reading about your perspective. ;^) Video games is a bigger industry than the movie industry. Casual/phones have captured a large slice in recent years, but the rest of the pie is almost entirely games consoles, which I don't think is a diminishing industry so much as the casual/phone space is rather growing the pie in overall volume. The industry is expanding as a whole. Yes, unfortunately the revenue in the mobile app space is very low for the majority of developers which requires tools that make them very productive at the cost of technical quality. So lots of stuff is being done with cheap (and not really performant) tech to cut down on dev time. Yes I can't tell you how hard it is. Plus editors that are much more concern historically by market than product quality, cause mobile apps are seen as cheap software. So few people take it seriously, maybe only Apple understand friendly applications have to be perfectly polished to be a commercial success. A more performant and productive language could certainly make a difference, but to get there you need to focus on that niche, otherwise it will take too many years to catch up with the alternatives (with their eco system). And the landscape keeps changing very quickly. Companies that offer 3rd party solutions fold all the time. So mobile devs are jaded. I don't think anyone in the D community really has that power. If Walter were to dictate direction that was unpopular enough, the developer base would promptly dissolve. Yes, some would leave, but others would join. Those who today look at D and say: - This is kind of cool, but not quite there yet - when can I expect to see it land in the area where it makes me productive - is this cart worth pushing, can we actually make a significant improvement here or do I have to push this cart all by myself I would imagine that there are more people sitting on the fence than not. What made Linux work out was that they were aiming for a well defined vision, Unix. Progress was easy to measure. What made Linux fail on the desktop that they did not have a well defined vision, so the community spread out on N alternatives and progress was hard to measure. This is a bit simplistic, but Open Source projects that does not have a strongly projected vision tends to wither and dissolve over time. the goal. Contributing to D is, in some way, a form of recreation for
Re: Idea #1 on integrating RC with GC
On Monday, 10 February 2014 at 14:24:06 UTC, Ola Fosheim Grøstad wrote: No, I don't think it is only a matter of resources. For instance, if I had the time I would most certainly consider writing a pack-rat parser for a modified subset a D that builds an AST for clang. You do that :D I'll be waiting. Some people just need to run into the roadblock to notice it exists.
Re: Idea #1 on integrating RC with GC
Am 11.02.2014 00:11, schrieb deadalnix: On Monday, 10 February 2014 at 21:57:42 UTC, Paulo Pinto wrote: A bit off topic, but can you still get new single core chips? Sure you can. But that is far from common, unless you have really strict constraints. I know, I was just big a bit sarcastic about not using threads in this day and age.
Re: Idea #1 on integrating RC with GC
On 2/10/14, 3:15 PM, Andrei Alexandrescu wrote: 2. A few months ago a prominent member of the community made (privately to Walter and myself) a strong argument along the same lines as yours: D could move much faster if some good management could be used with it, and offered to ask as a manager of the project. s/ask/act/
Re: Idea #1 on integrating RC with GC
On Monday, 10 February 2014 at 23:06:06 UTC, deadalnix wrote: You do that :D I'll be waiting. Some people just need to run into the roadblock to notice it exists. Which roadblock?
Re: Idea #1 on integrating RC with GC
On Monday, 10 February 2014 at 23:06:56 UTC, Xavier Bigand wrote: So in these case I will forget D, and cry all the tears of my body. It will just a shame for a system language. And it's certainly kind of applications actually miss for D, to improve his visibility. Yes, but nobody that are in the decision making body of D has shown any resemblance of understanding or priority for real time applications. Seriously, the language is close to ten years in the making. Just take a look around you all applications are interactive, with more animations,... Yeah, but at some point you just have to accept that people who don't have a need to write real time will avoid putting it on the road map. I would like to see a roadmap that says real time and no gc and whole program optimization, owned pointers, shared pointers++ I see no road map.
Re: Idea #1 on integrating RC with GC
On Monday, 10 February 2014 at 21:57:42 UTC, Paulo Pinto wrote: A bit off topic, but can you still get new single core chips? Yes you can! http://en.wikipedia.org/wiki/Intel_Edison will be made available in 2014, single core. And since it will have very limited resources, C# and Java are probably off limits. I must say D would be a perfect language for it! :D
Re: Idea #1 on integrating RC with GC
On Monday, 10 February 2014 at 21:57:42 UTC, Paulo Pinto wrote: A bit off topic, but can you still get new single core chips? Sure you can. But that is far from common, unless you have really strict constraints.
Re: Idea #1 on integrating RC with GC
On Monday, 10 February 2014 at 23:07:06 UTC, Ola Fosheim Grøstad wrote: On Monday, 10 February 2014 at 23:06:06 UTC, deadalnix wrote: You do that :D I'll be waiting. Some people just need to run into the roadblock to notice it exists. Which roadblock? You seems to knows everything in and out. You tell me. If you aren't sure, please start parsing D to clang AST. After all, that sound like a great idea. I'm not sure I want to spend any time trying to convince you considering: 1 - people have been trying and it looks like a time consuming energy hungry task. 2 - You don't seems interested to actually contribute anything. So start you clang idea, if it sounds great to you. And come back enlightened.
Re: Idea #1 on integrating RC with GC
On Monday, 10 February 2014 at 23:07:06 UTC, Ola Fosheim Grøstad wrote: On Monday, 10 February 2014 at 23:06:06 UTC, deadalnix wrote: You do that :D I'll be waiting. Some people just need to run into the roadblock to notice it exists. Which roadblock? deadalanix has been working on SDC for quite a while - alternative implementation of D frontend using LLVM for code gen.
Re: Capturing keystrokes
On Monday, 10 February 2014 at 14:21:59 UTC, Chris wrote: The first time I stated ./terminal it worked fine (including Ctrl+) until I hit Ctrl+Shift. It went on strike right there. After restarting, anytime I click Ctrl it just hangs. Weird, it must be sending a special escape sequence on it it works for me though on my 0.4.4 xfce terminal well, mostly works, I got the *terminal* to freeze up by opening and closing a few tabs, blargh. idk what the problem is though, I'd say give ncurses a try and if it works for you, that should be good.
Re: Idea #1 on integrating RC with GC
Le 10/02/2014 09:58, Manu a écrit : On 10 February 2014 17:58, francesco cattoglio francesco.cattog...@gmail.com mailto:francesco.cattog...@gmail.com wrote: On Monday, 10 February 2014 at 04:26:10 UTC, Manu wrote: Sorry, I obviously mean, the only *games* company... That was a given. However I think AAA titles have the manpower to avoid those pauses, since the amount of work toward optimization is huge anyway, am I right? Ofc you still need minimal backend from the compiler and runtime support. If you lack control on internals, there's no way for you to optimize anything. If we wanted to spend that time+manpower (read, money overtime/sanity) on bullshit like that, we have no reason to adopt D; we already have C/C++, and we already have decades of experience mitigating that nightmare. The point is, we are REALLY sick of it. Why would we sign up to replace it with more of the same thing. And people seem to forget promptly after every single time I repeat myself: * The GC frequency of execution is directly proportional to the amount of _free memory_. In console games; NONE. * The length of the associated pause is directly proportional to the amount of memory currently in use. In console games; all of it. For simple games, it would be nice to have a better GC and cut down allocations from the standard library. I guess that would suffice, no need to move to ARC. For 'simple' games, might as well write then in Java or C#, the tooling is much better, and support is offered by major multinational corporations. Not to say that they shouldn't be supported in D too, but that's not a target of interest to me, and I don't think it's an area which makes a particularly compelling argument for adoption of D. I've said before, console games is an industry desperate for salvation, and D makes a very strong case here in lieu of any other realistic alternatives... as long as this memory stuff is addressed acceptably. If there were to be some killer potential markets identified for D, I think this is definitely one of them. Like you I don't see the interest for D to compete against C# or Java. IMO there is a big hole that C/C++ developers dream to see filled. We want : - a less error prone language : DONE - a better syntax : DONE - advanced meta-programming features : DONE - a fast build : DONE - a rich framework : Have some potential (miss a lot of QtCore equivalent, GUI libraries), progress really slowly - be multi-platform : almost DONE - be cross-platform (binary portable) : a potential way with LVM bytecode - no performance concessions : GC issues - better tools (IDE with refactor tools working, better debugger,...) - buildin tools (unittest, static analyser,...) : DONE For the moment D GC was a real pain for me on DQuick, I am not able to control when releasing my OpenGL resources easily. I can't wait a GC collect, cause handles are fewer than the central memory. The destruction order is also a real issue. I certainly have to learn new patterns, but I try to add a release method on Resource objects and add a check in debug to see if it was correctly called. I wasn't able to use Throwable.TraceInfo cause it's a class which means can't be printed in the destructor. So if a user forgive to call release method on a resource (leak) I just can't warm him with a great message... For me leaks aren't just unreferenced pointers, but also and mainly chunk of resources still retained when not necessary cause those are harder to track and are critical on small devices. A GC won't help you a lot here, because IMO it act like a pool on every objects. It seems a lot of developers aren't concern by memory usage when there is a GC. I am also concern of having all applications using a GC, cause it force user of multi-task OS to buy more memory or close few applications. I just buy 4Go more cause I can't let my smartgit,VS,Chrome,... when playing Battlefield 4???. Smartgit is in Java, VS in C# in a part and Chrome create a process per tab??? Please stop pushing us create applications memory consuming, it's not cheap. --- Maybe D is too ambitious, what we really need is a language that can be updated more easily than C++ to be as soon as possible usable in industry. Seriously I work for a little game company, we are few developers (about 9 developers on 3 different projects), we don't have means to use IncrediBuild or such tools to save times. Reducing the compile time and having a great framework are critical points for us. We have relatively few memory issues by managing it ourselves. We use C++ cause our targets are numerous : - Windows Pocket PC : not anymore - Symbian : not anymore - Nintendo DS : not anymore - Nintendo Wii : not anymore - iOS - Windows - MacOS X - Android - Xbox 360 - PS 3 Our applications/games can have some critical performances
Re: Idea #1 on integrating RC with GC
On Monday, 10 February 2014 at 23:15:35 UTC, Andrei Alexandrescu wrote: Taking a look at https://www.bountysource.com/trackers/383571-d-programming-language, however, reveals that there's little attention to those bugs, in SPITE of the fact that contributions on HARDER problems on the SAME project continued as furiously as ever, if not more. Interesting, I had directly the opposite impression when went through the bountysource list. Lot of issues have pull requests provided but are stalled because of slow feedback cycle.
Re: Lists Allowing for Switching Values
On Monday, 10 February 2014 at 19:35:55 UTC, Jeroen Bollen wrote: Is there a way in D to have a list that allows you to shift around values? I'm creating a cache and I would like to keep a log of when an item was last accessed so when the cache shrinks or is about to overflow I can delete the items that haven't been accessed in a while. I would like to be able to push to the back and pop from the front. Do note that I would like to pop from the front, and not from the back, as I want the oldest items to be popped out. I would like the be able to search if the item is actually in the list. If no such functionality exists yet I could alternatively implement it myself; it's not crucial. I would like to be able to switch items around. This allows me when an item already in the list is accessed, I can put it back at the back, where the most recent items reside. Does such a feature exist already in D, is there perhaps a better approach about doing this? It all depends on the access times you need. If you are fine with O(n) or O(log n), then something from std.container with a few extra helper functions will do just fine. O(1) on the other hand, might require 2 associative arrays you will have to keep it sync. Nothing impossible anyway.
Re: Phobos for Review: std.buffer.scopebuffer
On 2/10/2014 2:45 PM, Dicebot wrote: Prohibiting alternative is not discouraging, it is prohibiting. Discouraging is providing both options and clearly stating which one is recommended. So far D has been a very permissive language in terms of user choice, it is strange to suddenly start making restrictions here. Often more than one way to do something in Phobos is tolerated for backwards compatibility reasons, not because it is a good idea on its own. One old case comes to mind, where the author of a module wanted to provide both an OOP interface and a free function interface to the same functionality, in the name of user choice. To me, this is giving some false illusion of flexibility, when in fact it is merely clutter and bloat.
Re: Idea #1 on integrating RC with GC
On Monday, 10 February 2014 at 23:29:25 UTC, Ola Fosheim Grøstad wrote: On Monday, 10 February 2014 at 23:13:56 UTC, deadalnix wrote: You seems to knows everything in and out. You tell me. If you aren't sure, please start parsing D to clang AST. After all, that sound like a great idea. No, I don't know everything, but I said modified subset of D, that would be a different language. Suitable for my needs (I don't need RTTI or exceptions etc). I know I can do it, because source-2-source compilation is not that difficult and could be the first step. And (slow) parsers are not so difficult to write with the tools we have today. After looking at the SVN repositories for clang I am becoming a bit more familiar with the source code which looked chaotic the first time I looked at it. The AST looks ok from skimming through the repository, I assume I can get it through a visualization tool and generate visual graphs of the hierarchies. Long story short, if you want to map thing on top of clang AST, you'll have to reduce significantly the subset of D you want to use, or build a full fledged front end, at which point you'd better use LLVM directly or GCC, or whatever backend suit your desires. For instance, static ifs, template constraints and CTFE require full understanding of language semantic by the frontend. Runtime reflection, is also out. That mean UDA could work but become useless. Type inference also require almost complete understanding of the language by the frontend. And even with these drastic restrictions, you'll still need a significant amount of semantic analysis in the frontend before feeding clang. You'll have to instantiate templates yourself (or bye bye alias parameters, string parameters and so on). Track variables used in closures (well, on that one you can arguably allocate every stack frame on heap and pas the whole stack frame to C++ lambda, that should work, but that will excruciatingly slow and memory consuming) to allocate them on heap. With CTFE, compile time reflection and static ifs/mixins, D wraps around itself in a way that makes it all or nothing in implementation.
Re: Idea #1 on integrating RC with GC
On Monday, 10 February 2014 at 23:13:56 UTC, deadalnix wrote: You seems to knows everything in and out. You tell me. If you aren't sure, please start parsing D to clang AST. After all, that sound like a great idea. No, I don't know everything, but I said modified subset of D, that would be a different language. Suitable for my needs (I don't need RTTI or exceptions etc). I know I can do it, because source-2-source compilation is not that difficult and could be the first step. And (slow) parsers are not so difficult to write with the tools we have today. After looking at the SVN repositories for clang I am becoming a bit more familiar with the source code which looked chaotic the first time I looked at it. The AST looks ok from skimming through the repository, I assume I can get it through a visualization tool and generate visual graphs of the hierarchies.
Re: Idea #1 on integrating RC with GC
On 2/10/14, 3:24 PM, Dicebot wrote: On Monday, 10 February 2014 at 23:15:35 UTC, Andrei Alexandrescu wrote: Taking a look at https://www.bountysource.com/trackers/383571-d-programming-language, however, reveals that there's little attention to those bugs, in SPITE of the fact that contributions on HARDER problems on the SAME project continued as furiously as ever, if not more. Interesting, I had directly the opposite impression when went through the bountysource list. Lot of issues have pull requests provided but are stalled because of slow feedback cycle. Same difference. A bunch of people can pull, I'm hardly the bottleneck. It just means I failed to convince the community to get those bounties done. Andrei
Re: Phobos for Review: std.buffer.scopebuffer
On 2/10/2014 11:46 AM, Dicebot wrote: I personally will vote No for any new proposal that looks obviously alien from existing Phobos code, despite it being possibly very useful and desired and backed by sound reasoning. 1. There are many, many package folders in phobos/druntime that do not have a package.d. 2. package.d can always be added. But it cannot be subtracted. Hence, it is best not to add it just because, it needs more compelling arguments.
Re: Idea #1 on integrating RC with GC
On Monday, 10 February 2014 at 23:20:50 UTC, Andrei Alexandrescu wrote: Terrific. The challenge here is to adapt project management theory to the realities of a volunteer project. Yes, I understand that. I guess it often means that key people have to do the unfun stuff and let the more intermittent volunteers do the fun stuff… But I believe that democratic design requires very strong communication of vision if you want to create something new (otherwise you tend to end up with bastardized copies of what exist, since people will navigate towards the safe common ground). that. I'm all ears on advice on how to do better. I just have difficulty seeing how more management would help. Just a suggestion of some possibilities: Externally (front of web page): - More clear communication of the boundaries of the project. - Stating clearly what ground you do not cover. - Defining short term/long term goals on your front page. - Make it visible when they are met or changed. Internally (you probably do this already in some form): - Map out a list of dependencies between long term goals and use it for planning so that people who are more inclined to do proof-of-concept stuff can help out. - Some sort of social reward mechanism (borrow from MMOs?). I like the bounty stuff, but social rewards are much stronger. - Make commitments in key areas. Like stating how the project will change if you cannot meet deadlines. Like a priori stating what you will do with the GC if benchmark X is not met by date N. That could make those wanting GC push harder and those not wanting GC more complacent. Ok, maybe the wrong thing to do for the GC, but you get the idea, get the direction set. (Is it reasonable to limit features/production-quality to the shared common denominator of 3 backends? Can you somehow mitigate that?)
Re: Idea #1 on integrating RC with GC
Le 11/02/2014 00:12, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com a écrit : On Monday, 10 February 2014 at 23:06:56 UTC, Xavier Bigand wrote: So in these case I will forget D, and cry all the tears of my body. It will just a shame for a system language. And it's certainly kind of applications actually miss for D, to improve his visibility. Yes, but nobody that are in the decision making body of D has shown any resemblance of understanding or priority for real time applications. Seriously, the language is close to ten years in the making. Just take a look around you all applications are interactive, with more animations,... Yeah, but at some point you just have to accept that people who don't have a need to write real time will avoid putting it on the road map. Boostrapping D, will certainly reveal some issue with GC? I don't know much about compilers, but certainly the parser may see some performance gains with GC and the other parts? Maybe some major loose? I am curious to see that as a benchmark comparator. It's not real-time but it's a serious system application challenge. I would like to see a roadmap that says real time and no gc and whole program optimization, owned pointers, shared pointers++ I see no road map.
Re: Idea #1 on integrating RC with GC
On Monday, 10 February 2014 at 23:15:35 UTC, Andrei Alexandrescu wrote: develop themselves. But as I told Walter, for better or (sometimes definitely) worse, our character flaws make history inside the D community. But I am also a hard core roleplayer… so you won't know when I am me, and when I am pulling your leg. I assume the same about you. ;-] The internet is a stage. What is real, what is not real? Hard to tell. What is a person, what is a character? Difficult question. This is a typical problem. Reviewing contributions is hard and thankless work. I know how we solved it at Facebook for our many open-sourced projects: we created a team for it, with a manager, tracking progress, the works. This is _exactly_ the kind of thing that can't be done in a volunteer community. Maybe you can make some parts modular after you refactor into D. Then people can take ownership of modules and social recognition will encourage more commitment. I don't know the D social arena well enough to know if that works though. So I wasn't glib when I sent you to github. In a very concrete sense, you'd be helping there a ton more in a fraction of the time you spend posting. But I don't want to do that when I am merely assessing D. I am not commited to D. Yet. I think D must not define itself in relation to any other language. I respect that position. Of course, it does not help if outsiders have been told that D is a better C++. It kinda sticks. Because people really want that. I am very hard trying to convince myself that D is more like compiled C#, which lowers my expectations, because that original vision of a better C++ is very firmly stuck. Of course, the problem with C++ is that it is used very differently by different people. D is appealing more to the high-level version of C++. It probably depends on when you first used C++ or what parts of C++ you are interested in. done and witnessed a number of such attempts, I think you're exceedingly naive about what can be done with traditional project management approaches in this case. There you go ad hominem again. I have studied online virtual worlds where people volunteer for worse… But my point was more that you need to communicate a vision that is such that the people you want to attract don't sit on the fence. I am quite certain that more skilled C++ programmers would volunteer if they saw a vision they believed in. So maybe they don't do more, but more hands available… Ola, I'm sure you mean well. I trust you will find it within yourself the best way to contribute to this community. You really need to avoid this ad hominem stuff… You see, as a hardcore roleplayer I could be tempted to switch over into a sarcastic mode. And that would not be fair to you. ;-)
DDMD as showcase?
Firstly is there some progress on the DDMD project or maybe an other D boostrap? There is a lot of thread and debate around the GC of D, I interrogate me on the capacity of a project like DDMD to prove to every D users that the GC is perfectly usable for system applications. If not it will certainly be improve during the DDMD development to a point can satisfy almost everybody? As I know DMD doesn't release memory, these will have to be fixed in DDMD to match the memory management most application have to apply. I see many interesting points in DDMD : - prove GC based compiler isn't longer to optimize than the C++ version (and capable to reach same performances) - will reveal more language issues or phobos miss. - will be easier to maintain and update
Re: Idea #1 on integrating RC with GC
On Tuesday, 11 February 2014 at 00:21:22 UTC, deadalnix wrote: With CTFE, compile time reflection and static ifs/mixins, D wraps around itself in a way that makes it all or nothing in implementation. Ok, but I think I didn't communicate clearly what I am looking for. I am just looking for a nicer C++. I don't really need the full D semantics. I am content with the C++ subset that I can desugar into. To me D is just that, a nicer C++. I don't need the high level stuff. Those are nice to have, but not needed.
Re: Testing some singleton implementations
Dejan Lekic wrote in message news:nvakemdpugwupoqct...@forum.dlang.org... Don't forget that __gshared static and static __gshared do different things! Care to elaborate? https://d.puremagic.com/issues/show_bug.cgi?id=4419
Re: Idea #1 on integrating RC with GC
On 2/10/14, 6:24 AM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: No, I don't think it is only a matter of resources. For instance, if I had the time Oh, the unbelievable irony. Andrei
