Re: Scriptlike: New lib to aid in writing script-like programs

[Nick Sabalausky]

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: Scriptlike: New lib to aid in writing script-like programs

[Jesse Phillips]

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

[Nick Sabalausky]

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: early alpha of D REPL

[cal]

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

[Jesse Phillips]

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

[Martin Nowak]

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

[Nick Sabalausky]

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: Scriptlike: New lib to aid in writing script-like programs

[Nick Sabalausky]

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: finally using D at work

[Manu]

On 11 February 2014 05:56, 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! Looking forward to your dconf talk next year! ;)

Re: Scriptlike: New lib to aid in writing script-like programs

[Jesse Phillips]

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: Scriptlike: New lib to aid in writing script-like programs

[Jesse Phillips]

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

[Nick Sabalausky]

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 throwin

Re: early alpha of D REPL

[deadalnix]

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

[Jesse Phillips]

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: ACCU: Wednesday, February 12 - Amaury Séchet, "Multi-core Software Development Challenges and How D Helps"

[Ali Çehreli]

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:   
Directions: VCAFE is accessible from the semicircular courtyard between
Symantec buildings 
Cost:  Free
More Info:


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: finally using D at work

[Justin Whear]

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: Scriptlike: New lib to aid in writing script-like programs

[thedeemon]

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: DDT 0.9.0 released - GDB debugging integration

[Vladimir Krivopalov]

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:


 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: finally using D at work

[Atila Neves]

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: early alpha of D REPL

[Martin Nowak]

On Tuesday, 11 February 2014 at 08:51:50 UTC, extrawurst wrote:

Did I just kill it ?
After playing around the site is not responding anymore :( I am 
sorry


No problem :), it's the most important TODO right now to prevent 
this.

https://github.com/MartinNowak/drepl/blob/master/examples/server.d#L34

Re: early alpha of D REPL

[The Guest]

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.

Scriptlike: New lib to aid in writing script-like programs

[Nick Sabalausky]

I've released a little one-module utility, Scriptlike, to help simplify 
writing shell script-like programs in D:


  https://github.com/Abscissa/scriptlike

Here's post outlining my motivations for this library (sorry, the CMS 
I'm using ATM generates very long URLs):


http://semitwist.com/articles/article/view/scriptlike-shell-scripting-in-d-annoyances-and-a-library-solution

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.


- 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


- 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.


- 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.)


- 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().)

Re: early alpha of D REPL

[thedeemon]

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: early alpha of D REPL

[thedeemon]

On Tuesday, 11 February 2014 at 04:46:41 UTC, Martin Nowak wrote:

Barely running but already fun and a little useful.


Have you seen Dabble?
https://github.com/callumenator/dabble
It works pretty well on my Win 7.

Re: finally using D at work

[extrawurst]

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: dmd 2.065 beta 3

[extrawurst]

On Tuesday, 11 February 2014 at 03:37:52 UTC, Martin Nowak wrote:

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.


No no optimization enabled and I am also not using any diet 
templates. It happens here on win32 even with the smallest 
example that vibe.d provides...

Re: early alpha of D REPL

[Martin Nowak]

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: early alpha of D REPL

[Andrei Alexandrescu]

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

[extrawurst]

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

[extrawurst]

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!

early alpha of D REPL

[Martin Nowak]

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

[deadalnix]

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: dmd 2.065 beta 3

[Martin Nowak]

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.

Re: finally using D at work

[Jonathan Dunlap]

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: finally using D at work

[Ali Çehreli]

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: dmd 2.065 beta 3

[extrawurst]

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

[Paulo Pinto]

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: finally using D at work

[John J]

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

[Dmitry Olshansky]

10-Feb-2014 23:56, extrawurst пишет:

So our next online game will be powered by some parts in D ;)
Yay!
Exciting times!


Lucky you :)

--
Dmitry Olshansky

Re: finally using D at work

[ponce]

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

[Walter Bright]

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.

finally using D at work

[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!