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.
