Re: D port of docopt
On Monday, 16 June 2014 at 06:51:41 UTC, Jacob Carlborg wrote: On 15/06/14 19:35, Bob Tolbert wrote: In order to learn D, I've worked up a port of the docopt commandline parser (original in Python http://docopt.org). https://github.com/rwtolbert/docopt.d Since this is my first code in D, I apologize in advance for the mix if Python and C++ idioms. Since this is ported from Python, with the intention of staying compatible with future Python versions, some of that is expected, but I look for this as an chance to learn more about D. It is also a pretty useful way to write commandline interfaces. The included example that mimics the git CLI is pretty impressive. This is also my first submission as a dub project, so hopefully I got that right as well. Still needs more tests ported from Python, but it does pass the entire functional test suite for the current Python version. Pretty cool idea. Are you aware of that in D you can, at compile time, parse the doc string and generate a command line parser for that particular documentation. Looking at the git example [1], it seems a bit complicated and verbose to use after parsing. To determine which arguments was passed to the application. [1] https://github.com/rwtolbert/docopt.d/blob/master/examples/git/gitD.d Im actually in the middle of writing this very thing :) My docopt parser builds a class (using string mixins) depending on what fields are required from the help text, and then returns a type of that class at run time. It's not ready for prime time yet though, so havent uploaded it. The idea was to have the interface look like: auto doc = docopt!(HelpText String)(args);
Re: D port of docopt
On Sunday, 15 June 2014 at 17:35:59 UTC, Bob Tolbert wrote: In order to learn D, I've worked up a port of the docopt commandline parser (original in Python http://docopt.org). https://github.com/rwtolbert/docopt.d Since this is my first code in D, I apologize in advance for the mix if Python and C++ idioms. Since this is ported from Python, with the intention of staying compatible with future Python versions, some of that is expected, but I look for this as an chance to learn more about D. It is also a pretty useful way to write commandline interfaces. The included example that mimics the git CLI is pretty impressive. This is also my first submission as a dub project, so hopefully I got that right as well. Still needs more tests ported from Python, but it does pass the entire functional test suite for the current Python version. Regards, Bob Good going bob, I've actually been attempting to write this for the past while too :) Looks good, and should be very useful to the community!
Yet another CT ini file parser: inifiled
On my way back from DConf I was bored with in the in-flight
entertainment and start to hack.
The result is "inifiled" a compile time ini file reader and writer that
fills and stores a annotated struct.
It excepts typical ini files with sections, comments and to some extend
nesting and arrays. The only
unique characteristic is that the struct and struct member annotations
require comments. Config
options without descriptive comments just make me troll. So comments for
options are required.
dub: http://code.dlang.org/packages/inifiled
github: https://github.com/burner/inifiled
@INI("A Person")
struct Person {
@INI("The lastname of the Person") string lastname;
@INI("The height of the Person") float height;
@INI("Some strings with a very long long INI description that is longer" ~
" than eigthy lines hopefully."
) string[] someStrings;
}
void main() {
Person person;
readINIFile(p, "filename.ini");
writeINIFile(p, "filename.ini");
}
Re: John Chapman (Juno), calling for John Chapman (not spam)
On Thursday, 12 June 2014 at 05:39:06 UTC, Karen Bantoft wrote: I'm looking for the John Chapman who worked as a programmer at Centre-file Ltd, in Finsbury Circus London in 1971. Any leads? Karen Not me, sorry.
Re: D port of docopt
On Monday, 16 June 2014 at 06:51:41 UTC, Jacob Carlborg wrote: Pretty cool idea. Are you aware of that in D you can, at compile time, parse the doc string and generate a command line parser for that particular documentation. I wondered about that, after looking at the compile-time regex stuff, which is pretty darn cool. Looking at the git example [1], it seems a bit complicated and verbose to use after parsing. To determine which arguments was passed to the application. [1] https://github.com/rwtolbert/docopt.d/blob/master/examples/git/gitD.d While that is true, I'd argue that if you are writing an app with a command line that complicated, then you have your work cut out for you no matter what the system is you use. Bob
Re: Lang.NEXT panel (dfix)
On 12/06/2014 18:53, Andrei Alexandrescu wrote: On 6/12/14, 10:40 AM, Nick Sabalausky wrote: On 6/10/2014 12:35 PM, justme wrote: On Wednesday, 4 June 2014 at 06:13:39 UTC, Andrei Alexandrescu wrote: Of possible interest. http://www.reddit.com/r/programming/comments/278twt/panel_systems_programming_in_2014_and_beyond/ Andrei IMHO, the coolest thing was when Rob Pike told about the tool they made for automatically upgrading user source code to their next language version. That should be quite easy to implement now in D, and once done, would give much needed room for breaking changes we feel should be done. Pike seemed to be extremely satisfied they did it. Personally, I wouldn't be comfortable trusting such a tool. Besides, I find that upgrading a codebase to a newer language version is one of the most trivial tasks I ever face in software development - even in D. It's a cute trick, but not a worthwhile use of development resources. I very much think the opposite, drawing from many years of hacking into large codebases. I'm completely with Rob here. On a large codebase, even the slightest manual or semi-manual change is painstaking to plan and execute, and almost always suffers of human errors. I got convinced a dfix tool would be a strategic component of D's offering going forward. Andrei What's keeping us from having such a tool? It seems that after one has a decent parser (that also keeps tracks of the source ranges of AST nodes), it's easy to write code that does syntactic modifications and then rewrites the source code. And there's several D parsers out there already - so it should be too much effort to get there. Even I am working on a tool that can be easily retrofitted for this purpose. Or maybe I am misunderstanding the amount of semantic analysis that would typically be required? Can someone give some examples of modifications that would be useful for such a dfix tool? (I haven't yet had the time to watch the full panel video, if that's relevant) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Interview at Lang.NEXT
On 05/06/2014 08:30, Andrei Alexandrescu wrote: On 6/5/14, 7:59 AM, Nick Sabalausky wrote: So let me get this straight: There are programmers out there who find the occasional type annotations on some declarations to be significantly more work than following a convention of nearly *quadrupling* the amount of code they have to write? Two to three lines of tests for every one line of real code is considered rapid development, "saving developer time", "just getting things done", etc? And all that's considered a "style" of coding? You're right, I really don't understand that style of coding at all. ;) Don't get me wrong, I am pretty big on unittests, but even still: If people are trying to save developer time by replacing each minor type annotation with several extra unittests (which are less reliable anyway - greater room for human error), then something's gone horribly wrong. > It's usually quite hard to explain such > differences in coding stile to people that are used to static typing. > That doesn't surprise me. It's also very difficult to explain 2+2==5 to people who are accustomed to basic arithmetic. ;) I have to confess this echoes a few similar confusions I have about the use and advocacy of dynamically-typed languages. One argument I've heard a while back was that static type errors are not "proportional response" and that static types only detect the most trivial of bugs, so why bother at all. But then the heavy-handed approach to unittesting espoused by dynamic languages, of which arguably a good part would be automated by a static type system, seems to work against that argument. Andrei Dicebot, Nick, Andrei: my thoughts exactly. And I get a lot of that, since my main development language (career-wise) is Java, which dynamic language proponents like to bash for it's verbosity (yes, it's more verbose that it needs to be, but still way better than a dynamic language having to write all those tests!) I sometimes tried to convince dynamic language proponents - the ones that write unittests at least - of the benefits of static typing, by stating that static typing is really just "compile time unit-tests"! (it is actually) It didn't work, they didn't get it... -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Lang.NEXT panel (dfix)
On 6/16/14, 6:43 AM, Bruno Medeiros wrote: On 12/06/2014 18:53, Andrei Alexandrescu wrote: I got convinced a dfix tool would be a strategic component of D's offering going forward. Andrei What's keeping us from having such a tool? It seems that after one has a decent parser (that also keeps tracks of the source ranges of AST nodes), it's easy to write code that does syntactic modifications and then rewrites the source code. And there's several D parsers out there already - so it should be too much effort to get there. Even I am working on a tool that can be easily retrofitted for this purpose. Or maybe I am misunderstanding the amount of semantic analysis that would typically be required? Can someone give some examples of modifications that would be useful for such a dfix tool? (I haven't yet had the time to watch the full panel video, if that's relevant) No magic required. -- Andrei
DConf Day 1 Talk 6: Case Studies in Simplifying Code with Compile-Time Reflection by Atila Neves
https://news.ycombinator.com/newest https://www.facebook.com/dlang.org/posts/867399893273693 https://twitter.com/D_Programming/status/478588866321203200 http://www.reddit.com/r/programming/comments/28am0x/case_studies_in_simplifying_code_with_compiletime/ Andrei
Re: D port of docopt
Am 15.06.2014 19:35, schrieb Bob Tolbert: In order to learn D, I've worked up a port of the docopt commandline parser (original in Python http://docopt.org). https://github.com/rwtolbert/docopt.d Since this is my first code in D, I apologize in advance for the mix if Python and C++ idioms. Since this is ported from Python, with the intention of staying compatible with future Python versions, some of that is expected, but I look for this as an chance to learn more about D. It is also a pretty useful way to write commandline interfaces. The included example that mimics the git CLI is pretty impressive. This is also my first submission as a dub project, so hopefully I got that right as well. Still needs more tests ported from Python, but it does pass the entire functional test suite for the current Python version. Regards, Bob That's a really nice approach. Makes me wonder if there is a generic bash completion script for this kind of help screen format(?). One thing that would be nice is support for multiple help screens (e.g. one per command). For DUB [1] (or GIT) for example there is one main help screen that lists all commands along with common options and then one help screen per command that lists the individual arguments, options and a summary of what the command does. But maybe for such more complex CLIs it starts to be more efficient to use a programmatic approach. For a statically typed language like D it would also be interesting to investigate the possibility to encode and validate the type of each option or positional argument instead of using a generic string type. [1]: http://code.dlang.org/
Re: D port of docopt
On Monday, 16 June 2014 at 17:59:13 UTC, Sönke Ludwig wrote: Am 15.06.2014 19:35, schrieb Bob Tolbert: One thing that would be nice is support for multiple help screens (e.g. one per command). For DUB [1] (or GIT) for example there is one main help screen that lists all commands along with common options and then one help screen per command that lists the individual arguments, options and a summary of what the command does. But maybe for such more complex CLIs it starts to be more efficient to use a programmatic approach. if you have a look at the gitD examples, they do just this. If you do gitD --help you get the general help for gitD, but if you do gitD push -h or gitD help push you get the help for the sub-command "push" so doing this with 'dub' would be pretty simple. And you don't have to use external sub-commands either. You can parse the basic args with the general doc string and then based on the sub-command chosen, re-parse with the options specific to that sub module. I haven't looked at the dub source code, but I'd be happy to help sketch out how this might work there specifically. Bob
Re: Interview at Lang.NEXT
On 6/16/2014 10:00 AM, Bruno Medeiros wrote: Java, which dynamic language proponents like to bash for it's verbosity Static language proponents like to bash Java for its verbosity, too!
Re: DConf Day 1 Talk 6: Case Studies in Simplifying Code with Compile-Time Reflection by Atila Neves
On 06/16/2014 07:27 PM, Andrei Alexandrescu wrote: > https://news.ycombinator.com/newest Why not put "DConf 2014" in the title too?
Re: Lang.NEXT panel (dfix)
What's keeping us from having such a tool? It seems that after one has a decent parser (that also keeps tracks of the source ranges of AST nodes), it's easy to write code that does syntactic modifications and then rewrites the source code. And there's several D parsers out there already - so it should be too much effort to get there. Even I am working on a tool that can be easily retrofitted for this purpose. Or maybe I am misunderstanding the amount of semantic analysis that would typically be required? Can someone give some examples of modifications that would be useful for such a dfix tool? (I haven't yet had the time to watch the full panel video, if that's relevant) Well, my recent efforts lead my to belief that I am in over my head with this. But ... many sufficiently simple transformations can be done with a complex regex and for me that is faster, given the trouble I have with writing ASTMatchers for Dscanner. BTW. Does anyone know a good approch to a DSL describeing AST-transformation patterns ? What I currently have is SQL-like Syntax and I feel it won't scale to complex selction and/or transformation patterns. Input is welcome.
Re: D port of docopt
Am 16.06.2014 20:19, schrieb Bob Tolbert: On Monday, 16 June 2014 at 17:59:13 UTC, Sönke Ludwig wrote: Am 15.06.2014 19:35, schrieb Bob Tolbert: One thing that would be nice is support for multiple help screens (e.g. one per command). For DUB [1] (or GIT) for example there is one main help screen that lists all commands along with common options and then one help screen per command that lists the individual arguments, options and a summary of what the command does. But maybe for such more complex CLIs it starts to be more efficient to use a programmatic approach. if you have a look at the gitD examples, they do just this. If you do gitD --help you get the general help for gitD, but if you do gitD push -h or gitD help push you get the help for the sub-command "push" so doing this with 'dub' would be pretty simple. And you don't have to use external sub-commands either. You can parse the basic args with the general doc string and then based on the sub-command chosen, re-parse with the options specific to that sub module. I haven't looked at the dub source code, but I'd be happy to help sketch out how this might work there specifically. Bob Ah OK, nice. I was somehow under the impression that all options would have to match exactly with what is in the help text. But nesting works fine like this of course. As for DUB, it probably doesn't make sense to rewrite the CLI now for no particular reason. Its command line interface maybe isn't as concise as a docopt based one, but still does pretty well and also has a few possible advantages, such as direct type validation and automatic assembly of help pages with nested options (the help text includes both, global and command specific options, as well as possible intermediate level options that are shared among several commands). Currently, everything is in a single module (the "framework" and all commands), but that is supposed to be broken up into multiple modules in the future: https://github.com/D-Programming-Language/dub/blob/master/source/dub/commandline.d
Re: Lang.NEXT panel (dfix)
On 16/06/2014 21:43, Stefan Koch wrote: What's keeping us from having such a tool? It seems that after one has a decent parser (that also keeps tracks of the source ranges of AST nodes), it's easy to write code that does syntactic modifications and then rewrites the source code. And there's several D parsers out there already - so it should be too much effort to get there. Even I am working on a tool that can be easily retrofitted for this purpose. Or maybe I am misunderstanding the amount of semantic analysis that would typically be required? Can someone give some examples of modifications that would be useful for such a dfix tool? (I haven't yet had the time to watch the full panel video, if that's relevant) Well, my recent efforts lead my to belief that I am in over my head with this. But ... many sufficiently simple transformations can be done with a complex regex and for me that is faster, given the trouble I have with writing ASTMatchers for Dscanner. BTW. Does anyone know a good approch to a DSL describeing AST-transformation patterns ? What I currently have is SQL-like Syntax and I feel it won't scale to complex selction and/or transformation patterns. Input is welcome. DSL?! You crazy bro? If you are using DScanner, just let people use D itself to write their own custom AST transformation code. With DUB it should be super easy to compile that code and run it on the target D code. This solution is vastly more simple than inventing your own DSL, and scales way better as a general purpose language will have much more power that selection/transformation patterns. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: D port of docopt
On Monday, 16 June 2014 at 06:51:41 UTC, Jacob Carlborg wrote: Pretty cool idea. Are you aware of that in D you can, at compile time, parse the doc string and generate a command line parser for that particular documentation. I don't think it gives any advantage here :) docopt looks cool, though my I'd prefer something that works other way around - automatically generates argument parsing code and help messages from aggregate that represents configuration and/or CLI API (with help of few UDA).
Re: Lang.NEXT panel (dfix)
DSL?! You crazy bro? If you are using DScanner, just let people use D itself to write their own custom AST transformation code. With DUB it should be super easy to compile that code and run it on the target D code. This solution is vastly more simple than inventing your own DSL, and scales way better as a general purpose language will have much more power that selection/transformation patterns. The thing I have in mind should be really easy for simple tasks as in `if constuctor in any class has parameter of type "oldRouter" change that parameter to type "new Router"` but i habe yet to find a good notation for that
Re: D port of docopt
On 06/16/2014 11:11 PM, Dicebot via Digitalmars-d-announce wrote: > On Monday, 16 June 2014 at 06:51:41 UTC, Jacob Carlborg wrote: >> Pretty cool idea. Are you aware of that in D you can, at compile >> time, parse the doc string and generate a command line parser for >> that particular documentation. > > I don't think it gives any advantage here :) > > docopt looks cool, though my I'd prefer something that works other way > around - automatically generates argument parsing code and help > messages from aggregate that represents configuration and/or CLI API > (with help of few UDA). +1 I could use reviews for this PR https://github.com/D-Programming-Language/phobos/pull/2072
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
On Sunday, 15 June 2014 at 21:38:18 UTC, Dmitry Olshansky wrote:
15-Jun-2014 20:21, Dicebot пишет:
On Saturday, 14 June 2014 at 16:34:35 UTC, Dmitry Olshansky
wrote:
But let's face it - it's a one-time job to get it right in
your
favorite build tool. Then you have fast and cached (re)build.
Comparatively costs of CTFE generation are paid in full
during _each_
build.
There is no such thing as one-time job in programming unless
you work
alone and abandon any long-term maintenance. As time goes any
mistake
that can possibly happen will inevitably happen.
The frequency of such event is orders of magnitude smaller.
Let's not take arguments to supreme as then doing anything is
futile due to the potential of mistake it introduces sooner or
later.
It is more likely to happen if you change you build scripts more
often. And this is exactly what you propose.
I am not going to say it is impractical, just mentioning flaws
that make me seek for better solution.
Automation. Dumping the body of ctRegex is manual work after
all, including putting it with the right symbol. In proposed
scheme it's just a matter of copy-pasting a pattern after
initial setup has been done.
I think defining regexes in separate module is even less of an
effort than adding few lines to the build script ;)
It is somewhat worse because you don't routinely change
external
libraries, as opposed to local sources.
But surely we have libraries that are built as separate project
and are "external" dependencies, right? There is nothing new
here except that "d-->obj-->lib file" is changed to
"generator-->generated D file--->obj file".
Ok, I am probably convinced on this one. Incidentally I do always
prefer full source builds as opposed to static library separation
inside application itself. When there is enough RAM for dmd of
course :)
Huge mess to maintain. According to my experience
dub is terrible at defining any complicated build models.
Pretty much
anything that is not single step compile-them-all approach can
only be
done via calling external shell script.
I'm not going to like dub then ;)
It is primarily source dependency manager, not a build tool. I
remember Sonke mentioning it is intentionally kept simplistic to
guarantee no platform-unique features are ever needed.
For anything complicated I'd probably wrap dub call inside
makefile to prepare all necessary extra files.
If using external generators is
necessary I will take make over anything else :)
Then I understand your point about inevitable mistakes, it's
all in the tool.
make is actually pretty good if you don't care about other
platforms than Linux. Well, other than stupid whitespace
sensitivity. But it is incredibly good at defining build systems
with chained dependencies.
What I want to point out is to not mistake goals and the means
to an end. No matter how we call it CTFE code generation is
just a means to an end, with serious limitations (especially as
it stands today, in the real world).
I agree. What I do disagree about is definition of the goal. It
is not just "generating code", it is "generating code in a manner
understood by compiler".
For instance if D compiler allowed external tools as plugins
(just an example to show means vs ends distinction) with some
form of the following construct:
mixin(call_external_tool("args", 3, 14, 15, .92));
it would make any generation totally practical *today*.
But this is exactly the case when language integration gives you
nothing over build system solution :) If compiler itself is not
aware how code gets generated from arguments, there is no real
advantage in putting tool invocation inline.
How long till C preprocessor is working at CTFE? How long till
it's practical to do:
mixin(htod(import("some_header.h")));
and have it done optimally fast at CTFE?
Never, but it is not really about being fast or convenient. For
htod you don't want just C grammar / preprocessor support, you
want it as good as one in real C compilers.
My answer is - no amount of JITing CTFE and compiler
architecture improvements in foreseeable future will get it
better then standalone tool(s), due to the mentioned
_fundamental_ limitations.
There are real practical boundaries on where an internal
interpreter can stay competitive.
I don't see any fundamental practical boundaries. Quality of
implementation ones - sure. Quite the contrary, I totally see how
better compiler can easily outperform any external tools for most
build tasks despite somewhat worse JIT codegen - it has huge
advantage of being able to work on language semantical entities
and not just files. That allows much smarter caching and
dependency tracking, something external tools will never be able
to achieve.
Re: D port of docopt
On Monday, 16 June 2014 at 21:21:47 UTC, Robert Schadek via
Digitalmars-d-announce wrote:
On 06/16/2014 11:11 PM, Dicebot via Digitalmars-d-announce
wrote:
On Monday, 16 June 2014 at 06:51:41 UTC, Jacob Carlborg wrote:
Pretty cool idea. Are you aware of that in D you can, at
compile
time, parse the doc string and generate a command line parser
for
that particular documentation.
I don't think it gives any advantage here :)
docopt looks cool, though my I'd prefer something that works
other way
around - automatically generates argument parsing code and help
messages from aggregate that represents configuration and/or
CLI API
(with help of few UDA).
+1 I could use reviews for this PR
https://github.com/D-Programming-Language/phobos/pull/2072
Sure, will have a look.
Though I don't see how what I propose can fit into Phobos as
std.getopt, it is something for an alternative module. The way I
see it, getopt will be more suitable for small simple CLI
implementations and that imaginary module - for programs with
huge amount of options and complicated nested commands.
Something like this:
@help("
Header used to describe this configuration option block
")
struct CLI
{
@descr("Some optional parameter")
Optional!int param1;
@descr("Mandatory parameter")
int param2;
struct Command
{
string nested_param;
void opCall(ref A outer)
{
// called after parsing relevant args into this
instance
}
}
Command command;
}
void main(string[] args)
{
Config config;
parseCLI!config(args);
// ./app --param2 42 command --nested_param yay
}
Re: DConf Day 1 Talk 6: Case Studies in Simplifying Code with Compile-Time Reflection by Atila Neves
The reddit response this year hasn't been particularly impressive it seems to me compared to last year :(
Re: DConf Day 1 Talk 6: Case Studies in Simplifying Code with Compile-Time Reflection by Atila Neves
On Monday, 16 June 2014 at 22:14:01 UTC, Adam D. Ruppe wrote: The reddit response this year hasn't been particularly impressive it seems to me compared to last year :( I have found many of talks this year incredibly interesting for actual D users but not as "catchy" for something that passes by. Also lot of stuff has been discussed live in #d and ustream chat room. Or r/programming is just so saturated with links that something that does not fit into "tl; dr" paragraph does not get any attention :)
Re: D port of docopt
Bob Tolbert, el 15 de June a las 17:35 me escribiste: > In order to learn D, I've worked up a port of the docopt > commandline parser (original in Python http://docopt.org). > > https://github.com/rwtolbert/docopt.d THANK YOU. I love docopt! > Since this is my first code in D, I apologize in advance for the > mix if Python and C++ idioms. Since this is ported from Python, > with the intention of staying compatible with future Python > versions, some of that is expected, but I look for this as an > chance to learn more about D. > > It is also a pretty useful way to write commandline interfaces. > The included example that mimics the git CLI is pretty impressive. > > This is also my first submission as a dub project, so hopefully I > got that right as well. > > Still needs more tests ported from Python, but it does pass the > entire functional test suite for the current Python version. > > Regards, > Bob -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- This is what you get, when you mess with us.
Re: DConf Day 1 Talk 6: Case Studies in Simplifying Code with Compile-Time Reflection by Atila Neves
On Monday, 16 June 2014 at 17:26:51 UTC, Andrei Alexandrescu wrote: https://news.ycombinator.com/newest https://www.facebook.com/dlang.org/posts/867399893273693 https://twitter.com/D_Programming/status/478588866321203200 http://www.reddit.com/r/programming/comments/28am0x/case_studies_in_simplifying_code_with_compiletime/ Andrei http://youtu.be/xpImt14KTdc
Re: DConf Day 1 Talk 6: Case Studies in Simplifying Code with Compile-Time Reflection by Atila Neves
On Monday, 16 June 2014 at 22:23:31 UTC, Dicebot wrote: I have found many of talks this year incredibly interesting for actual D users but not as "catchy" for something that passes by. Also lot of stuff has been discussed live in #d and ustream chat room. Yeah. Or r/programming is just so saturated with links that something that does not fit into "tl; dr" paragraph does not get any attention :) It could be that it isn't on the youtube right off too. I posted there saying I tried the ogv and it was awful and the mp4 was too big... so maybe other people aren't inclined to bother with the downloads either. BTW I tried posting the link to the sample chapter of my book in this too since it talks about reflection and the post seems to have just disappeared. I think I triggered reddits comment spam filter :(
Re: DConf Day 1 Talk 6: Case Studies in Simplifying Code with Compile-Time Reflection by Atila Neves
On 6/16/2014 8:38 PM, Adam D. Ruppe wrote: BTW I tried posting the link to the sample chapter of my book in this too since it talks about reflection and the post seems to have just disappeared. I think I triggered reddits comment spam filter :( I gave up posting links on reddit years ago - every one gets deleted as spam, and then I have to beg the moderators to de-spam it.
Re: Interview at Lang.NEXT
On 16/06/14 16:00, Bruno Medeiros wrote: I sometimes tried to convince dynamic language proponents - the ones that write unittests at least - of the benefits of static typing, by stating that static typing is really just "compile time unit-tests"! (it is actually) You can actually do compile time unit tests in D, that is not the type system. I.e. unit tests for CTFE functions that runs at compile time. Pretty cool actually :) -- /Jacob Carlborg
Re: D port of docopt
On 16/06/14 15:31, Bob Tolbert wrote: While that is true, I'd argue that if you are writing an app with a command line that complicated, then you have your work cut out for you no matter what the system is you use. It would be nice to see a simpler example of how to use the library after parsing. Most examples now just do "writeln(arguments);". -- /Jacob Carlborg
Re: Lang.NEXT panel (dfix)
On 16/06/14 15:43, Bruno Medeiros wrote: What's keeping us from having such a tool? It seems that after one has a decent parser (that also keeps tracks of the source ranges of AST nodes), it's easy to write code that does syntactic modifications and then rewrites the source code. And there's several D parsers out there already - so it should be too much effort to get there. Even I am working on a tool that can be easily retrofitted for this purpose. Or maybe I am misunderstanding the amount of semantic analysis that would typically be required? Can someone give some examples of modifications that would be useful for such a dfix tool? (I haven't yet had the time to watch the full panel video, if that's relevant) * The parser haven't been available for that long (I think) * Can they handle whole language? * Semantic analysis is needed. Otherwise as soon as someone uses templates or mixins the tool won't properly work -- /Jacob Carlborg
Re: D port of docopt
On 16/06/14 23:11, Dicebot wrote: I don't think it gives any advantage here :) docopt looks cool, though my I'd prefer something that works other way around - automatically generates argument parsing code and help messages from aggregate that represents configuration and/or CLI API (with help of few UDA). Same here. I use the argument parser in Tango [1], which I think works well. I have extended the one in Tango to support generating the help message, and some other stuff as well [2]. [1] http://siegelord.github.io/Tango-D2/tango.text.Arguments.html [2] https://github.com/jacob-carlborg/mambo/tree/master/mambo/arguments -- /Jacob Carlborg
