Re: D port of docopt
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 -- /Jacob Carlborg
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.
An LLVM bug that affect both LDC and SDC. Worth pushing for
http://llvm.org/bugs/show_bug.cgi?id=20049 Basically when you have a closure in a closure and the whole thing get inlined, LLVM mess up, which result in compiler not being able to optimize GC allocation away. Probably worth pushing for. It does probably affect other functional languages as well, but I didn't checked.
Re: A Perspective on D from game industry
On 6/15/2014 4:26 PM, Burp wrote: I work in the game industry so I'm familiar with this type of mindset. Not everyone in my industry is like this, but unfortunately many are(I avoid working with them). He doesn't understand metaprogramming and so dismisses it. He also assumes C++ is all about Java style OOP, when modern style is wildly different from Java. And yes the game industry will likely *never* produce its own language or tools. Why? Because it is very short-term goal oriented, focusing almost entirely on the current project with little thought for long term growth. Most companies are relatively small, and even large ones like EA are very fragmented(although EA did produce its own version of the STL). Basically, this guy is a *rendering engineer*, likely good at math and algorithms, but not so hot with design. Interesting to hear, thanks for sharing your perspective. There's one thing I'd like to ask about though, not intending to argue, but just for clarification: You say the industry isn't likely to produce its own tools. While I'm in no position to disagree, I am surprised to hear that since the industry is known to produce some of its own middleware. EA is said to have a fairly sophisticated in-house UI authoring system, and of course they have Frostbite. Various studios have developed in-house engines, and many of the big-name ones (ex, Unreal Engine, Source, CryEngine) started out as in-house projects. Would you say those are more exceptional cases, or did you mean something more specific by tools?
Re: A Perspective on D from game industry
On Mon, Jun 16, 2014 at 12:18:26AM -0400, Nick Sabalausky via Digitalmars-d wrote: [...] C++'s lack of finally didn't do any favors for exception handling's popularity, either. (Has finally finally been added?) http://stackoverflow.com/questions/7779652/try-catch-finally-construct-is-it-in-c11 Apparently, C++ *still* doesn't have finally, preferring RAII instead. Yet another nail in the too-little-too-late coffin that is C++11. T -- Кто везде - тот нигде.
Re: A Perspective on D from game industry
On Monday, 16 June 2014 at 06:24:47 UTC, H. S. Teoh via Digitalmars-d wrote: On Mon, Jun 16, 2014 at 12:18:26AM -0400, Nick Sabalausky via Digitalmars-d wrote: [...] C++'s lack of finally didn't do any favors for exception handling's popularity, either. (Has finally finally been added?) http://stackoverflow.com/questions/7779652/try-catch-finally-construct-is-it-in-c11 Apparently, C++ *still* doesn't have finally, preferring RAII instead. Yet another nail in the too-little-too-late coffin that is C++11. T Who needs finally when you have scope(exit) ?
Re: Concurrent GC (for Windows)
On 15.06.2014 23:30, Martin Nowak wrote: On 06/04/2014 10:37 PM, Rainer Schuetze wrote: Most of the remaining pause time is sweeping garbage. I think about deferring sweeping into allocations by running finalizers just before reusing the memory for another object. This can throttle allocations a bit while at the same time reduce pauses. That's pausing the thread which triggered the collection, right? Other threads don't need to wait for sweeping. Yes, the world is not stopped during sweeping. The GC lock still blocks any thread that tries to allocate, though. Dividing the cost to run finalizers among many allocations is a charming idea. Another nice property: If memory is recycled during malloc, you can run the finalizers without the GC lock held just before returning, so there are less restrictions on what can happen in a destructor.
Re: A Perspective on D from game industry
On 06/15/2014 11:16 PM, Abdulhaq wrote: On Sunday, 15 June 2014 at 20:10:34 UTC, Walter Bright wrote: On 6/15/2014 9:20 AM, Xinok wrote: Given that he lives in Italy, it's safe to assume that English is not his first language. But rather than consider what he has to say or dispute his arguments, you completely dismissed his point of view because his level of writing doesn't meet your standards. Xinok does have a point that we all should be aware of. I've found a very strong correlation between poor writing skills and disorganized thinking. (Your point about non-native English speakers is well taken, one must not confuse unfamiliarity with English with disorganized thinking.) I'm hardly the only one. If one wants their views to be taken seriously, pay attention to spelling, grammar, paragraphs, organized writing, etc. There's an awful lot of stuff to read on the internet, and poor writing often elicits a meh, I'll skip this one and move on reaction. True but if I'm going to judge a comment by the way it's written I'll take a second language piece over a foul and insulting rant any day of the week. And my guess is the people doing the insults never use another language than their native language on a day-to-day basis. Not being a native English speaker myself, I too got offended by this rant. It's naive to assume everyone should be as fluent in English as native speakers. Some countries are even dubbing all English shows and movies, so they're not exposed to much English outside some forums - where many people might not be native speakers themselves and thus learning you faulty grammar. Luckily most people understands this issue.
Re: A Perspective on D from game industry
On Monday, 16 June 2014 at 05:46:22 UTC, Nick Sabalausky wrote: On 6/15/2014 9:55 PM, Manu via Digitalmars-d wrote: To say that they literally have no time to spend on extra-curricular projects is an understatement, and risk-aversion is a key form of self-defence. I know many gamedev's who are frequently expected to choose between their life and families, or their jobs. Geezus, that garbage is still going on? EA Spouse alone was well over a decade ago. That, and all the many, many other examples (often less extreme, but still entirely unacceptable IMO) was exactly the reason I decided at the last minute (in college), to change my long-standing plans and not pursue a career in that industry after all. Several *years* ago, I was under the impression that problem had finally been changing? Is that not so? I was considering getting a job in the games industry, so I applied to a bunch of places in the UK during my final year of university. When you filtered out the jobs that were looking for years of industry experience, then filtered out the jobs that expected you to work terribly long hours, you got to the positions that said, We'll get you started as a tester. I switched to web development, where I work roughly 9-5 for a good salary, and I never looked back.
Re: A Perspective on D from game industry
On 6/15/2014 5:41 PM, Sean Kelly wrote: That's precisely the reason I wrote a chapter on templates in Tango With D despite Don's suggestion that I talk about the far sexier CTFE. People have an unreasonable fear of templates and when you get down to it they're terribly simple to understand. Ever thought about doing an update to your book?
Re: A Perspective on D from game industry
On 6/15/2014 6:12 PM, H. S. Teoh via Digitalmars-d wrote: I think you may have missed the fact that your very realization was a further development in itself. The term template comes from the C++ idea of having a pre-written piece of code with some blanks in a few places, that will be filled in to make the actual code. But the concept of compile-time parameter is something conceptually different, and more powerfully unifying IMO. It digs at the root of C++'s template nastiness, which ultimately comes from treating template parameters as something fundamentally distinct from function parameters. The ugly syntax is but the superficial expression of this underlying difference in conception. D's superior template syntax is not merely a better dressed syntax; it ultimately stems from treating template parameters as being the *same* thing as function parameters -- except they are evaluated at compile-time rather than runtime. This insight therefore causes D's templates to mesh very nicely with CTFE to form a beautifully-integrated whole. I like the way you think. Can I subscribe to your newsletter? :-) I like how TDPL introduces templates by not introducing them at all, but just talks about compile-time arguments. By the time the reader gets to the chapter on templates, he's already been using them comfortably. Our eevil plan at work! But on that note, perhaps it's not altogether a bad thing for the word template to have a negative connotation; perhaps we should be pushing the term compile-time parameter instead. It engenders an IMO superior way of thinking about these things that may help newcomers overcome the fear of metaprogramming. !
Re: A Perspective on D from game industry
On Monday, 16 June 2014 at 06:40:39 UTC, simendsjo wrote: Some countries are even dubbing all English shows and movies, so they're not exposed to much English outside some forums That's exactly what's happening in Italy... --- Paolo
Re: A Perspective on D from game industry
On Monday, 16 June 2014 at 07:17:32 UTC, Paolo Invernizzi wrote: On Monday, 16 June 2014 at 06:40:39 UTC, simendsjo wrote: Some countries are even dubbing all English shows and movies, so they're not exposed to much English outside some forums That's exactly what's happening in Italy... --- Paolo https://www.youtube.com/watch?v=VdjhzMVY9T4
Re: A Perspective on D from game industry
On 6/16/2014 2:23 AM, H. S. Teoh via Digitalmars-d wrote: On Mon, Jun 16, 2014 at 12:18:26AM -0400, Nick Sabalausky via Digitalmars-d wrote: [...] C++'s lack of finally didn't do any favors for exception handling's popularity, either. (Has finally finally been added?) http://stackoverflow.com/questions/7779652/try-catch-finally-construct-is-it-in-c11 Apparently, C++ *still* doesn't have finally, preferring RAII instead. Yet another nail in the too-little-too-late coffin that is C++11. Ahh, ouch. Some years back, I was very surprised when I came across Brian Hook's old Book of Hook article denouncing exceptions as a bad approach to error handling. Then I realized C++ didn't have finally. All of a sudden his perspective made a lot more sense. :) But wait...Hasn't Andrei created library-based scope guards for C++? (Or am I remembering something wrong?) How would that possible without finally?
Re: A Perspective on D from game industry
On 16/06/2014 1:12 p.m., H. S. Teoh via Digitalmars-d wrote: On Sun, Jun 15, 2014 at 12:51:12PM -0700, Walter Bright via Digitalmars-d wrote: On 6/15/2014 6:50 AM, Peter Alexander wrote: The fear of meta programming comes from Boost, and rightly so in my opinion. Boost is written with the assumption that users will never have to read its source code. When it comes to debugging and performance tuning however, that assumption is shattered. For years I avoided C++ templates (even though I implemented them in DMC++) because they were just so dang hard to read. D originally was not going to have templates for that reason. But I eventually discovered that hiding behind the complexity of C++ templates was a very simple idea - templates are just functions with compile time rather than run time arguments. (Isn't it amazing that I could implement C++ without figuring this out? I still don't understand that.) That was the enabling breakthrough for D templates. I think you may have missed the fact that your very realization was a further development in itself. The term template comes from the C++ idea of having a pre-written piece of code with some blanks in a few places, that will be filled in to make the actual code. But the concept of compile-time parameter is something conceptually different, and more powerfully unifying IMO. It digs at the root of C++'s template nastiness, which ultimately comes from treating template parameters as something fundamentally distinct from function parameters. The ugly syntax is but the superficial expression of this underlying difference in conception. D's superior template syntax is not merely a better dressed syntax; it ultimately stems from treating template parameters as being the *same* thing as function parameters -- except they are evaluated at compile-time rather than runtime. This insight therefore causes D's templates to mesh very nicely with CTFE to form a beautifully-integrated whole. In fact, templates engender such an OMG! Templates! I don't get Templates! aura about them that I convinced Andrei to not even use the word template in his book about D! [...] I like how TDPL introduces templates by not introducing them at all, but just talks about compile-time arguments. By the time the reader gets to the chapter on templates, he's already been using them comfortably. Personally I put CTFE ahead of meta programming in D. I don't think we have yet quite cracked its true power. By the time you've used CTFE a bit you beg for templated functions and classes almost. But on that note, perhaps it's not altogether a bad thing for the word template to have a negative connotation; perhaps we should be pushing the term compile-time parameter instead. It engenders an IMO superior way of thinking about these things that may help newcomers overcome the fear of metaprogramming. T
Re: A Perspective on D from game industry
On Monday, 16 June 2014 at 07:27:16 UTC, Nick Sabalausky wrote: But wait...Hasn't Andrei created library-based scope guards for C++? (Or am I remembering something wrong?) How would that possible without finally? Skip to 19:00 http://vimeo.com/97329153
Re: A Perspective on D from game industry
On 16 June 2014 15:46, Nick Sabalausky via Digitalmars-d digitalmars-d@puremagic.com wrote: On 6/15/2014 9:55 PM, Manu via Digitalmars-d wrote: On 16 June 2014 05:53, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 6/15/2014 12:27 PM, Nick Sabalausky wrote: It really gets me that the same industry which created Frostbite 3, Unreal Engine 4, GTA5, Steam (obviously all enormous investments), mostly done *in* C++ which makes them that much MORE effort, will bitch *soo* much about C++ and STILL won't get off their asses enough to write, or even contribute to, a mere language. It's all about comfort zone. It is much easier to continue doing what one is familiar with than to try something new. It's also fair to say that some people have learned D, and gone back to C++. I think the reason is mostly like I said in my other post; that gamedev is a strictly closed and proprietary industry. Open Source is a synonym with flakey, barely working, non-windows-compatible, probably-linux-nonsense, rubbish, if you ask most gamedev's. They don't understand OSS, and the industry doesn't support any knowledge Interesting. That explains a chat I had a few years back, that had been puzzling me ever since, with a gamedev guy. I'd known him for a long time, and I *know* he's a very intelligent guy, but when the subject changed to OSS, suddenly it felt like, uhh, *ahem*...like the LA Times was trying to tell me about Nintendo's PlayStation 4 ;). *Zero* awareness of the real-word commercial contributions to OSS (Almost as if Mozilla didn't even exist). But I *knew* this guy was smart enough to know better. I just couldn't figure it out. But if that's a prevalent belief in the industry, then that would explain what felt like an almost surreal conversation. If you ask the average programmer, chances are they'll have a strong opinion on the matter, probably based on nothing more than hearsay. Sadly, for such a huge industry, it fosters some really immature engineers. in the field. I think this is changing, but it hasn't pervasively affected gamedev culture yet... I've been watching Unity3D pretty closely as of late, and I predict that it, plus it's Asset Store (or similar competitors) are going to start forcing the issue of AAA collaboration/openness more and more. That company seems to be built, in no small part, on putting indies closer and closer to competing with AAAs. And they have a history of making some real eyebrow-raising steps in that direction, with no signs of slowing down. I'm convinced Epic's already taken notice of that, as UE4 seems to be directly targeted at both Frostbite and Unity (Not that Frostbite has gone commercial, AFAIK). Related to this whole topic of openness in gamedev, Slightly Mad's Project C.A.R.S. is really going to be something to keep an eye on. I'd imagine the success or failure of that could very well trigger at least a few ripples. I think these sorts of ripples are starting to have some significant effect, but it's not pervasive yet. Many companies and engineers don't take the time out to look at the bigger picture. It can take quite some time to invade their mind-sets. To say that they literally have no time to spend on extra-curricular projects is an understatement, and risk-aversion is a key form of self-defence. I know many gamedev's who are frequently expected to choose between their life and families, or their jobs. Geezus, that garbage is still going on? EA Spouse alone was well over a decade ago. That, and all the many, many other examples (often less extreme, but still entirely unacceptable IMO) was exactly the reason I decided at the last minute (in college), to change my long-standing plans and not pursue a career in that industry after all. Several *years* ago, I was under the impression that problem had finally been changing? Is that not so? Well, depends who you ask. Some have worked it out and acted on it, others have worked it out and don't have the luxury to act (or face terminal thread to their company). I think it's getting better slowly, but that's coming at the cost of big game studios failing all over the world, resulting in a high level of occupational burnout, and employees so badly scarred they will never work like that again, which re-enforces the movement ;) There's a serious problem when companies business models depend on working their staff into the ground to remain competitive against the competition. It's a race to the bottom, and plenty of companies won the prize... If they can't see the package and toolset nicely integrated, they can't imagine the workflow as realistic. I often make the point how important VisualD is, and I don't say that lightly, it is everything to this community. And I must re-iterate, it's a _gigantic_ community! Yea. Even as a non-IDE user (but former Visual Studio fan), I do sympathize with that. Naturally it's an
Re: A Perspective on D from game industry
On 6/16/2014 2:56 AM, w0rp wrote: On Monday, 16 June 2014 at 05:46:22 UTC, Nick Sabalausky wrote: Geezus, that garbage is still going on? EA Spouse alone was well over a decade ago. That, and all the many, many other examples (often less extreme, but still entirely unacceptable IMO) was exactly the reason I decided at the last minute (in college), to change my long-standing plans and not pursue a career in that industry after all. Several *years* ago, I was under the impression that problem had finally been changing? Is that not so? I was considering getting a job in the games industry, so I applied to a bunch of places in the UK during my final year of university. When you filtered out the jobs that were looking for years of industry experience, then filtered out the jobs that expected you to work terribly long hours, you got to the positions that said, We'll get you started as a tester. I switched to web development, where I work roughly 9-5 for a good salary, and I never looked back. Yea. I never even bothered applying anywhere in gamedev (although nothing exists in ohio anyway and I didn't particularly want to move, but still). So instead, my first summer in college I got an internship with one of the web teams at a major corp around here and learned webdev on the job (ASP, back in in the pre-.NET days, even did some WAP/WML) The 8-5 on that (incl lunch) was enough of a hell for me (even despite being a rather decent company) - so I certainly wouldn't want anything in an industry that does crunch mode. Been kinda stuck in web dev ever since. It's not all bad though, as much as I hate about web, there are some aspects of webdev I've come to enjoy. For example, the various problems of making web dev less painful has gone from survival to a genuine interest. I've known some people who did go into AAA games though. One guy who rose the ranks from tester to full fledged programmer back on the PS1 (and later worked on Undying, which was a pretty sweet FPS). And an old college friend of mine joined up with Volition as a character designer/artist for several of their games. He's not there now though, and we pretty much lost contact after college, so no idea what he's up to now. Although if things are going well for him, then I have a couple good guesses. But anyway, I'm rambling again. :)
Re: A Perspective on D from game industry
On Monday, 16 June 2014 at 07:41:03 UTC, safety0ff wrote: On Monday, 16 June 2014 at 07:27:16 UTC, Nick Sabalausky wrote: But wait...Hasn't Andrei created library-based scope guards for C++? (Or am I remembering something wrong?) How would that possible without finally? Skip to 19:00 http://vimeo.com/97329153 Oops, scope exit is at 16:00, just watch the whole video though, it's good :o)
Re: A Perspective on D from game industry
On Monday, 16 June 2014 at 06:56:22 UTC, w0rp wrote: On Monday, 16 June 2014 at 05:46:22 UTC, Nick Sabalausky wrote: On 6/15/2014 9:55 PM, Manu via Digitalmars-d wrote: To say that they literally have no time to spend on extra-curricular projects is an understatement, and risk-aversion is a key form of self-defence. I know many gamedev's who are frequently expected to choose between their life and families, or their jobs. Geezus, that garbage is still going on? EA Spouse alone was well over a decade ago. That, and all the many, many other examples (often less extreme, but still entirely unacceptable IMO) was exactly the reason I decided at the last minute (in college), to change my long-standing plans and not pursue a career in that industry after all. Several *years* ago, I was under the impression that problem had finally been changing? Is that not so? I was considering getting a job in the games industry, so I applied to a bunch of places in the UK during my final year of university. When you filtered out the jobs that were looking for years of industry experience, then filtered out the jobs that expected you to work terribly long hours, you got to the positions that said, We'll get you started as a tester. I switched to web development, where I work roughly 9-5 for a good salary, and I never looked back. Same here. I did managed to get into some interviews at a few AAA studios, attended two GDCE and got to know some people in the industry. But the salary that gets paid, alongside the amount of hours one is forced to work which get rewarded by being fired at the end of the project, have made me choose to work in the regular software industry instead. -- Paulo
Re: A Perspective on D from game industry
On Monday, 16 June 2014 at 04:18:28 UTC, Nick Sabalausky wrote: On 6/15/2014 4:53 PM, w0rp wrote: I'm going to try my hand at making a game with 2.066, because I believe @nogc is a final piece in a puzzle of making doing that easy. Much like writing bare metal D code without the runtime, I'm going to try my hand at writing D code with the main function marked as @nogc, because I reckon it's going to leave me with a saner set of syntax and semantics than either C or C++ in the end, with none of the drawbracks from the stop the world effect in a game loop. Having said that, I do think there's some kind of brain malfunction on the part of games programmers that makes them think is slow and can't escape from when they hear garbage collector and makes things more complicated and slower when they hear template. Neither of these things are true. I think C++ has caused a lot of brain damage to a lot of unfortunate souls. One consequence was making those souls think that the C and C++ compilation model is a synonym for all languages that compile to native code. -- Paulo
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 16:42:22 UTC, Abdulhaq wrote: On Sunday, 15 June 2014 at 13:19:12 UTC, Russel Winder via Digitalmars-d wrote: On Sun, 2014-06-15 at 12:30 +, Abdulhaq via Digitalmars-d wrote: […] learning the Android API - after all, JDK8 + tooling is bearable now. On the other hand Android API is Apache Harmony which is Java 6. Yes I keep forgetting that - wishful thinking maybe. Of note: Groovy finally works on Android, so you can use what Java 8 brings, on Java 6 and Java 7 using Groovy. And note Groovy may be a dynamic language, but it is also a static language. I'll look into it. Perhaps this question is just too broad, but if you wanted to develop an application on the Android platform right now, what approach would you take? Java, Groovy, web-based? I have played around with C++ for a small graphics application, but note that the NDK does only support game related APIs. When using middleware like Qt, you have access to the majority of APIs but then have to pay the JNI marshaling cost. -- Paulo
Re: DIP63 : operator overloading for raw templates
On Sunday, 15 June 2014 at 18:32:31 UTC, Dicebot wrote:
http://wiki.dlang.org/DIP63
This is solution for a problem I am currently having with
implementing http://wiki.dlang.org/DIP54 (afair it was also
mentioned by Timon Gehr during old discussion of that DIP)
New proposed semantics ( to catch your attention and get to
read the link ;) ):
template Pack(T...)
{
alias expand = T;
alias opIndex(size_t index) = T[index];
alias opSlice(size_t lower, size_t upper) =
Pack!(T[lower..upper]);
alias opDollar = T.length;
}
// no ambiguity as Pack!(int, int) is not a valid type
// is(element == int)
alias element = Pack!(int, int)[1];
I guess there's no way around it, but it seems inconsistent that
the operators are defined as templated aliases instead of
functions as anywhere else. Could you add a paragraph to the DIP
which points this out and give a short justification?
Re: Out of sight out of mind
On Sun, 2014-06-15 at 19:28 +, bearophile via Digitalmars-d wrote: Andrew Edwards: How do you recover your work from the GitHub five years from now when GitHub falls off the edge of the earth Online sites are ephemeral. So unless there is a way to move the bug repository off GitHub if the need arises, I am not going to appreciate the idea of moving bugs to GitHub. Given the current site is equally ephemeral, isn't this a sophistic argument? Switching bug reporting systems is not-trivial, always. The issue though is workflow for those who should be using it. The point being made here is really: what is the best system for creating an active system of users reporting and developers fixing bugs. There has been a directly analogous argument going on with SCons. We shifted from Subversion on Tigris with it's bug tracker, to Mercurial on BitBucket but keeping the Tigris bug tracker because it has lots of wizzy functionality and the BitBucket bug tracker was poor. However despite the wizzy functionality of the bugtracker, it has become fallow – no-one uses it because it is not front and centre with the repository. However the BitBucket system is not good enough, and the Tigris one cannot be sanely connected to BitBucket. We are in the middle of experiments with a third way: an independent bugtracker that allows for two way linkage to the BitBucket repositories. It is a lot of work to prepare the ground and make the change, but it is being done because the current workflow is failing. Just because a bugtracker is a good one, doesn't make it one that is good to use in a given context. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Out of sight out of mind
Andrew Edwards wrote in message news:lnkeji$5ve$1...@digitalmars.com... This happens because we have two separate systems (one tracking problems, another tracking the resolution), both of which compete for the same precious and extremely limited resource: the volunteer time of developers. I disagree, github is only manage because it has an order of magnitude less information. Having a prettier and more closely integrated bug tracker would be nice, but the disruption and information loss caused by switching makes it seem not worthwhile to me.
Re: Out of sight out of mind
Russel Winder: Given the current site is equally ephemeral, The current site is under dlang.org, it's not ephemeral. Bye, bearophile
Re: A Perspective on D from game industry
On Monday, 16 June 2014 at 08:22:59 UTC, Paulo Pinto wrote: I have played around with C++ for a small graphics application, but note that the NDK does only support game related APIs. When using middleware like Qt, you have access to the majority of APIs but then have to pay the JNI marshaling cost. Yep, this is true. For a while I believe that the swedish cross platform product MoSync would pull it off by compiling C++ to java etc. It was pretty nice for what it aimed to do, but apparently the market was not ready for it and the Android/iPhone/Windows platforms started to diverge their UIs at a fast rate making cross platform design difficult. You also have the Marmalade SDK which allows cross platform game coding in C/C++, but it costs real money (coming from a game studio). Anyway, with Swift out, writing regular non-visual apps in that language makes most sense, then porting it to Java. C++ can be used for backend engines, but for anything in the user interface it makes more sense to either special case it for the native APIs or go HTML5.
Is D production-ready?
Hi! A while ago, after my journey with PHP and Python, I've decided to learn C++. However, the more I learned, the more it got complicated. I think what Scott Meyer said in his talk was the main reason: the language was inconsistent; it didn't make sense as a whole. It always needed an extra explanation. I saw D. It is unstable! they said, There aren't enough tools! they said. I thought, If I learn C++, he learns C++, then how the hell alternatives are supposed to rise? I felt responsible. I wanted to contribute to D community. So I gave D a shot. People were kind of right – it was hard for a beginner for me to get into. I mean, I spent a whole day trying to make DSFML work. I wasn't trying to produce anything, so I was happy that I spent my time learning those things. I'm getting better – I still don't consider myself as a programmer, but I'm getting better. (Sorry about the storytelling, I just wanted to share.) Now I want to know if the language is production-ready. I can't really see anything besides abandoned libraries written in D. Is it possible – for example – to write a simple 2D game, or an automation program, or a text editor in D? I know the language is perfectly capable, but I'm not sure if the tools are mature enough. Does D have a mature and cross-platform GUI library? Does D have a mature SFML or SDL binding? Are there any advices you can give me? By the way, sorry for my English. Thank you! John
Re: Is D production-ready?
On Monday, 16 June 2014 at 10:24:46 UTC, John Petal wrote: Hi! A while ago, after my journey with PHP and Python, I've decided to learn C++. However, the more I learned, the more it got complicated. I think what Scott Meyer said in his talk was the main reason: the language was inconsistent; it didn't make sense as a whole. It always needed an extra explanation. I saw D. It is unstable! they said, There aren't enough tools! they said. I thought, If I learn C++, he learns C++, then how the hell alternatives are supposed to rise? I felt responsible. I wanted to contribute to D community. So I gave D a shot. People were kind of right – it was hard for a beginner for me to get into. I mean, I spent a whole day trying to make DSFML work. I wasn't trying to produce anything, so I was happy that I spent my time learning those things. I'm getting better – I still don't consider myself as a programmer, but I'm getting better. (Sorry about the storytelling, I just wanted to share.) Now I want to know if the language is production-ready. I can't really see anything besides abandoned libraries written in D. Is it possible – for example – to write a simple 2D game, or an automation program, or a text editor in D? I know the language is perfectly capable, but I'm not sure if the tools are mature enough. Does D have a mature and cross-platform GUI library? Does D have a mature SFML or SDL binding? Are there any advices you can give me? By the way, sorry for my English. Thank you! John And I should add: Would you mind sharing something where you use D actively? Thank you! John
Re: Is D production-ready?
On Monday, 16 June 2014 at 10:24:46 UTC, John Petal wrote: Does D have a mature SFML or SDL binding? http://code.dlang.org/packages/derelict-sfml2 and http://code.dlang.org/packages/derelict-sdl2 Are available. I have personally used the SDL2 bindings on both Windows and Mac and they work perfectly so far. Just download the library bindings from libsdl.org and go! For both SFML2 and SDL2, it uses the C interface, so the tutorials using C are the ones you'll want to pay attention to. In addition, there's GFM: http://code.dlang.org/packages/gfm It wraps SDL2 in a bit of a nicer interface (I had trouble using gfm as a dependency since ~master references gfm:bgfx which doesn't exist in the dub registry yet ... but gfm:sdl2 works when used as the dependency, however, it's somewhat new and incomplete ... could use some contributions, I think)
Re: Is D production-ready?
On Monday, 16 June 2014 at 10:39:42 UTC, Chris Cain wrote: On Monday, 16 June 2014 at 10:24:46 UTC, John Petal wrote: Does D have a mature SFML or SDL binding? http://code.dlang.org/packages/derelict-sfml2 and http://code.dlang.org/packages/derelict-sdl2 Are available. I have personally used the SDL2 bindings on both Windows and Mac and they work perfectly so far. Just download the library bindings from libsdl.org and go! For both SFML2 and SDL2, it uses the C interface, so the tutorials using C are the ones you'll want to pay attention to. In addition, there's GFM: http://code.dlang.org/packages/gfm It wraps SDL2 in a bit of a nicer interface (I had trouble using gfm as a dependency since ~master references gfm:bgfx which doesn't exist in the dub registry yet ... but gfm:sdl2 works when used as the dependency, however, it's somewhat new and incomplete ... could use some contributions, I think) Ahem, looks like I commited something too early. This is a bug. In the mean time you can use the ==1.1.1 version. What are you missing in gfm:sdl2? Please report :) I recognize for now using the wrapper brings marginal utility.
Re: Is D production-ready?
On Monday, 16 June 2014 at 10:24:46 UTC, John Petal wrote: I can't really see anything besides abandoned libraries written in D. Is it possible – for example – to write a simple 2D game, or an automation program, or a text editor in D? I know the language is perfectly capable, but I'm not sure if the tools are mature enough. Does D have a mature and cross-platform GUI library? Does D have a mature SFML or SDL binding? Are there any advices you can give me? By the way, sorry for my English. Thank you! John code.dlang.org
Re: Is D production-ready?
If you see abandoned libraries, you're probably looking at DSource, which is dead. Everything has long since moved to GitHub. Derelict provides good SDL2 as well as SFML2 bindings (and bindings to many other APIs). For GUI, (assuming you don't want Windows-only ones) TkD is simple and easy-to-use (think TkInter in Python) although a bit new, GtkD is usable but not perfect, and there are many other frameworks/libs/bindings. If you want very simple GUI in an OpenGL app, dimgui should work. https://github.com/DerelictOrg https://github.com/nomad-software/tkd https://github.com/d-gamedev-team/dimgui Also see the wiki (the old wiki is dead, just like DSource): http://wiki.dlang.org/Libraries_and_Frameworks And the DUB packages of libs and other projects: http://code.dlang.org/
Re: Is D production-ready?
NO IT'S NOT! no working/incomplete windows headers for 32 and 64 bit. no gui or db lib and tons of abandoned libs and proggies that you mentioned. if your are on linux like most of the lieutenants and the vice-general you may be fine. On Monday, 16 June 2014 at 10:28:50 UTC, John Petal wrote: On Monday, 16 June 2014 at 10:24:46 UTC, John Petal wrote: Hi! A while ago, after my journey with PHP and Python, I've decided to learn C++. However, the more I learned, the more it got complicated. I think what Scott Meyer said in his talk was the main reason: the language was inconsistent; it didn't make sense as a whole. It always needed an extra explanation. I saw D. It is unstable! they said, There aren't enough tools! they said. I thought, If I learn C++, he learns C++, then how the hell alternatives are supposed to rise? I felt responsible. I wanted to contribute to D community. So I gave D a shot. People were kind of right – it was hard for a beginner for me to get into. I mean, I spent a whole day trying to make DSFML work. I wasn't trying to produce anything, so I was happy that I spent my time learning those things. I'm getting better – I still don't consider myself as a programmer, but I'm getting better. (Sorry about the storytelling, I just wanted to share.) Now I want to know if the language is production-ready. I can't really see anything besides abandoned libraries written in D. Is it possible – for example – to write a simple 2D game, or an automation program, or a text editor in D? I know the language is perfectly capable, but I'm not sure if the tools are mature enough. Does D have a mature and cross-platform GUI library? Does D have a mature SFML or SDL binding? Are there any advices you can give me? By the way, sorry for my English. Thank you! John And I should add: Would you mind sharing something where you use D actively? Thank you! John
Re: Is D production-ready?
On 6/16/2014 7:39 PM, Chris Cain wrote: On Monday, 16 June 2014 at 10:24:46 UTC, John Petal wrote: Does D have a mature SFML or SDL binding? http://code.dlang.org/packages/derelict-sfml2 and http://code.dlang.org/packages/derelict-sdl2 Are available. I have personally used the SDL2 bindings on both Windows and Mac and they work perfectly so far. Just download the library bindings from libsdl.org and go! For both SFML2 and SDL2, it uses the C interface, so the tutorials using C are the ones you'll want to pay attention to. In addition, there's GFM: http://code.dlang.org/packages/gfm It wraps SDL2 in a bit of a nicer interface (I had trouble using gfm as a dependency since ~master references gfm:bgfx which doesn't exist in the dub registry yet ... but gfm:sdl2 works when used as the dependency, however, it's somewhat new and incomplete ... could use some contributions, I think) Note that the DerelictSFML2 binding suffers from a long-standing DMD bug[1] on Linux, which makes it unusable when compiling as 64-bit. This is the reason Jeremy DeHaan created DSFML and DSFML-C in the first place, just to work around this bug. Looks like it may be partially fixed in the next release, though, so it's getting closer to no longer being a problem. The SDL2 binding is mature and stable. It also includes bindings for SDL_mixer/net/ttf/image. Aside from these, you'll also find bindings for OpenAL, OpenGL, GLFW3, FreeImage, FreeType and more in the DerelictOrg github group[2], all of which are available via dub[3]. [1] https://issues.dlang.org/show_bug.cgi?id=5570 [2] https://github.com/DerelictOrg [3] http://code.dlang.org/ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Re: A Perspective on D from game industry
C++'s lack of finally didn't do any favors for exception handling's popularity, either. (Has finally finally been added?) Just noting: exceptions are rarely used in gamedev. Also I agree with Bjarne RIAA is preferable to finally in the C++ context, finally makes more sense in a language with GC for dealing with none memory resources. You say the industry isn't likely to produce its own tools. While I'm in no position to disagree, I am surprised to hear that since the industry is known to produce some of its own middleware. EA is said to have a fairly sophisticated in-house UI authoring system, and of course they have Frostbite. Various studios have developed in-house engines, and many of the big-name ones (ex, Unreal Engine, Source, CryEngine) started out as in-house projects. Would you say those are more exceptional cases, or did you mean something more specific by tools? Yeah I should clarify. I'm not really speaking of middleware or engines; gamedev produces plenty of that, but always in bog standard C or C++. What I don't see, is the game industry producing a programming language that would be adopted outside of the company that produced it. Or assisting in the development of an existing one. Despite their being (guessing here) tens of thousands of professional C++ game developers, are any of them attending ISO C++ meetings? I doubt it. If a game studio does produce anything resembling a language/associated tools it would very like proprietary. -Take Epic, they created Unreal script(barf), nobody else uses it. Epic has abandoned it in UE4. -Naughty Dog, they had a custom lisp based development at one point, nobody else used it, I believe they now use Racket to generate C++ That is some *crazy*, impressive, *herculean*-effort stuff. CLEARLY, significant parts of the game industry genuinely understand the importance of investments into technology. And yet...all the complaining they do about C++ and they *still* won't write the language they want? Some of this comes from the proprietary tooling they end up using on each platform. It is supplied by the platform owner. Language wise, you get a C++ compiler, and not necessary a very good one. Making a clean replacement for C++ isn't really enough. Any C++ replacement has to interop well with C++ because of the existing mountain of C++ based middleware, libraries, and engines. Several *years* ago, I was under the impression that problem had finally been changing? Is that not so? My experience is that is has changed for the better. I'm in the Western US though, and Manu is (I believe) in Australia. If a studio tried to make me crunch extra hours without pay I'd just refuse, finding a different job isn't that hard /shrug. I switched to web development, where I work roughly 9-5 for a good salary, and I never looked back. The state of California passed laws after the EA spouse case, so if you work in California or for a CA based company they cannot legally make you work more than 40 hrs/week. Scummy places may try to get more hours out of you by applying peer pressure or some such crap, but they cannot legally do so-
Re: A Perspective on D from game industry
On 06/16/2014 03:12 AM, H. S. Teoh via Digitalmars-d wrote: This insight therefore causes D's templates to mesh very nicely with CTFE to form a beautifully-integrated whole. I wouldn't go exactly that far. For one thing, CTFE cannot be used to manipulate types.
Dynamic array length ABI unit
Regarding the D ABI, http://dlang.org/abi.html , I've noticed that the description for dynamic arrays seems ambiguous: offset property contents 0.length array dimension size_t .ptr pointer to array data Couldn't array dimension be either in bytes or in T units, for a T[]? It seems to be in bytes (I had assumed it was in T units). If you agree that it is ambiguous, please tweak the description to be more precise.
Re: Is D production-ready?
On Monday, 16 June 2014 at 10:51:11 UTC, ponce wrote: Ahem, looks like I commited something too early. This is a bug. In the mean time you can use the ==1.1.1 version. Actually, sadly, you can't use gfm at all (or, at least, I can't) ... It complains about not being able to satisfy dependencies, even specifying 1.1.1. (That might be a dub bug, though) Though just manually specifying gfm:sdl2 and such is fine. What are you missing in gfm:sdl2? Please report :) I recognize for now using the wrapper brings marginal utility. No real need for reports, yet. AFAIK, all SDL2 things are available, but more wrappers could be available for things, I think. Plus it's best to save reports for things until after I get out of this stage of using your library: http://mlkshk.com/r/97VP (i_have_no_idea_what_im_doing_dog.jpg) If I start coming up with things, I'll start doing pull requests :) Thanks btw for gfm. So far it's been a pleasure to work with (despite not working with it as much as I'd like)
Re: A Perspective on D from game industry
On 16/06/2014 11:39 p.m., Timon Gehr wrote: On 06/16/2014 03:12 AM, H. S. Teoh via Digitalmars-d wrote: This insight therefore causes D's templates to mesh very nicely with CTFE to form a beautifully-integrated whole. I wouldn't go exactly that far. For one thing, CTFE cannot be used to manipulate types. I would go that far, when combining string mixins, templates and CTFE. It can produce whole new set of code from a given set. Just look at dvorm in its Query class. What with generating methods like: Query!Book edition_eq(ubyte)
Re: Is D production-ready?
On 16/06/2014 11:14 p.m., seeker wrote: NO IT'S NOT! no working/incomplete windows headers for 32 and 64 bit. no gui or db lib and tons of abandoned libs and proggies that you mentioned. Wow now. For database libraries, there is a few choices out there currently. Mysql, Mongodb, Redis and Postgresql. There's also a couple different ORM's. If you really feel the need to get access to some more arcane database's there is always OpenDBX (c library) but getting it to compile is a little harder on Windows (library not the binding). As for Windows headers, there is one set pretty well manually developed floating around. I also have my own version that was generated directly from MingW64's headers. Not fully tested but so far not really any issues. So I'd say almost fully complete (few edge cases I missed in the script). if your are on linux like most of the lieutenants and the vice-general you may be fine. Majority of the time this isn't an issue unless its a 'new fangled feature' like shared libraries. Now Mac OSX on the other hand.. On Monday, 16 June 2014 at 10:28:50 UTC, John Petal wrote: On Monday, 16 June 2014 at 10:24:46 UTC, John Petal wrote: Hi! A while ago, after my journey with PHP and Python, I've decided to learn C++. However, the more I learned, the more it got complicated. I think what Scott Meyer said in his talk was the main reason: the language was inconsistent; it didn't make sense as a whole. It always needed an extra explanation. I saw D. It is unstable! they said, There aren't enough tools! they said. I thought, If I learn C++, he learns C++, then how the hell alternatives are supposed to rise? I felt responsible. I wanted to contribute to D community. So I gave D a shot. People were kind of right – it was hard for a beginner for me to get into. I mean, I spent a whole day trying to make DSFML work. I wasn't trying to produce anything, so I was happy that I spent my time learning those things. I'm getting better – I still don't consider myself as a programmer, but I'm getting better. (Sorry about the storytelling, I just wanted to share.) Now I want to know if the language is production-ready. I can't really see anything besides abandoned libraries written in D. Is it possible – for example – to write a simple 2D game, or an automation program, or a text editor in D? I know the language is perfectly capable, but I'm not sure if the tools are mature enough. Does D have a mature and cross-platform GUI library? Does D have a mature SFML or SDL binding? Are there any advices you can give me? By the way, sorry for my English. Thank you! John And I should add: Would you mind sharing something where you use D actively? Thank you! John
Re: Dynamic array length ABI unit
Luís Marques wrote in message news:fykakpufqivskbnus...@forum.dlang.org... Regarding the D ABI, http://dlang.org/abi.html , I've noticed that the description for dynamic arrays seems ambiguous: offset property contents 0.length array dimension size_t .ptr pointer to array data Couldn't array dimension be either in bytes or in T units, for a T[]? It seems to be in bytes (I had assumed it was in T units). If you agree that it is ambiguous, please tweak the description to be more precise. It _is_ in T units. It is exactly the dimension of the array, not the size in memory.
D Lang Web Site (and Wiki): How many accounts must one have?
Between bugs, code.lang.org, etc., I must have multiple log-in accounts and i've run out of e-mail addresses. Can't there be a single account for dlang.org? Or maybe I'm doing something wrong? Thanks. Best regards, -Tom
Re: Is D production-ready?
On Monday, 16 June 2014 at 10:24:46 UTC, John Petal wrote: Is it possible – for example – to write a simple 2D game, or an automation program, or a text editor in D? Speaking by myself, I was able to write both: Game and Text Editor, using Derelict2 and Cairo respectively. PS: I know the general concerns but anyway don't be afraid, give it a try. Matheus.
Re: D Lang Web Site (and Wiki): How many accounts must one have?
On Monday, 16 June 2014 at 12:03:49 UTC, Tom Browder via Digitalmars-d wrote: Between bugs, code.lang.org, etc., I must have multiple log-in accounts and i've run out of e-mail addresses. Can't there be a single account for dlang.org? The systems run on different machines and are managed by different people. Short of convincing the maintainers of the different services to add OpenID support, there is not much you can do to avoid having separate accounts. However, it shouldn't be a problem to just use the same email address for all of them. Why would it be for you? Best, David
Re: Is D production-ready?
On Monday, 16 June 2014 at 11:46:57 UTC, Chris Cain wrote: On Monday, 16 June 2014 at 10:51:11 UTC, ponce wrote: Ahem, looks like I commited something too early. This is a bug. In the mean time you can use the ==1.1.1 version. Actually, sadly, you can't use gfm at all (or, at least, I can't) ... It complains about not being able to satisfy dependencies, even specifying 1.1.1. (That might be a dub bug, though) I'll look into it. Depending on the parent package named gfm is fortunately never what you really want, since it depends itself on all other sub-packages which would make it a monolithic dependency. Specifying sub-packages instead in dependencies is the intended usage. No real need for reports, yet. AFAIK, all SDL2 things are available, but more wrappers could be available for things, I think. Plus it's best to save reports for things until after I get out of this stage of using your library: http://mlkshk.com/r/97VP (i_have_no_idea_what_im_doing_dog.jpg) Fine. If I start coming up with things, I'll start doing pull requests :) Thanks btw for gfm. So far it's been a pleasure to work with (despite not working with it as much as I'd like) It will only become better when you start complaining :)
Re: Dynamic array length ABI unit
On Monday, 16 June 2014 at 11:44:53 UTC, Luís Marques wrote: Regarding the D ABI, http://dlang.org/abi.html , I've noticed that the description for dynamic arrays seems ambiguous: offset property contents 0.length array dimension size_t .ptr pointer to array data Couldn't array dimension be either in bytes or in T units, for a T[]? It seems to be in bytes (I had assumed it was in T units). If you agree that it is ambiguous, please tweak the description to be more precise. Dimension seems to say number of elements to me without much room for interpretation (which it indeed is). Feel free to open a pull request if you have an idea for a better description, though. Best, David
Re: Is D production-ready?
On 6/16/2014 8:14 PM, seeker wrote: NO IT'S NOT! no working/incomplete windows headers for 32 and 64 bit. no gui or db lib and tons of abandoned libs and proggies that you mentioned. if your are on linux like most of the lieutenants and the vice-general you may be fine. YES IT IS! I've been using D on Windows just fine for years and so have several others. The Windows API binding works just fine if you need the Win32 API, either Andrej Mitrovic's version at github[1] or the original at DSource[2]. There are a growing number of tools and GUI libraries available, too. Just because the compiler doesn't ship with everything in one nice package, and just because the Windows ecosystem doesn't have a plethora of tools that you can count on being available like on Linux, does not mean DMD development favors Linux. [1] https://github.com/AndrejMitrovic/DWinProgramming [2] http://www.dsource.org/projects/bindings/wiki/WindowsApi --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Re: DIP63 : operator overloading for raw templates
On Monday, 16 June 2014 at 08:56:24 UTC, Marc Schütz wrote:
On Sunday, 15 June 2014 at 18:32:31 UTC, Dicebot wrote:
http://wiki.dlang.org/DIP63
This is solution for a problem I am currently having with
implementing http://wiki.dlang.org/DIP54 (afair it was also
mentioned by Timon Gehr during old discussion of that DIP)
New proposed semantics ( to catch your attention and get to
read the link ;) ):
template Pack(T...)
{
alias expand = T;
alias opIndex(size_t index) = T[index];
alias opSlice(size_t lower, size_t upper) =
Pack!(T[lower..upper]);
alias opDollar = T.length;
}
// no ambiguity as Pack!(int, int) is not a valid type
// is(element == int)
alias element = Pack!(int, int)[1];
I guess there's no way around it, but it seems inconsistent
that the operators are defined as templated aliases instead of
functions as anywhere else. Could you add a paragraph to the
DIP which points this out and give a short justification?
+1
And why these operators only ?
struct StaticVariant
{
alias opAssign(T t) = (immutable T x = t; alias x this;)
}
struct Json
{
immutable (StaticVariant[string]);
alias opDispatch(string s, T t) = (data[s] ~= t);
alias opDispatch(string s) = data[s];
}
void main()
{
Json john;
john.size = 1.78;
john.name = John;
float johnSize = john.size;
string johnName = john.name;
}
Ok I am a dreaming D beginner. In this case multiple alias this
would be better. Also, I don't understand why we can't append
immutable array thanks to CTFE too. D is awesome in lots of ways
but it's quite frustrating too because it frees your imagination.
Where do we set the limit in terms of meta-meta-stuff ?
Re: Is D production-ready?
On Monday, 16 June 2014 at 10:24:46 UTC, John Petal wrote: Are there any advices you can give me? If nothing can convince you, learning D will make it way easier to learn C++, and you won't write the same C++ either.
Re: A Perspective on D from game industry
On Monday, 16 June 2014 at 11:49:11 UTC, Rikki Cattermole wrote: I would go that far, when combining string mixins, As far as I can tell string mixins have the same bad properties that macros have. It makes automatic translation very difficult and makes reasoning about code more difficult. It is a cheap and effective solution, but without any trace of beauty... A design blunder IMHO.
Re: D Lang Web Site (and Wiki): How many accounts must one have?
On Mon, Jun 16, 2014 at 7:23 AM, David Nadlinger via Digitalmars-d digitalmars-d@puremagic.com wrote: ... However, it shouldn't be a problem to just use the same email address for all of them. Why would it be for you? Well, I started with a wiki editing account which works fine. Then, when I tried to file a bug bugzilla wouldn't let me in so I tried to start a new account but it wouldn't let me use my usual e-mail so I used an alternate one. Next I wanted to get into code.lang.org and same thing: the other two logins won't work. All three use an e-mail or user name, but none can be the same apparently. -Tom
Re: DIP63 : operator overloading for raw templates
Well I realized I was a bit off-topic there since it is not about ctfe operators but raw template operators. I'm out.
Re: Tail pad optimization, cache friendlyness and C++ interrop
On 06/16/2014 06:49 AM, Walter Bright wrote: On 6/15/2014 4:26 PM, Timon Gehr wrote: On 06/16/2014 01:06 AM, Walter Bright wrote: I don't understand your question. I don't know what is unhelpful about saying that @safe refers to memory safety. ... You stated the two to be equivalent earlier, which is impossible. It is for Java, No. sun.misc.Unsafe can be used to write memory safe code. why should D be different? The list is not restricted to syntactic issues. (Yes it is, No, it is not. For example, assigning an int to a pointer is a semantic issue, not a [syntactic] one. ... By extension, memory safety is a semantic issue. Since it is non-trivial, it is in general not verifiable. (This is Rice's Theorem.) @safe-ty OTOH is a verifiable property of the program. ... I'm just trying to find the definition/theorem we do not agree on. I strongly suggest that you can help by identifying specific issues in bugzilla My point was that no implementation of @safe whatsoever can make it _equivalent_ to memory safety (i.e. @safe will never single out precisely those programs that do not corrupt memory). It will always only approximate memory safety. This is not a bug, it's just a fact. and marking them with the 'safe' keyword, as I suggested earlier. In my book, the main problem is that @safe is not specified in a way that is easy to be verified to guarantee memory safety. I think plugging holes one after another as they are discovered in real code until _hopefully_ none remain is not a very productive use of time. We should strive to keep @safe sound during its whole implementation. I do not believe that memory safety is a difficult concept to agree on. Why? Many superficially simple informal concepts are difficult to agree on. In this case this is witnessed by the fact that you do not seem to want to ban undefined behaviour from @safe code which I can't agree with.
Re: Dynamic array length ABI unit
On Monday, 16 June 2014 at 12:27:03 UTC, David Nadlinger wrote: Dimension seems to say number of elements to me without much room for interpretation (which it indeed is). Feel free to open a pull request if you have an idea for a better description, though. I think you are right, my comment made more sense if it was the other way (number of bytes). My bad, sorry for decreasing the S/N ratio of the forum :P
Re: Dynamic array length ABI unit
On Monday, 16 June 2014 at 11:54:27 UTC, Daniel Murphy wrote: Couldn't array dimension be either in bytes or in T units, for a T[]? It seems to be in bytes (I had assumed it was in T units). If you agree that it is ambiguous, please tweak the description to be more precise. It _is_ in T units. It is exactly the dimension of the array, not the size in memory. Ah, OK. I was mislead by the following: 1: int[] a1 = [42]; 2: ubyte[] a2 = cast(ubyte[]) a1; 3: writeln(a2); I thought line 2 did a reinterpret_cast on the a1 array header (length + ptr), so I expected a2 == [42], but it is equal to [42, 0, 0, 0] (casts the array contents, adjusts the array length). Forcing a reinterpret_cast-style cast shows that indeed length is in T units, as I originally expected: int[] a1 = [42]; void* p = a1; ubyte[] a2 = *cast(ubyte[]*) p; assert(a2 == [42]);
Re: Is D production-ready?
On Monday, 16 June 2014 at 10:24:46 UTC, John Petal wrote: Now I want to know if the language is production-ready. I've been using it on live production websites for a handful of jobs since 2009 with no significant problems.
Re: Is D production-ready?
On Mon, 16 Jun 2014 11:14:05 +, seeker wrote: NO IT'S NOT! no working/incomplete windows headers for 32 and 64 bit. no gui or db lib and tons of abandoned libs and proggies that you mentioned. if your are on linux like most of the lieutenants and the vice-general you may be fine. On Monday, 16 June 2014 at 10:28:50 UTC, John Petal wrote: On Monday, 16 June 2014 at 10:24:46 UTC, John Petal wrote: Hi! A while ago, after my journey with PHP and Python, I've decided to learn C++. However, the more I learned, the more it got complicated. I think what Scott Meyer said in his talk was the main reason: the language was inconsistent; it didn't make sense as a whole. It always needed an extra explanation. I saw D. It is unstable! they said, There aren't enough tools! they said. I thought, If I learn C++, he learns C++, then how the hell alternatives are supposed to rise? I felt responsible. I wanted to contribute to D community. So I gave D a shot. People were kind of right – it was hard for a beginner for me to get into. I mean, I spent a whole day trying to make DSFML work. I wasn't trying to produce anything, so I was happy that I spent my time learning those things. I'm getting better – I still don't consider myself as a programmer, but I'm getting better. (Sorry about the storytelling, I just wanted to share.) Now I want to know if the language is production-ready. I can't really see anything besides abandoned libraries written in D. Is it possible – for example – to write a simple 2D game, or an automation program, or a text editor in D? I know the language is perfectly capable, but I'm not sure if the tools are mature enough. Does D have a mature and cross-platform GUI library? Does D have a mature SFML or SDL binding? Are there any advices you can give me? By the way, sorry for my English. Thank you! John And I should add: Would you mind sharing something where you use D actively? Thank you! John I have web site thats planned to launch next month that runs on windows, db included!
Re: D Lang Web Site (and Wiki): How many accounts must one have?
On Monday, 16 June 2014 at 12:50:50 UTC, Tom Browder via Digitalmars-d wrote: All three use an e-mail or user name, but none can be the same apparently. This is not the case. Maybe you just had accounts at the other sites already? Of course, you could also be hitting some strange bug. In that case, the best thing to do would be to contact the respective admins (issues.dlang.org: Brad Roberts, code.dlang.org: Sönke Ludwig) to try and figure out what is going on. Best, David
Re: Dynamic array length ABI unit
On Monday, 16 June 2014 at 13:11:24 UTC, Luís Marques wrote: Ah, OK. I was mislead by the following: 1: int[] a1 = [42]; 2: ubyte[] a2 = cast(ubyte[]) a1; 3: writeln(a2); Ah, that clears up the confusion. Array casts are smart and automatically divide down the length as needed, or fail otherwise. David
Re: foreach
On Sun, 15 Jun 2014 20:38:53 -0400, H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sun, Jun 15, 2014 at 03:05:37AM -0400, Nick Sabalausky via Digitalmars-d wrote: [...] True story: I once had to put up with a production codebase (the company's *flagship* product) that wasn't asm (it was VB6) and yet was filled with garbage like this: if ...cond... then ...statements... goto somelabel end ...statements... somelabel: Got posted on thedailywtf for that one. I see code like that *all the time*. It's about the only sane way you can write error-handling code in C: No, you are missing something. Something *else*, that goes along with if. ;) -Steve
Re: Out of sight out of mind
Does github link issues with pull requests (and the conversation) and commits? Does it link issues with sub issues/tasks? Can Issues link to other repos (link issues that are in both runtime and std lib)? If it does have these features (and they are easy to use) then I would back it. I have found jira to be one of the best trackers out there. -Byron
Re: D Lang Web Site (and Wiki): How many accounts must one have?
On Mon, Jun 16, 2014 at 8:21 AM, David Nadlinger via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 16 June 2014 at 12:50:50 UTC, Tom Browder via Digitalmars-d wrote: All three use an e-mail or user name, but none can be the same apparently. ... This is not the case. Maybe you just had accounts at the other sites already? Of course, you could also be hitting some strange bug. In that case, the best thing to do would be to contact the respective admins (issues.dlang.org: Brad Roberts, code.dlang.org: Sönke Ludwig) to try and figure out what is going on. Thanks for the contact info, David. Best, -Tom
Re: foreach
On Mon, Jun 16, 2014 at 09:24:56AM -0400, Steven Schveighoffer via Digitalmars-d wrote: On Sun, 15 Jun 2014 20:38:53 -0400, H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sun, Jun 15, 2014 at 03:05:37AM -0400, Nick Sabalausky via Digitalmars-d wrote: [...] True story: I once had to put up with a production codebase (the company's *flagship* product) that wasn't asm (it was VB6) and yet was filled with garbage like this: if ...cond... then ...statements... goto somelabel end ...statements... somelabel: Got posted on thedailywtf for that one. I see code like that *all the time*. It's about the only sane way you can write error-handling code in C: No, you are missing something. Something *else*, that goes along with if. ;) [...] Unfortunately, in C, that means a function with n statements will require n levels of if-else nesting. That may be more textbook-correct, but it would be far less readable than the already ugly if-error-goto construct above. T -- Старый друг лучше новых двух.
Re: A Perspective on D from game industry
On Mon, Jun 16, 2014 at 12:44:05PM +, via Digitalmars-d wrote:
On Monday, 16 June 2014 at 11:49:11 UTC, Rikki Cattermole wrote:
I would go that far, when combining string mixins,
As far as I can tell string mixins have the same bad properties that
macros have. It makes automatic translation very difficult and makes
reasoning about code more difficult. It is a cheap and effective
solution, but without any trace of beauty... A design blunder IMHO.
Actually, IIRC, string mixins were never designed to be nice -- they
started as a kind of temporary last-resort kludge that got put in, in
lieu of a true AST macro system, with the view that it would meet the
current metaprogramming needs until the latter, ostensibly superior,
solution came along. Unfortunately, AST macros never happened, and
string mixins kinda took hold in the D codebase, so that's what we have
now.
I would personally avoid using string mixins unless there's absolutely
no other way to achieve what you want -- they're a kind of last-resort
nuclear warhead that you don't bring out unless all the other guns fail
to win the battle.
Having said that, though, proper use of string mixins with CTFE and
templates ('scuse me, *compile-time arguments* ;)) can be extremely
powerful, and one of the things that make D metaprogramming so awesome.
T
--
The whole problem with the world is that fools and fanatics are always so
certain of themselves, but wiser people so full of doubts. -- Bertrand
Russell. How come he didn't put 'I think' at the end of it? -- Anonymous
Re: foreach
On Mon, 16 Jun 2014 10:53:49 -0400, H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote: On Mon, Jun 16, 2014 at 09:24:56AM -0400, Steven Schveighoffer via Digitalmars-d wrote: On Sun, 15 Jun 2014 20:38:53 -0400, H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sun, Jun 15, 2014 at 03:05:37AM -0400, Nick Sabalausky via Digitalmars-d wrote: [...] True story: I once had to put up with a production codebase (the company's *flagship* product) that wasn't asm (it was VB6) and yet was filled with garbage like this: if ...cond... then ...statements... goto somelabel end ...statements... somelabel: Got posted on thedailywtf for that one. I see code like that *all the time*. It's about the only sane way you can write error-handling code in C: No, you are missing something. Something *else*, that goes along with if. ;) [...] Unfortunately, in C, that means a function with n statements will require n levels of if-else nesting. That may be more textbook-correct, but it would be far less readable than the already ugly if-error-goto construct above. The code above is not what you are talking about. It's straightforward if-else. -Steve
Swift does away with pointers == pervasive ARC
What say you to that, Walter? Apple have committed to pervasive ARC, which you consistently argue is not feasible... Have I missed something, or is this a demonstration that it is actually practical?
Re: A Perspective on D from game industry
On Monday, 16 June 2014 at 15:07:08 UTC, H. S. Teoh via
Digitalmars-d wrote:
Having said that, though, proper use of string mixins with CTFE
and
templates ('scuse me, *compile-time arguments* ;)) can be
extremely
powerful, and one of the things that make D metaprogramming so
awesome.
Sure, just like m4 and cpp can be extremely powerful. Too
powerful…
Re: A Perspective on D from game industry
On 06/16/2014 05:18 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Monday, 16 June 2014 at 15:07:08 UTC, H. S. Teoh via Digitalmars-d
wrote:
Having said that, though, proper use of string mixins with CTFE and
templates ('scuse me, *compile-time arguments* ;)) can be extremely
powerful, and one of the things that make D metaprogramming so awesome.
Sure, just like m4 and cpp can be extremely powerful. Too powerful…
I wouldn't go as far as comparing mixins to a text macro preprocessor
either. At least they are integrated into the language.
Re: A Perspective on D from game industry
On 6/15/14, 11:56 PM, w0rp wrote: I was considering getting a job in the games industry, so I applied to a bunch of places in the UK during my final year of university. When you filtered out the jobs that were looking for years of industry experience, then filtered out the jobs that expected you to work terribly long hours, you got to the positions that said, We'll get you started as a tester. I switched to web development, where I work roughly 9-5 for a good salary, and I never looked back. Pretty similar to me, although like Nick I never even tried to interview. Now I write iPhone games as a hobby with no pressure to try to make a living from it, and enjoy it quite a bit!
Re: Swift does away with pointers == pervasive ARC
On Monday, 16 June 2014 at 15:16:44 UTC, Manu via Digitalmars-d wrote: Have I missed something, or is this a demonstration that it is actually practical? All performance tests so far says Swift is slower than Objective-C, which is slow to begin with, but it is still in Beta. I don't think you are supposed to do signal processing in Swift, most apps can be done with higher level/script-like programming and leave the performance sensitive part to the rich iOS frameworks.
Re: Swift does away with pointers == pervasive ARC
On Monday, 16 June 2014 at 15:16:44 UTC, Manu via Digitalmars-d wrote: What say you to that, Walter? Apple have committed to pervasive ARC, which you consistently argue is not feasible... Have I missed something, or is this a demonstration that it is actually practical? Good luck writing games in Swift.
Re: Swift does away with pointers == pervasive ARC
On Monday, 16 June 2014 at 16:19:55 UTC, Dicebot wrote: On Monday, 16 June 2014 at 15:16:44 UTC, Manu via Digitalmars-d wrote: What say you to that, Walter? Apple have committed to pervasive ARC, which you consistently argue is not feasible... Have I missed something, or is this a demonstration that it is actually practical? Good luck writing games in Swift. https://github.com/fullstackio/FlappySwift
Re: An LLVM bug that affect both LDC and SDC. Worth pushing for
On Monday, 16 June 2014 at 06:09:28 UTC, deadalnix wrote: http://llvm.org/bugs/show_bug.cgi?id=20049 Basically when you have a closure in a closure and the whole thing get inlined, LLVM mess up, which result in compiler not being able to optimize GC allocation away. Probably worth pushing for. It does probably affect other functional languages as well, but I didn't checked. This is the corresponding D code: https://github.com/deadalnix/SDC/blob/master/tests/test0156.d Correct?
Re: Is D production-ready?
On Monday, 16 June 2014 at 10:24:46 UTC, John Petal wrote: Does D have a mature and cross-platform GUI library? I released this a month or so ago: http://code.dlang.org/packages/tkd It's fully cross-platform and very simple to use. If it's not as full featured as you need then try this: http://code.dlang.org/packages/gtk-d
