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
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: 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: 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: 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 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: 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 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: 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: 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 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 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: 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 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)
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
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)
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: 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: 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: 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: 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/
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: 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
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 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: 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: 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.
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: 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!
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);