D simple web server
Hi, Because I have a personal project based on a custom web server, and I couldn't find one implemented in D(excepting vibe.d), I started to implement some web server classes in D with the hope that my work will be useful to someone else as well. If you are interested in this project, or if you want to contribute to it, here is the link to the git repository: https://github.com/gedaiu/DSWS Also, I don't have a lot of experience with D and I would apreciate if someone would like to spare some time for a code review for my work. Thanks, Bogdan
Re: D simple web server
On Saturday, 31 August 2013 at 16:42:11 UTC, gedaiu wrote:
Because I have a personal project based on a custom web server,
and I couldn't find one implemented in D(excepting vibe.d)
My cgi.d has one too:
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/cgi.d
===
void hello(Cgi cgi) { cgi.write(hello); }
mixin GenericMain!hello;
===
dmd test.d cgi.d -version=embedded_httpd
Then run test and it listens on port 8085 by default, and you can
change that with a command line argument --port 3000 for example.
Re: D simple web server
Your code seems rather nice.
That said, here are some remarks of a purely stylistic nature :-) :
- You can use foreach instead of for to simplify your loop
statements over arrays and other collections:
auto array = [1, 2, 3];
foreach (item; array) {
writeln (item);
}
foreach can also support indexed iteration of your items:
auto array = [a, b, c];
foreach (index, item; array) {
writefln (%d: %s, index, item);
}
and if you just want to iterate a certain amount of time, you can use
ranges:
foreach (index; 1..100) {
writeln (index);
}
- You don't have to put each class in a different file: you still can do
if you prefer it that way.
- I tend to prefer to have class members of same visibility grouped
together under a public:, protected: or private: block, either
using the colon or the braces instead of always specifying the
visibility - this kind of help me better understand what will be useful
when using the class.
- Associative arrays can be initialized with literals, so instead of
having lots of:
status_message[100] = Continue;
status_message[101] = ...
...
status_message[505] = HTTP Version not supported;
you can use:
status_message = [
100: Continue,
101: ...
505: HTTP Version not supported
];
which I find more concise.
- You can also use unified function calls:
instead of: to!string(port)
you can do: port.to!string
the latter having a more English feel when reading.
Again, these are purely stylistic considerations, D's flexibility allows
you to choose from many styles.
On a design standpoint, I would have preferred a delegate for the
processRequest() method instead of requiring the users to derive from
the WebServer class - on second thought, that may too be a stylistic
issue :-) .
Also related: I have started to write some high level bindings to the
Mongoose embedded webserver library, written in C (using Jacob
Carlsberg's dstep for the low level bindings). The source code is
available here: https://github.com/remy-j-a-moueza/mongooseD .
You may find some stuff to reuse or get inspiration from for your server.
Adam Ruppe also has a lot of interesting tools beyond the basic web
serving that you may get interested in
(https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff).
On 08/31/2013 06:42 PM, gedaiu wrote:
Hi,
Because I have a personal project based on a custom web server, and I
couldn't find one implemented in D(excepting vibe.d), I started to
implement some web server classes in D with the hope that my work will
be useful to someone else as well. If you are interested in this
project, or if you want to contribute to it, here is the link to the git
repository:
https://github.com/gedaiu/DSWS
Also, I don't have a lot of experience with D and I would apreciate if
someone would like to spare some time for a code review for my work.
Thanks,
Bogdan
Re: feature request: N-ary map
On Saturday, 22 June 2013 at 00:07:40 UTC, Timothee Cour wrote: On Fri, Jun 21, 2013 at 4:14 PM, Timothee Cour thelastmamm...@gmail.comwrote: On Fri, Jun 21, 2013 at 4:02 PM, Ali Çehreli acehr...@yahoo.com wrote: On 06/21/2013 03:57 PM, Diggory wrote: On Friday, 21 June 2013 at 22:56:04 UTC, Andrei Alexandrescu wrote: On 6/21/13 3:55 PM, Andrei Alexandrescu wrote: On 6/21/13 3:45 PM, Timothee Cour wrote: I'd like to support N-ary map, ie std.algorithm.map that takes 1 or more ranges as arguments and operates lazily on those. You can use zip from std.range. Timothee specifically said that he is trying to avoid zip: :) before: zip(a,b).map!(u=absDiff(u[0],**u[1])).reduce!fun; after: map!absDiff(a,b).reduce!fun; Ali also works great with string lambdas: eg: dotproduct: before: zip(u,v).map!a[0]*a[1].reduce!a+b; after: map!a*b(u,v).reduce!a+b; = clearer, and provides more room for optimizaton actually the version without the proposed N-ary map is even worse, because zip uses StoppingPolicy.shortest by default (which i find weird and contrary to D's safe by default stance): here's the (corrected) dotproduct: before: zip(StoppingPolicy.requireSameLength,u,v).map!a[0]*a[1].reduce!a+b; after: map!a*b(u,v).reduce!a+b; i think it's a clear improvement in terms of clarity (and again, optimizations possible). There we have it. zip + map is the body of the generic function desired. Optimise later if needed.
Re: assert() vs. enforce(), invariant() vs. ... ?
On 8/30/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: * typedef: it was so ill defined, bringing it any closer to sanity would've broken someone's code. So it had to be properly defined in the spec and implemented. Meanwhile we're fighting with the Phobos Typedef and it has way more problems right now, some of which will likely be unsolvable. Bug reports: http://d.puremagic.com/issues/show_bug.cgi?id=10872 http://d.puremagic.com/issues/show_bug.cgi?id=10871 http://d.puremagic.com/issues/show_bug.cgi?id=10778 http://d.puremagic.com/issues/show_bug.cgi?id=8618 http://d.puremagic.com/issues/show_bug.cgi?id= http://d.puremagic.com/issues/show_bug.cgi?id=7737 * scope: cute and dangerous in equal proportions - great for a movie character, terrible for language design. scoped() has its own quirks, for example: http://d.puremagic.com/issues/show_bug.cgi?id=4636 http://d.puremagic.com/issues/show_bug.cgi?id=5115 http://d.puremagic.com/issues/show_bug.cgi?id=10921 And this last bug that was filed (10921) was a bug that was known since 2010: http://d.puremagic.com/issues/show_bug.cgi?id=5115#c6 So 3 years later, and it's still an issue. I don't even see how Issue 4636 can even be fixed, there's no way for a template in another module to get private access to the class constructor. --- Anyway, we've deprecated old keywords, and introduced half-implemented library replacements. I don't see how we stand any better today than we did before.
Can not override template and nontemplate function
D can not override template and nontemplate function:
void foo(bool param)
{
if(param)
{
//do something useful
}
else
{
//do something else
}
}
void foo(bool param)()
{
static if(param)
{
//do something useful
}
else
{
//do something else
}
}
void main()
{
}
dmd output:
src/main.d(13): Error: template main.foo(bool param)() conflicts
with function main.foo at src/main.d(1)
Does exist any reason to deny this, or it's just compiler bug?
I think that compiler can always understand what I want:
//nontemplate function call
foo(true);
//template function call
foo!true();
Re: Can not override template and nontemplate function
On 8/31/13, ilya-stromberg ilya-stromberg-2...@yandex.ru wrote: D can not override template and nontemplate function. It was a long-standing bug which was fixed in git-head and will work in the 2.064 release.
Re: Linking C extern(C) on OS X: duplicate symbols not flagged
On 2013-08-30 16:10, Luís Marques l...@luismarques.eu wrote: That fails, as expected. So DMD and Clang uses different sections? Have you tried GDC or LDC? -- /Jacob Carlborg
Re: Can not override template and nontemplate function
Am 31.08.2013 12:53, schrieb Andrej Mitrovic:
On 8/31/13, ilya-stromberg ilya-stromberg-2...@yandex.ru wrote:
D can not override template and nontemplate function.
It was a long-standing bug which was fixed in git-head and will work
in the 2.064 release.
Also, for completeness, it's possible to work around it for now using a
parameter-less template:
void foo()(bool param)
{
// ...
}
void foo(bool param)()
{
// ...
}
Re: obsolete D libraries/modules
On 2013-08-30 20:19, Ramon wrote: Thanks for the information and your thoughts. I'd like to ask one more question on that, as I happened to work a little with phobos' getopt and looked at your code and happened to notice (your use of) tangos arg parsing/handling: Why do you consider tangos arg parsing being better? Could you kindly elaborate that somewhat? (Because I, possibly due to my newbness, failed to see striking advantages in tangos arg parsing when looking at Dstep). I think the Tango version is more flexible and has more features. With the Tango argument parser you can: * Restrict values * Specify the min and max number of arguments a given flag need to have * Aliases * Default value * Conflict handling The Phobos version accepts weird syntax's like: --t 4 -- /Jacob Carlborg
Re: obsolete D libraries/modules
On 2013-08-30 18:55, Artur Skawina wrote: The question was not about Tango. Oh, my bad. -- /Jacob Carlborg
Re: Front-end release.NEXT
On 2013-08-30 21:50, Walter Bright wrote: I think it's a good idea. The only further enhancement I really want to get in this release is DLL support for Linux. Do you mean loading DLL's completely at runtime, i.e. using dlopen? We have already shipped Phobos as a DLL. -- /Jacob Carlborg
Re: assert() vs. enforce(), invariant() vs. ... ?
On 2013-08-31 11:46, Andrej Mitrovic wrote: So 3 years later, and it's still an issue. I don't even see how Issue 4636 can even be fixed, there's no way for a template in another module to get private access to the class constructor. A delegate/function pointer will bypass the protection. -- /Jacob Carlborg
Re: Front-end release.NEXT
On 8/30/13, Walter Bright newshou...@digitalmars.com wrote: The only further enhancement I really want to get in this release is DLL support for Linux. And if it's (mostly) done, we should put it in the changelog, since it's a pretty big deal!
Re: assert() vs. enforce(), invariant() vs. ... ?
On 8/31/13, Jacob Carlborg d...@me.com wrote: A delegate/function pointer will bypass the protection. How will you pass a pointer to a constructor?
Re: std.serialization: pre-voting review / discussion
Jacob, what are your current plans on this (considering recent range API discussion thread)?
Re: Can not override template and nontemplate function
On Saturday, 31 August 2013 at 11:22:17 UTC, Sönke Ludwig wrote:
Also, for completeness, it's possible to work around it for now
using a parameter-less template:
void foo()(bool param)
{
// ...
}
void foo(bool param)()
{
// ...
}
While we are at it, this is also the way to force attribute
inference on a function.
Re: Can not override template and nontemplate function
On Saturday, 31 August 2013 at 12:19:17 UTC, monarch_dodra wrote: While we are at it, this is also the way to force attribute inference on a function. Can you print any code example, please?
Re: Can not override template and nontemplate function
On Saturday, 31 August 2013 at 12:53:17 UTC, ilya-stromberg wrote: On Saturday, 31 August 2013 at 12:19:17 UTC, monarch_dodra wrote: While we are at it, this is also the way to force attribute inference on a function. Can you print any code example, please? AFAIK template function attributes are always inferred. So converting normal function to parameter-less template function forces it.
Re: Front-end release.NEXT
On Saturday, 31 August 2013 at 11:24:41 UTC, Jacob Carlborg wrote: Do you mean loading DLL's completely at runtime, i.e. using dlopen? We have already shipped Phobos as a DLL. Yep, see https://github.com/D-Programming-Language/druntime/pull/593 and linked pull requests. David
Re: Replacing std.xml
On Thursday, 29 August 2013 at 07:53:46 UTC, Tobias Pankrath wrote: There is http://dsource.org/projects/xmlp, which at some point has been proposed for std.xml2. But that stalled for some time now. Also, we have Tango Xml: https://github.com/SiegeLord/Tango-D2/tree/d2port/tango/text/xml It's the fastest Xml parser in the world, so may be you can find it useful: dotnot.org/blog/archives/2008/03/10/xml-benchmarks-parsequerymutateserialize/ dotnot.org/blog/archives/2008/03/12/why-is-dtango-so-fast-at-parsing-xml/
Re: Can not override template and nontemplate function
On Saturday, 31 August 2013 at 12:53:17 UTC, ilya-stromberg wrote:
On Saturday, 31 August 2013 at 12:19:17 UTC, monarch_dodra
wrote:
While we are at it, this is also the way to force attribute
inference on a function.
Can you print any code example, please?
//This function is @system, not pure, and throws.
void foo()
{}
//This function is @safe, pure and nothrow.
void bar()()
It's a trick that is useful when doing non-template functions
inside a templated struct. EG:
struct S(T)
{
T t;
T foo()
{
return t;
}
}
Here, we don't know if foo is nothrow, as the postblit could
throw, for example. If we make it a template, then the compiler
deduces it for us.
Although arguably, since foo is already in a parameterized
context, *ideally* it should already be infered (but that is not
the case today).
Re: Can not override template and nontemplate function
On Saturday, 31 August 2013 at 16:39:22 UTC, monarch_dodra wrote:
It's a trick that is useful when doing non-template functions
inside a templated struct. EG:
struct S(T)
{
T t;
T foo()
{
return t;
}
}
Here, we don't know if foo is nothrow, as the postblit could
throw, for example. If we make it a template, then the compiler
deduces it for us.
Bad example, the correct example is one that uses voldermort
typing:
auto foo(T)()
{
struct S //S is not a template
{
void bar(){}
}
return S();
}
void main() pure nothrow @system
{
auto s = foo!int();
s.bar(); //Error here!
}
but, again, arguably, that should have just worked (tm)
Re: assert() vs. enforce(), invariant() vs. ... ?
On 8/30/13 9:55 PM, Maxim Fomin wrote: On Friday, 30 August 2013 at 21:11:32 UTC, Andrei Alexandrescu wrote: * typedef: it was so ill defined, bringing it any closer to sanity would've broken someone's code. I haven't heard about any specific troubles with typedef which are reason to depreciate the feature. The problem is nobody could agree whether typedef was a supertype or a subtype of its original type. It was just a bizarre teratoma grown by happenstance. In addition to typedef some other features are also experiencing troubles (shared, ref, properties, invariants,..) yet they are not deprecated. That's not an argument. * delete: a festering dung of unsafety straight in the middle of the language. It was useful to delete class objects at the time where programmer knew that he can delete safely to mitigate the problem of dangling references upon class finalization (by invoking dtor when objects are alive). Right now there is no way to do that. By the way, currently dmd accepts putting @safe attribute on class dtor definitions which access GC objects - this is a hole in @safety (accessing such elements is not a sufficient reason to be hole in safity, but not reseting pointers to null is). That would be a bug. If there's enough argument that the functionality of delete is actually desirable we can always add a function for that. Probably yes. * scope: cute and dangerous in equal proportions - great for a movie character, terrible for language design. Andrei I cannot remember any feature implemented in phobos that was better then built-in language construct, including scope. Hasn't C++ followed the same policy and at the end it was considered as mistake? Not sure I understand. At least D has many built-in features comparing to C++ and this is advertized as an advantage. I don't think that's how I see things. Andrei
Re: assert() vs. enforce(), invariant() vs. ... ?
On 8/31/13 2:46 AM, Andrej Mitrovic wrote: On 8/30/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: * typedef: it was so ill defined, bringing it any closer to sanity would've broken someone's code. So it had to be properly defined in the spec and implemented. Meanwhile we're fighting with the Phobos Typedef and it has way more problems right now, some of which will likely be unsolvable. Bug reports: http://d.puremagic.com/issues/show_bug.cgi?id=10872 http://d.puremagic.com/issues/show_bug.cgi?id=10871 http://d.puremagic.com/issues/show_bug.cgi?id=10778 http://d.puremagic.com/issues/show_bug.cgi?id=8618 http://d.puremagic.com/issues/show_bug.cgi?id= http://d.puremagic.com/issues/show_bug.cgi?id=7737 Most of these look approachable, and there are workarounds for the others. Granted, the UDT can't be made 100% like the old typedef (and probably that would be bad, too :o)). * scope: cute and dangerous in equal proportions - great for a movie character, terrible for language design. scoped() has its own quirks, for example: http://d.puremagic.com/issues/show_bug.cgi?id=4636 http://d.puremagic.com/issues/show_bug.cgi?id=5115 http://d.puremagic.com/issues/show_bug.cgi?id=10921 And this last bug that was filed (10921) was a bug that was known since 2010: http://d.puremagic.com/issues/show_bug.cgi?id=5115#c6 So 3 years later, and it's still an issue. I don't even see how Issue 4636 can even be fixed, there's no way for a template in another module to get private access to the class constructor. --- Anyway, we've deprecated old keywords, and introduced half-implemented library replacements. I don't see how we stand any better today than we did before. Library issues are a lot easier to deal with than core language issues. Andrei
Re: obsolete D libraries/modules
On 8/31/13 4:21 AM, Jacob Carlborg wrote: On 2013-08-30 20:19, Ramon wrote: Thanks for the information and your thoughts. I'd like to ask one more question on that, as I happened to work a little with phobos' getopt and looked at your code and happened to notice (your use of) tangos arg parsing/handling: Why do you consider tangos arg parsing being better? Could you kindly elaborate that somewhat? (Because I, possibly due to my newbness, failed to see striking advantages in tangos arg parsing when looking at Dstep). I think the Tango version is more flexible and has more features. With the Tango argument parser you can: * Restrict values * Specify the min and max number of arguments a given flag need to have * Aliases * Default value * Conflict handling Haven't seen Tango's arguments parser, but it's a given getopt can be improved in any number of ways. Yet the way I see it, with command line parsing, the margin between a good enough argument parser and a terrific one is razor thin. One parses arguments by definition once in every program, and things like checking against limits and constraints across multiple arguments can be easily done after basic parsing. The Phobos version accepts weird syntax's like: --t 4 Only if you tell it to! Andrei
DMD 2.064 alpha windows build
Hi, guys! I've made DMD build using MSVC(ICC has some performance troubles) and tcmalloc, so it can compile more than 2x faster. http://acomirei.ru/u/dmd.7z It uses lastest DMD, druntime and Phobos.
Re: std.serialization: pre-voting review / discussion
On 2013-08-31 14:11, Dicebot wrote: Jacob, what are your current plans on this (considering recent range API discussion thread)? My todo list looks like this: - write an overview documentation - improve the documentation for std.serialization.serializable to indicate it's not required - implement a convenience function for serializing - implement a convenience function for serializing to a file - remove Serializeable - check only for toData when serializing - check only for fromData when deserializing - split Serializer in to two parts - make the parts structs - possibly provide class wrappers - split Archive in two parts - add range interface to Serializer and Archive - rename all archives to archivers - replace ddoc comments with regular comments for all package protected symbols Although I'm guessing I won't be able to finish it in time for voting. How much time is it left anyway? -- /Jacob Carlborg
Re: Replacing std.xml
On 2013-08-31 17:43, ilya-stromberg wrote: Also, we have Tango Xml: https://github.com/SiegeLord/Tango-D2/tree/d2port/tango/text/xml It's the fastest Xml parser in the world, so may be you can find it useful: dotnot.org/blog/archives/2008/03/10/xml-benchmarks-parsequerymutateserialize/ dotnot.org/blog/archives/2008/03/12/why-is-dtango-so-fast-at-parsing-xml/ Unfortunately the Tango XML package will never end up in Phobos due to licensing issues. -- /Jacob Carlborg
Re: assert() vs. enforce(), invariant() vs. ... ?
On 2013-08-31 14:03, Andrej Mitrovic wrote: How will you pass a pointer to a constructor? No, you invoke the constructor via a pointer. https://github.com/D-Programming-Language/phobos/blob/master/std/conv.d#L4391 Replace that line with: auto dg = result.__ctor; dg(args); The static-if needs to be adjusted as well. -- /Jacob Carlborg
Re: Can not override template and nontemplate function
On 2013-08-31 14:19, monarch_dodra wrote: While we are at it, this is also the way to force attribute inference on a function. And force a function to appear with its implementation in interface files. Useful for CTFE. -- /Jacob Carlborg
Re: Front-end release.NEXT
On 8/31/2013 4:24 AM, Jacob Carlborg wrote: On 2013-08-30 21:50, Walter Bright wrote: I think it's a good idea. The only further enhancement I really want to get in this release is DLL support for Linux. Do you mean loading DLL's completely at runtime, i.e. using dlopen? We have already shipped Phobos as a DLL. I mean that from a C or D program, being able to dynamically load and unload DLLs at runtime.
Re: obsolete D libraries/modules
On 2013-08-31 19:11, Andrei Alexandrescu wrote: Haven't seen Tango's arguments parser, but it's a given getopt can be improved in any number of ways. Yet the way I see it, with command line parsing, the margin between a good enough argument parser and a terrific one is razor thin. One parses arguments by definition once in every program, and things like checking against limits and constraints across multiple arguments can be easily done after basic parsing. I don't want this to start a huge argument about Tango versus Phobos. But Tango supports this _now_, out of the box, Phobos doesn't. No need to do any post processing. It's that simple. Again I don't understand why some people having so much trouble that some developers here are using Tango. -- /Jacob Carlborg
Re: DMD 2.064 alpha windows build
Do you have a source for this? I don't trust random binaries, especially ones that are hosted on an .ru site.. On 8/31/13, Temtaime temta...@gmail.com wrote: Hi, guys! I've made DMD build using MSVC(ICC has some performance troubles) and tcmalloc, so it can compile more than 2x faster. http://acomirei.ru/u/dmd.7z It uses lastest DMD, druntime and Phobos.
Re: assert() vs. enforce(), invariant() vs. ... ?
On 8/31/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Library issues are a lot easier to deal with than core language issues. Not when you have Kenji around!
Re: assert() vs. enforce(), invariant() vs. ... ?
On 8/31/13, Jacob Carlborg d...@me.com wrote: Replace that line with: auto dg = result.__ctor; dg(args); Hmm... I hope this can actually work when there are multiple ctors, how would the compiler know which of the ctors dg should be assigned to?
Re: obsolete D libraries/modules
On 8/31/13 11:12 AM, Jacob Carlborg wrote: On 2013-08-31 19:11, Andrei Alexandrescu wrote: Haven't seen Tango's arguments parser, but it's a given getopt can be improved in any number of ways. Yet the way I see it, with command line parsing, the margin between a good enough argument parser and a terrific one is razor thin. One parses arguments by definition once in every program, and things like checking against limits and constraints across multiple arguments can be easily done after basic parsing. I don't want this to start a huge argument about Tango versus Phobos. But Tango supports this _now_, out of the box, Phobos doesn't. No need to do any post processing. It's that simple. I agree with the sentiment, but not with the example. It's just petty. There's no out-of-the-box vs it-could-be-built, it's just a difference without a distinction. We're talking about a few lines per application. Again I don't understand why some people having so much trouble that some developers here are using Tango. In this case you're seeing things where they aren't. Speaking only for myself I think Tango is a fine library and I'm glad it's keeping traction in D. Andrei
Re: obsolete D libraries/modules
On Friday, 30 August 2013 at 12:28:42 UTC, Wyatt wrote: On Thursday, 29 August 2013 at 19:18:48 UTC, H. S. Teoh wrote: Right now, having no way to actually update that site to add a notice to this effect On this point, when's the last time someone tried pinging him via email? Is the whois for the domain not current? -Wyatt His email is supposedly brad at dsource.org. I know people have had difficulty contacting him in the past but I've never tried myself. And just to clarify, I'm not the same Brad Anderson that runs DSource (which has caused some confusion in the past). I'm pretty sure neither of us talk in the third person.
Re: Can not override template and nontemplate function
On 08/31/2013 06:39 PM, monarch_dodra wrote: Although arguably, since foo is already in a parameterized context, *ideally* it should already be infered (but that is not the case today). http://d.puremagic.com/issues/show_bug.cgi?id=7511
Re: Replacing std.xml
On 2013-08-31 15:43:00 +, ilya-stromberg ilya-stromberg-2...@yandex.ru said: On Thursday, 29 August 2013 at 07:53:46 UTC, Tobias Pankrath wrote: There is http://dsource.org/projects/xmlp, which at some point has been proposed for std.xml2. But that stalled for some time now. Also, we have Tango Xml: https://github.com/SiegeLord/Tango-D2/tree/d2port/tango/text/xml It's the fastest Xml parser in the world, so may be you can find it useful: dotnot.org/blog/archives/2008/03/10/xml-benchmarks-parsequerymutateserialize/ dotnot.org/blog/archives/2008/03/12/why-is-dtango-so-fast-at-parsing-xml/ Someone should benchmark it against the XML implementation I made. It has many of the same characteristics. For instance, Tango's SaxParser is based on its PullParser. This design requires the use a dynamic array to maintain a stack of opened elements. While not a huge performance hit, you don't need that if you use recursion, which you can do with my implementation. You can do that even though you can also use it as a pull tokenizer[^1] when needed (recursion is optional on a token-by-token basis). [^1]: IMHO, PullParser isn't a really good term for something that does not conform to the requirements of a parser in the XML spec. Tokenizer is a better term. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: std.serialization: pre-voting review / discussion
On Saturday, 31 August 2013 at 17:58:57 UTC, Jacob Carlborg wrote: My todo list looks like this: - write an overview documentation - improve the documentation for std.serialization.serializable to indicate it's not required - implement a convenience function for serializing - implement a convenience function for serializing to a file - remove Serializeable - check only for toData when serializing - check only for fromData when deserializing - split Serializer in to two parts - make the parts structs - possibly provide class wrappers - split Archive in two parts - add range interface to Serializer and Archive - rename all archives to archivers - replace ddoc comments with regular comments for all package protected symbols Although I'm guessing I won't be able to finish it in time for voting. How much time is it left anyway? Great. No hurry here, there is no hard deadline for voting - I'll put it on pause until you are ready. Just doing some personal bookkeeping. No pressure, just write me an e-mail when ready for next stage.
Re: DMD 2.064 alpha windows build
You can get DMD source on DMD's github. I've read DMD backend license, so it forbids to distribute DMD itself. I've removed the archive. I'll investigate in LDC.
Re: DMD 2.064 alpha windows build
On 8/31/13, Temtaime temta...@gmail.com wrote: You can get DMD source on DMD's github. I'm asking about the modified version which uses tcmalloc. You've said it compiles 2x faster, but faster to what? The regular MSVC build is already known to be 2x faster than the one built with DMC.
Re: obsolete D libraries/modules
On Saturday, 31 August 2013 at 18:44:52 UTC, Brad Anderson wrote: On Friday, 30 August 2013 at 12:28:42 UTC, Wyatt wrote: On Thursday, 29 August 2013 at 19:18:48 UTC, H. S. Teoh wrote: Right now, having no way to actually update that site to add a notice to this effect On this point, when's the last time someone tried pinging him via email? Is the whois for the domain not current? -Wyatt His email is supposedly brad at dsource.org. I know people have had difficulty contacting him in the past but I've never tried myself. And just to clarify, I'm not the same Brad Anderson that runs DSource (which has caused some confusion in the past). I'm pretty sure neither of us talk in the third person. He, the dsource guy, is Brad AndersEn from Atlanta, GA, according to what little info is available. His whois email is at some company that seems to have gone away or changed name or ... dsource seems to be on a VPS at slicehost and, so it seems, just one in some more sites on that virtual host. It seems we shouldn't hold our breath to hear from Mr. Andersen, unless someone here knows him personally and is in contact with him. But then, most people looking for D arrive here at dlang anyway. I think, we should simply put some kind of marker here concering dsource being comatose. A+ -R
Re: std.serialization: pre-voting review / discussion
On 2013-08-31 20:51, Dicebot wrote: Great. No hurry here, there is no hard deadline for voting - I'll put it on pause until you are ready. Just doing some personal bookkeeping. No pressure, just write me an e-mail when ready for next stage. What I mean is that we usual have a couple of weeks for reviewing and then about one week for voting. I don't want to put the whole review queue on hold. -- /Jacob Carlborg
Re: Front-end release.NEXT
On 2013-08-31 20:10, Walter Bright wrote: I mean that from a C or D program, being able to dynamically load and unload DLLs at runtime. I see. -- /Jacob Carlborg
Re: assert() vs. enforce(), invariant() vs. ... ?
On 2013-08-31 20:28, Andrej Mitrovic wrote: Hmm... I hope this can actually work when there are multiple ctors, how would the compiler know which of the ctors dg should be assigned to? Apparently you cannot use auto when having an overloaded symbol, so just use an explicit type: T delegate (Args) dg = result.__ctor; dg(args); -- /Jacob Carlborg
Re: Replacing std.xml
On 2013-08-31 20:53, Michel Fortin wrote: [^1]: IMHO, PullParser isn't a really good term for something that does not conform to the requirements of a parser in the XML spec. Tokenizer is a better term. I guess Pull is the key here. That it is the client's responsibility to fetch the next token, not the other way around. -- /Jacob Carlborg
Re: assert() vs. enforce(), invariant() vs. ... ?
On 8/31/13, Jacob Carlborg d...@me.com wrote: T delegate (Args) dg = result.__ctor; dg(args); Ah, pretty cool workaround.
Re: Front-end release.NEXT
On Sat, Aug 31, 2013 at 11:10:54AM -0700, Walter Bright wrote: On 8/31/2013 4:24 AM, Jacob Carlborg wrote: On 2013-08-30 21:50, Walter Bright wrote: I think it's a good idea. The only further enhancement I really want to get in this release is DLL support for Linux. Do you mean loading DLL's completely at runtime, i.e. using dlopen? We have already shipped Phobos as a DLL. I mean that from a C or D program, being able to dynamically load and unload DLLs at runtime. Oh, you mean the D equivalent of dlopen/dlsym/dlclose? That would be *very* nice, if it can be made to work. T -- Many open minds should be closed for repairs. -- K5 user
Re: std.serialization: pre-voting review / discussion
On Saturday, 31 August 2013 at 19:37:34 UTC, Jacob Carlborg wrote: On 2013-08-31 20:51, Dicebot wrote: Great. No hurry here, there is no hard deadline for voting - I'll put it on pause until you are ready. Just doing some personal bookkeeping. No pressure, just write me an e-mail when ready for next stage. What I mean is that we usual have a couple of weeks for reviewing and then about one week for voting. I don't want to put the whole review queue on hold. You won't. Reviewing is not a blocking operation, if anyone wants to acts as a review manager for some other contribution, nothing prevents from doing it right now. I have simply marked `std.serialization` as Incorporating review comments in wiki and given no new comments this round of review can be considered finished.
Re: assert() vs. enforce(), invariant() vs. ... ?
On 31.08.2013 21:52, Andrej Mitrovic wrote: On 8/31/13, Jacob Carlborg d...@me.com wrote: T delegate (Args) dg = result.__ctor; dg(args); Ah, pretty cool workaround. Then, why not close that old bug?
Re: Replacing std.xml
On 8/29/2013 12:25 AM, w0rp wrote: Hello everybody. I've been wondering, what are the current plans to replace std.xml? I'd like to help with the effort to get a final XML library in phobos. So, I have a few questions. First, and most importantly, what do we except out of a D XML library? I'd really like to have a discussion of the form, Here is exactly the interface the structs/classes need to implement, go forth and implement. The general idea in my mind is something SAX-like, with something a little DOM-like. I'm aware that std.xml has some issues support different encodings, so obvious that's included. Second, is there an existing library that has gotten close to meeting whatever we need for the first point? If so, how far away is it from being able to meet all of the requirements and become the standard library version? The Tango implementation of XML has been very well received. I haven't looked at it, but it was designed to do no memory allocation - it just did slices over the input. I don't believe it should make any attempt at decoding. Decoding entails both performance loss and memory consumption. If the user wants to do decoding, they can layer it on the output. And lastly, it should of course sport a range interface.
Re: Front-end release.NEXT
On 8/31/2013 1:00 PM, H. S. Teoh wrote: Oh, you mean the D equivalent of dlopen/dlsym/dlclose? That would be *very* nice, if it can be made to work. It certainly can be made to work. Martin Nowak is close to getting it done.
Re: assert() vs. enforce(), invariant() vs. ... ?
On 8/31/13, Piotr Szturmaj bncr...@jadamspam.pl wrote: On 31.08.2013 21:52, Andrej Mitrovic wrote: On 8/31/13, Jacob Carlborg d...@me.com wrote: T delegate (Args) dg = result.__ctor; dg(args); Ah, pretty cool workaround. Then, why not close that old bug? It needs to be fixed first.
Re: assert() vs. enforce(), invariant() vs. ... ?
On Friday, 30 August 2013 at 21:11:32 UTC, Andrei Alexandrescu
wrote:
* scope: cute and dangerous in equal proportions - great for a
movie character, terrible for language design.
I'll argue for it and others can then destroy.
IME, a lot of the value of functional programming (by which I
mean, programming with higher order functions) can be had with
downward funargs, as found in Pascal (and more recently, Ada),
which don't require garbage collection.
The D language expresses closures and higher order functions as
delegates, and uses the heap to manage these. I had assumed that
we could use 'scope' on the delegate being passed to prevent it's
heap allocation, as discussed here:
http://stackoverflow.com/questions/4711309/meaning-of-scope-in-d-for-a-parameter
I wrote a small test case to try this out, in which I construct a
2-D integration function from a 1-D one, and I use Adam Ruppe's
nogc code to seg fault when the GC is hit. Without using a
'scope' on a local variable, I'm forced to pile up the anonymous
function calls to get the behavior I want.
import std.stdio, std.math;
// int delegate(int) adder(int a) { return (int b) { return a +
b;}; }
float integrate(scope float delegate(float x) f, float lo, float
hi, size_t n) {
float result = 0.0;
float dx = (hi - lo) / n;
for (size_t i = 0; i n; i++) {
result += f(lo + i * dx) * dx;
}
return result;
}
float integrate(scope float delegate(float, float) f,
float x0, float x1,
float y0, float y1,
size_t nX, size_t nY) {
scope auto f_y = delegate float(float y) =
integrate(delegate(float x) = f(x,y), x0, x1, nX);
return integrate(f_y, y0, y1, nY);
// I'll have to write it like this to avoid heap allocation
without
// local variable scope
// return integrate((y) = integrate((x) =f(x,y), x0, x1, nX),
y0, y1, nY);
}
The code to test demonstrates the issue better, as I'm forced to
use inline anonymous functions everywhere to avoid the GC calls
(unitCircle and unitSphere omitted for brevity)
void main() {
scope auto funcX_1 = delegate float(float x) = unitCircle(x);
float result1 = integrate(funcX_1 /* (x) = unitCircle(x) */,
-1.0, 1.0, 500);
writefln(integrate(func1, -1.0, 1.0, 500) = %g, result1);
scope auto funcXY_1 = delegate float(float x, float y) =
unitSphere(x,y);
result1 = integrate(funcXY_1 /* (x,y) = unitSphere(x,y) */,
-1.0, 1.0, -1.0, 1.0, 100, 100);
writefln(integrate(funcXY_1, -1.0, 1.0, -1.0, 1.0, 100, 100)
= %g, result1);
}
Yes, it's a toy example, but I do program with higher order
functions a lot in OCaml and I'd probably use them quite a bit in
D, especially if I could avoid impacting the GC.
If scope on local variables is going away, it would be nice if
the compiler could figure out when I'm using delegate args in a
'downward, non escaping' way and not heap allocate. My tests with
DMD indicate that without those 'scope' on the local variable the
GC does in fact get hit, and with them it does not.
-- Brian
PS: I don't really use classes much, so I have little to say
about scope on objects
PPS: If my missive made little sense,
https://en.wikipedia.org/wiki/Funarg_problem
http://stackoverflow.com/questions/581182/what-are-downward-funargs
Re: assert() vs. enforce(), invariant() vs. ... ?
On 8/31/13 1:34 PM, Brian Rogoff wrote: On Friday, 30 August 2013 at 21:11:32 UTC, Andrei Alexandrescu wrote: * scope: cute and dangerous in equal proportions - great for a movie character, terrible for language design. I'll argue for it and others can then destroy. IME, a lot of the value of functional programming (by which I mean, programming with higher order functions) can be had with downward funargs, as found in Pascal (and more recently, Ada), which don't require garbage collection. The D language expresses closures and higher order functions as delegates, and uses the heap to manage these. I had assumed that we could use 'scope' on the delegate being passed to prevent it's heap allocation, as discussed here: http://stackoverflow.com/questions/4711309/meaning-of-scope-in-d-for-a-parameter That use will stay and is useful and uncontested. Andrei
Re: Front-end release.NEXT
On Sat, Aug 31, 2013 at 01:27:09PM -0700, Walter Bright wrote: On 8/31/2013 1:00 PM, H. S. Teoh wrote: Oh, you mean the D equivalent of dlopen/dlsym/dlclose? That would be *very* nice, if it can be made to work. It certainly can be made to work. Martin Nowak is close to getting it done. Excellent! I presume it will be type-safe and support all the usual D idioms? (I.e., none of that ugly mess with dlsym and C++, where casting void* returned by dlsym() to a func ptr is undefined behaviour according to the C++ spec). T -- The two rules of success: 1. Don't tell everything you know. -- YHL
Re: assert() vs. enforce(), invariant() vs. ... ?
On Saturday, 31 August 2013 at 21:30:40 UTC, Andrei Alexandrescu
wrote:
http://stackoverflow.com/questions/4711309/meaning-of-scope-in-d-for-a-parameter
That use will stay and is useful and uncontested.
Andrei
Sure, but my complaint is that that useful style is cramped by
the inability to have scope on *local variables*. I understand
that scope on function parameters will stay. If you're saying
that scope on local variables for delegates will stay, then
disregard all I've written here, I'm happy! :-).
If you look at the code I posted, try removing scope from the 2-D
integrate and from the local variable declarations in the main()
function, and the program hits the GC, with the scopes, they
don't. The problem occurs when I create the local variables to
name an anonymous function. I tested this with Adam Ruppe's code
which halts when the GC is called.
As I said, I'm not arguing for scope on objects, but for
contrivances which allow me to program easily with downward
funargs and not hit the GC. D goes further than most languages in
this and it would be a shame if this capability is removed with
no substitute.
For those who want to test on their systems, here are the trivial
unitCircle and unitSphere I omitted.
float unitCircle(float x) {
float x2 = x * x;
if (x2 1.0) {
return sqrt(1.0 - x2);
} else {
return 0.0;
}
}
float unitSphere(float x, float y) {
float sum = x*x + y*y;
if (sum = 1.0) {
return sqrt(1.0 - sum);
} else {
return 0.0;
}
}
-- Brian
Re: obsolete D libraries/modules
On Saturday, 31 August 2013 at 19:11:25 UTC, Ramon wrote: On Saturday, 31 August 2013 at 18:44:52 UTC, Brad Anderson wrote: On Friday, 30 August 2013 at 12:28:42 UTC, Wyatt wrote: On Thursday, 29 August 2013 at 19:18:48 UTC, H. S. Teoh wrote: Right now, having no way to actually update that site to add a notice to this effect On this point, when's the last time someone tried pinging him via email? Is the whois for the domain not current? -Wyatt His email is supposedly brad at dsource.org. I know people have had difficulty contacting him in the past but I've never tried myself. And just to clarify, I'm not the same Brad Anderson that runs DSource (which has caused some confusion in the past). I'm pretty sure neither of us talk in the third person. He, the dsource guy, is Brad AndersEn from Atlanta, GA, according to what little info is available. His whois email is at some company that seems to have gone away or changed name or ... dsource seems to be on a VPS at slicehost and, so it seems, just one in some more sites on that virtual host. It seems we shouldn't hold our breath to hear from Mr. Andersen, unless someone here knows him personally and is in contact with him. But then, most people looking for D arrive here at dlang anyway. I think, we should simply put some kind of marker here concering dsource being comatose. A+ -R By reading this thread I just learn that dsource.org is dead. And by going deeper in the wiki I found a page that replace dsource.org as an entry point to D related projects : http://wiki.dlang.org/Libraries_and_Frameworks I think this page should be more visible on dlang to show how much the community is large to the newcomers. Maybe a Dquick will have a little place near others GUI Libraries when it will be more than a protytpe. I can see that all multi-platforms ones are wrappers and others only support Windows. I am a Windows user, but I don't understand why others platforms are forgotten.
Re: obsolete D libraries/modules
On 9/1/13, Flamaros flamaros.xav...@gmail.com wrote: I am a Windows user, but I don't understand why others platforms are forgotten. I think it's because win32 is the easiest to create a native library for, since the standard API functions for creating windows and widgets has been the same for many years. On OSX you probably have to interact with Objective-C code, which IIRC is hard to do from D without some extra language support (there's some pull request for it). And on Posix you basically don't have a standard API, so front-end libraries typically use GTK or Qt as the backend.
Re: assert() vs. enforce(), invariant() vs. ... ?
On 8/31/13 2:57 PM, Brian Rogoff wrote: On Saturday, 31 August 2013 at 21:30:40 UTC, Andrei Alexandrescu wrote: http://stackoverflow.com/questions/4711309/meaning-of-scope-in-d-for-a-parameter That use will stay and is useful and uncontested. Andrei Sure, but my complaint is that that useful style is cramped by the inability to have scope on *local variables*. Oh I see. Yes, if we do find a way to define scope to provide guarantees, that would be awesome. Andrei
Re: obsolete D libraries/modules
On Saturday, 31 August 2013 at 23:03:48 UTC, Andrej Mitrovic wrote: On 9/1/13, Flamaros flamaros.xav...@gmail.com wrote: I am a Windows user, but I don't understand why others platforms are forgotten. I think it's because win32 is the easiest to create a native library for, since the standard API functions for creating windows and widgets has been the same for many years. On OSX you probably have to interact with Objective-C code, which IIRC is hard to do from D without some extra language support (there's some pull request for it). And on Posix you basically don't have a standard API, so front-end libraries typically use GTK or Qt as the backend. Yep, I know that for linux it's hard to use X11 or XCB direcly. Today linux window manager (unity, KDE) seems want migrate form gtk to QML that can interact efficiently with modern window compositors (wayland, Mir). Old GUI systems are to different on platforms that why we made the choice of doing something like QML which is based on a 3D renderer. If I am not wrong that so much hard to wrap native GUI systems in a portable way than QtWidgets is manually written to mimic native GUI.
Re: Help?
On 31 August 2013 04:59, Johannes Pfau nos...@example.com wrote:
Am Sat, 31 Aug 2013 04:09:10 +1000
schrieb Manu turkey...@gmail.com:
So should I extern(C) the forward declaration?
Sometimes
---
struct MyStruct {}
---
is used as a workaround, but that may have other issues.
Yeah, that's no good. That certainly opens up more problems.
The point is that it is an undefined struct, and it can only be used to
type a pointer. It's pretty much impossible to extern to a lot of C code if
this doesn't work properly.
Re: obsolete D libraries/modules
On 01/09/13 03:11, Andrei Alexandrescu wrote: Haven't seen Tango's arguments parser, but it's a given getopt can be improved in any number of ways. Yet the way I see it, with command line parsing, the margin between a good enough argument parser and a terrific one is razor thin. One parses arguments by definition once in every program, and things like checking against limits and constraints across multiple arguments can be easily done after basic parsing. The Python Standard Library's argparse module http://docs.python.org/2/library/argparse.html would be a good model to base an improved option parsing module on. I've used it a lot in Python and it's very useful. Peter
Had another 48hr game jam this weekend...
We have to get the user experience and first impressions under control... I'd really love to to see a general roadmap and list of priorities. Even if goals are high-level, they might help direct focus? So I had another game-jam this weekend with a bunch of friends who are all industry professionals. The point of a 48 hour game jam is to prioritise productivity and creativity. Choosing a language like D here makes sense from a productivity point of view... that is, if it 'JUST WORKS'™. There were 7 programmers, they were all using D for the first time (except me). Most running windows, one on OSX, one on Linux. We ran into the same problems old that have been giving me the shits as long as I've been using D. Configuring compilers: Naturally, this is primarily a problem with the windows experience, but it's so frustrating that it is STILL a problem... how many years later? People don't want to 'do work' to install a piece of software. Rather, they expect it to 'just work'. We lost about 6 hours trying to get everyone's machines working properly. In the context of a 48 hour game jam, that's a terrible sign! I just kept promising people that it would save time overall... which I wish were true. The only compiler you can realistically use productively in windows is DMD-Win64, and that doesn't work out of the box. We needed to mess with sc.ini for quite some time to get the stars aligned such that it would actually compile and find the linker+libs. Walter: DMD needs to internally detect installations of various versions of VisualStudio, and either 'just work', or amend sc.ini on its own. Or the installer needs to amend sc.ini. Either way, leaving it to a user to fiddle with an ini file just isn't acceptable. We had to google solutions to this problem, and even then, we had trouble with the paths we added to sc.ini; are spaces acceptable? Do they have quites around them?... I might also suggest that Microsoft supplied (ie, 'standard'), libraries should be automatically detected and path entries added in there too: C:\Program Files (x86)\Microsoft SDKs\... C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\... These are on basically every windows developers machine, and each of us had to configure them ourselves. Getting a workable environment: Unsurprisingly, the Linux user was the only person happy work with a makefile. Everybody else wanted a comfortable IDE solution (and the linux user would prefer it too). ! This has to be given first-class attention! I am completely and utterly sick of this problem. Don made a massive point of it in his DConf talk, and I want to re-re-re-re-re-re-re-stress how absolutely important this is. ! I have come to the conclusion that treating IDE integration as ancillary projects maintained by usually just one single member of the community has absolutely failed. I suggest: * These should be made central D community projects. * I think they should be hosted in the same github organisation as DMD. *** As many contributors as possible should be encouraged to work with them every day. - Deprecate DMD makefiles. Seriously! Insist that contributors use the IDE bindings to work on DMD. - The fact that you all laughed at the prior point suggests clearly why it needs to be done. It will cease to be a problem when all the druntime/phobos contributors are suffering the end-user experience. * They should receive bugs in the main github bug-tracker, so EVERY D contributor can see them, and how many there are. IDE integration absolutely needs to be considered a first class feature of D. I also suggest that the IDE integration downloads should be hosted on the dlang download page so they are obvious and available to everyone without having to go looking, and also as a statement that they are actually endorsed by the dlanguage authorities. As an end-user, you're not left guessing which ones are good/bad/out of date/actually work/etc. Obviously, we settled on Visual-D (Windows) and Mono-D (OSX/Linux); the only realistic choices available. The OSX user would have preferred an XCode integration. Overwhelmingly, the biggest complaint was a lack of symbolic information to assist with auto-completion. Visual-D tries valiantly, but it falls quite short of the mark. This goes back to the threads where the IDE guys are writing their own parsers, when really, DMD should be able to be built as a lib, with an API designed for using DMD as a lib/plugin. I think continuous code compilation for auto-completion and syntax highlighting purposes should be a service offered and maintained by DMD. That way it will evolve with the language, and anyone can use it without reinventing the wheel. Debugging: Poor debugging experience wastes your time every 5 minutes. I can only speak for the Windows experience (since we failed to get OSX working); there are lots of problems with the debugging experience under visual studio... I haven't logged bugs yet, but I intend
Re: obsolete D libraries/modules
On 8/31/13 4:37 PM, Peter Williams wrote: On 01/09/13 03:11, Andrei Alexandrescu wrote: Haven't seen Tango's arguments parser, but it's a given getopt can be improved in any number of ways. Yet the way I see it, with command line parsing, the margin between a good enough argument parser and a terrific one is razor thin. One parses arguments by definition once in every program, and things like checking against limits and constraints across multiple arguments can be easily done after basic parsing. The Python Standard Library's argparse module http://docs.python.org/2/library/argparse.html would be a good model to base an improved option parsing module on. I've used it a lot in Python and it's very useful. Peter I remember sitting next to Kirk McDonald at the D conference in 2007 as he was showing me Python's argparse. I personally found pretty much any example we could think of more verbose and uglier than std.getopt. Andrei
Re: obsolete D libraries/modules
On Saturday, August 31, 2013 19:18:11 Andrei Alexandrescu wrote: I remember sitting next to Kirk McDonald at the D conference in 2007 as he was showing me Python's argparse. I personally found pretty much any example we could think of more verbose and uglier than std.getopt. std.getopt is definitely lacking some nice-to-have features (like automatically generating --help from the options), but for the most part, I don't think that it can be improved much without seriously complicating it. I think that it's about at the limit of what can be done and still have it be simple, and it works really well for the most part, so if we haven't hit the sweet spot, we're at least close. I've toyed with trying to figure out how to improve it, but I think that doing so cleanly would be very hard. The main thing that I'd really like to see changed is the exception types that it throws, because I'd very much like to be able to have code which can give specific information about how the flags were incorrectly used and whatnot, and ConvException (which is usually what you get) doesn't cut it for that. You'd need getopt-specific exceptions for that. But we can fix that without changing the API. It's just that doing so would likely break code which was catching ConvException explicitly, so if we do that, we might be forced to introduce getOpt to replace getopt or something like that. But even if we did that, the basic design wouldn't change, just what it's throwing on failure. - Jonathan M Davis
Re: Had another 48hr game jam this weekend...
On 9/1/13, Manu turkey...@gmail.com wrote:
The only compiler you can realistically use productively in windows is
DMD-Win64
Why? Win32 works fine for me and many others. If you run into
Optlink-related bugs it's usually the compiler's fault. It might
generate a bad object file and cause Optlink to crash (Unilink is
better for diagnosing what went wrong).
I'd imagine in a game-jam you won't be making a huge codebase, so you
might as well stick with 32bit?
We needed to mess with sc.ini for quite some time to get the stars aligned
such that it would actually compile and find the linker+libs.
Walter: DMD needs to internally detect installations of various versions of
VisualStudio, and either 'just work', or amend sc.ini on its own.
I provided a setup script once to retrieve the VC paths, which could
then be invoked by some other process (perhaps even DMD itself when it
reads sc.ini), but nothing seems to have come out of it yet:
http://forum.dlang.org/thread/50dad8ba.8030...@digitalmars.com?page=2#post-CAJ85NXCKNnKMjVKpk9wSWOrGdAhJFCWa_n:2BkjCZpjJOBC5u-bQ:40mail.gmail.com
Recently Nick has been working on making release scripts which will
package dmd.zip automatically, I hope we can work on better VC
integration after that work is done.
I suggest:
* These should be made central D community projects.
Most of us are happy enough with syntax-highlighted text editors, so
we likely wouldn't touch any IDE code. I'm not sure what the above
political move would do. There was a period when DWT was elected as
the official D GUI, but nothing came out of it. So these political
moves don't really mean a thing.
- Deprecate DMD makefiles. Seriously! Insist that contributors use the
IDE bindings to work on DMD.
Not gonna happen.
- The fact that you all laughed at the prior point suggests clearly why
it needs to be done. It will cease to be a problem when all the
druntime/phobos contributors are suffering the end-user experience.
Slowing us down won't help anyone.
* They should receive bugs in the main github bug-tracker, so EVERY D
contributor can see them, and how many there are.
Bugzilla is better than whatever github has to offer. It's fast and
its very searchable. Github just seems to introduce more and more
useless features every other day (but I can't even search the damn
pull request section, even though there's a global search..).
This goes back to the threads where the IDE guys are writing their own
parsers, when really, DMD should be able to be built as a lib, with an API
designed for using DMD as a lib/plugin.
I think continuous code compilation for auto-completion and syntax
highlighting purposes should be a service offered and maintained by DMD.
That way it will evolve with the language, and anyone can use it without
reinventing the wheel.
This has been said a million times, but it's a very slow evolution
turning an application into a library, especially one like DMD. The
C++ = D migration process of DMD could maybe help us move into this
direction.
There were many instances of people wasting their time chasing bugs in
random places when it was simply a case of the debugger lying about the
value of variables to them, and many more cases where the debugger simply
refused to produce values for some variables at all.
That sucks.
Documentation:
Okay for the most part, but some windows dev's want a CHM that looks like
the typical Microsoft doc's people are used to.
It's in the windows/bin folder. It's a poor place to put it, it should
better be put in a 'doc' folder or something, and it should be noted
somewhere on the website.
This code:
foreach(i, item; array)
if(item == itemToRemove)
array = array[0..i] ~ array[i+1..$];
Got a rather 'negative' reaction from the audience to put it lightly...
That will allocate a new array. It could have been:
foreach(i, item; array)
if (item == itemToRemove)
array = array.remove(i);
or even:
auto idx = array.countUntil(item);
if (idx != -1)
array = array.remove(idx);
Although it's still not very pretty. I'm surprised you're using
allocation like that for game development! :)
It is how quickly classes became disorganised and difficult to navigate
(like Java and C#).
We all wanted to ability to define class member functions outside the class
definition:
class MyClass
{
void method();
}
void MyClass.method()
{
//...
}
It definitely cost us time simply trying to understand the class layout
visually (ie, when IDE support is barely available).
You don't need to see the function bodies in the class definition, you want
to quickly see what a class has and does.
I think Andrei mentioned once that this might be a good idea, but it
needs a DIP and formal reviewing, not to mention a solid
implementation. Only this time, no more back-channel introduction of
features like UDAs, please. We ended up having a deprecation for
syntax that never formally existed.
Re: Had another 48hr game jam this weekend...
On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote: We have to get the user experience and first impressions under control... I'd really love to to see a general roadmap and list of priorities. Even if goals are high-level, they might help direct focus? So I had another game-jam this weekend with a bunch of friends who are all industry professionals. The point of a 48 hour game jam is to prioritise productivity and creativity. Choosing a language like D here makes sense from a productivity point of view... that is, if it 'JUST WORKS'™. There were 7 programmers, they were all using D for the first time (except me). Most running windows, one on OSX, one on Linux. We ran into the same problems old that have been giving me the shits as long as I've been using D. Configuring compilers: Naturally, this is primarily a problem with the windows experience, but it's so frustrating that it is STILL a problem... how many years later? People don't want to 'do work' to install a piece of software. Rather, they expect it to 'just work'. We lost about 6 hours trying to get everyone's machines working properly. In the context of a 48 hour game jam, that's a terrible sign! I just kept promising people that it would save time overall... which I wish were true. The only compiler you can realistically use productively in windows is DMD-Win64, and that doesn't work out of the box. We needed to mess with sc.ini for quite some time to get the stars aligned such that it would actually compile and find the linker+libs. Walter: DMD needs to internally detect installations of various versions of VisualStudio, and either 'just work', or amend sc.ini on its own. Or the installer needs to amend sc.ini. Either way, leaving it to a user to fiddle with an ini file just isn't acceptable. We had to google solutions to this problem, and even then, we had trouble with the paths we added to sc.ini; are spaces acceptable? Do they have quites around them?... I might also suggest that Microsoft supplied (ie, 'standard'), libraries should be automatically detected and path entries added in there too: C:\Program Files (x86)\Microsoft SDKs\... C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\... These are on basically every windows developers machine, and each of us had to configure them ourselves. Getting a workable environment: Unsurprisingly, the Linux user was the only person happy work with a makefile. Everybody else wanted a comfortable IDE solution (and the linux user would prefer it too). ! This has to be given first-class attention! I am completely and utterly sick of this problem. Don made a massive point of it in his DConf talk, and I want to re-re-re-re-re-re-re-stress how absolutely important this is. ! I have come to the conclusion that treating IDE integration as ancillary projects maintained by usually just one single member of the community has absolutely failed. I suggest: * These should be made central D community projects. * I think they should be hosted in the same github organisation as DMD. *** As many contributors as possible should be encouraged to work with them every day. - Deprecate DMD makefiles. Seriously! Insist that contributors use the IDE bindings to work on DMD. - The fact that you all laughed at the prior point suggests clearly why it needs to be done. It will cease to be a problem when all the druntime/phobos contributors are suffering the end-user experience. * They should receive bugs in the main github bug-tracker, so EVERY D contributor can see them, and how many there are. IDE integration absolutely needs to be considered a first class feature of D. I also suggest that the IDE integration downloads should be hosted on the dlang download page so they are obvious and available to everyone without having to go looking, and also as a statement that they are actually endorsed by the dlanguage authorities. As an end-user, you're not left guessing which ones are good/bad/out of date/actually work/etc. Obviously, we settled on Visual-D (Windows) and Mono-D (OSX/Linux); the only realistic choices available. The OSX user would have preferred an XCode integration. Overwhelmingly, the biggest complaint was a lack of symbolic information to assist with auto-completion. Visual-D tries valiantly, but it falls quite short of the mark. This goes back to the threads where the IDE guys are writing their own parsers, when really, DMD should be able to be built as a lib, with an API designed for using DMD as a lib/plugin. I think continuous code compilation for auto-completion and syntax highlighting purposes should be a service offered and maintained by DMD. That way it will evolve with the language, and anyone can use it without reinventing the wheel. Debugging: Poor debugging experience wastes your time every 5 minutes. I can only speak for the Windows experience (since we failed to get
Re: Had another 48hr game jam this weekend...
On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote: We have to get the user experience and first impressions under control... I'd really love to to see a general roadmap and list of priorities. Even if goals are high-level, they might help direct focus? So I had another game-jam this weekend with a bunch of friends who are all industry professionals. The point of a 48 hour game jam is to prioritise productivity and creativity. Choosing a language like D here makes sense from a productivity point of view... that is, if it 'JUST WORKS'™. There were 7 programmers, they were all using D for the first time (except me). Most running windows, one on OSX, one on Linux. We ran into the same problems old that have been giving me the shits as long as I've been using D. Configuring compilers: Naturally, this is primarily a problem with the windows experience, but it's so frustrating that it is STILL a problem... how many years later? People don't want to 'do work' to install a piece of software. Rather, they expect it to 'just work'. We lost about 6 hours trying to get everyone's machines working properly. In the context of a 48 hour game jam, that's a terrible sign! I just kept promising people that it would save time overall... which I wish were true. The only compiler you can realistically use productively in windows is DMD-Win64, and that doesn't work out of the box. We needed to mess with sc.ini for quite some time to get the stars aligned such that it would actually compile and find the linker+libs. Walter: DMD needs to internally detect installations of various versions of VisualStudio, and either 'just work', or amend sc.ini on its own. Or the installer needs to amend sc.ini. Either way, leaving it to a user to fiddle with an ini file just isn't acceptable. We had to google solutions to this problem, and even then, we had trouble with the paths we added to sc.ini; are spaces acceptable? Do they have quites around them?... I might also suggest that Microsoft supplied (ie, 'standard'), libraries should be automatically detected and path entries added in there too: C:\Program Files (x86)\Microsoft SDKs\... C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\... These are on basically every windows developers machine, and each of us had to configure them ourselves. Getting a workable environment: Unsurprisingly, the Linux user was the only person happy work with a makefile. Everybody else wanted a comfortable IDE solution (and the linux user would prefer it too). ! This has to be given first-class attention! I am completely and utterly sick of this problem. Don made a massive point of it in his DConf talk, and I want to re-re-re-re-re-re-re-stress how absolutely important this is. ! I have come to the conclusion that treating IDE integration as ancillary projects maintained by usually just one single member of the community has absolutely failed. I suggest: * These should be made central D community projects. * I think they should be hosted in the same github organisation as DMD. *** As many contributors as possible should be encouraged to work with them every day. - Deprecate DMD makefiles. Seriously! Insist that contributors use the IDE bindings to work on DMD. - The fact that you all laughed at the prior point suggests clearly why it needs to be done. It will cease to be a problem when all the druntime/phobos contributors are suffering the end-user experience. * They should receive bugs in the main github bug-tracker, so EVERY D contributor can see them, and how many there are. IDE integration absolutely needs to be considered a first class feature of D. I also suggest that the IDE integration downloads should be hosted on the dlang download page so they are obvious and available to everyone without having to go looking, and also as a statement that they are actually endorsed by the dlanguage authorities. As an end-user, you're not left guessing which ones are good/bad/out of date/actually work/etc. Obviously, we settled on Visual-D (Windows) and Mono-D (OSX/Linux); the only realistic choices available. The OSX user would have preferred an XCode integration. Overwhelmingly, the biggest complaint was a lack of symbolic information to assist with auto-completion. Visual-D tries valiantly, but it falls quite short of the mark. This goes back to the threads where the IDE guys are writing their own parsers, when really, DMD should be able to be built as a lib, with an API designed for using DMD as a lib/plugin. I think continuous code compilation for auto-completion and syntax highlighting purposes should be a service offered and maintained by DMD. That way it will evolve with the language, and anyone can use it without reinventing the wheel. Debugging: Poor debugging experience wastes your time every 5 minutes. I can only speak for the Windows experience (since we failed to get
Re: Had another 48hr game jam this weekend...
On 2013-09-01 02:05:39 +, Manu turkey...@gmail.com said: I might re-iterate my feeling that external IDE integration projects should be claimed by the community officially In my opinion the community is just too short on man-hours. I did integrate D with Xcode at one point (no autocompletion though) and created an all-in-one installer for the compiler and the Xcode plugin. It just worked. I don't maintain it anymore and Xcode 4 broke it. It's open source so anyone in the community could have taken it further, but so far this hasn't happened. I'm not using D anymore. I realized that with the time required to maintain the toolset (including installer and Xcode plugin) plus the time it'd take to make the language suitable to my needs (Objective-C integration, perhaps ARM support for iOS), all that by itself would probably be more than one full-time job. As all this meta-work would seriously get in the way of my actual work, I let it go. I'm not regretting that move. So I'm no longer using D, but I'm still hanging around here from time to time because there's always something interesting to read. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: Had another 48hr game jam this weekend...
Yes IDE should be built with the language :) D has bad IDE support that is why I read about D but don't actually use it...
Re: Had another 48hr game jam this weekend...
Sorry about the nonsensical reply, the web interface was acting up... this is the intended reply. On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote: The only compiler you can realistically use productively in windows is DMD-Win64, and that doesn't work out of the box. Why didn't you go with DMD-Win32? Because of OMF? implib and/or objconv is a hassle but probably less of a hassle than using the nascent DMD-Win64. Overwhelmingly, the biggest complaint was a lack of symbolic information to assist with auto-completion. Visual-D tries valiantly, but it falls quite short of the mark. This goes back to the threads where the IDE guys are writing their own parsers, when really, DMD should be able to be built as a lib, with an API designed for using DMD as a lib/plugin. Although I'm not convinced auto-completion is a vital feature (Microsoft's C++ IntelliSense is shit too), I agree that any time spent on custom parsers and best-effort semantic analysis is a complete waste of time. The only semantic analysis engine that is going to be sufficiently good for D is one from a compiler front-end. Apart from DMD, it's worth taking a look at SDC for this. some windows dev's want a CHM that looks like the typical Microsoft doc's people are used to. Those that aren't familiar with the CHM viewer; it's just HTML but with a nice index + layout tree. dmd2\windows\bin\d.chm The question came up multiple times; I don't think this should be an array... what containers can I use, and where are they?... Also, nobody could work out how to remove an arbitrary item from an array, or an item from an AA by reference/value (only by key). This code: foreach(i, item; array) if(item == itemToRemove) array = array[0..i] ~ array[i+1..$]; Got a rather 'negative' reaction from the audience to put it lightly... `std.algorithm.remove` provides both stable (preserves order, shuffles entire array down) and unstable (swaps with last element and shrinks by one) removal. However, Phobos does not make a habit of providing helpers for strictly O(n) algorithms, so the O(n) nature has to be made explicit by first getting the index with `std.algorithm.countUntil`. Removing a pair from an AA by value is also an exercise in linear search, and as such will not get a deceptive helper function. However, once range interfaces for AAs mature, such an algorithm can be composed trivially. Yes, we hit DMD bugs, like the one with opaque structs which required extensive work-arounds. struct MyStruct; MyStruct*[] = new MyStruct*[n]; I'm not sure this is a bug. How do you default initialize an array of structs you don't know the .init values of?
Re: Had another 48hr game jam this weekend...
On Sunday, 1 September 2013 at 03:17:29 UTC, Trent wrote: On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote: We have to get the user experience and first impressions under control... I'd really love to to see a general roadmap and list of priorities. Even if goals are high-level, they might help direct focus? So I had another game-jam this weekend with a bunch of friends who are all industry professionals. The point of a 48 hour game jam is to prioritise productivity and creativity. Choosing a language like D here makes sense from a productivity point of view... that is, if it 'JUST WORKS'™. There were 7 programmers, they were all using D for the first time (except me). Most running windows, one on OSX, one on Linux. We ran into the same problems old that have been giving me the shits as long as I've been using D. Configuring compilers: Naturally, this is primarily a problem with the windows experience, but it's so frustrating that it is STILL a problem... how many years later? People don't want to 'do work' to install a piece of software. Rather, they expect it to 'just work'. We lost about 6 hours trying to get everyone's machines working properly. In the context of a 48 hour game jam, that's a terrible sign! I just kept promising people that it would save time overall... which I wish were true. The only compiler you can realistically use productively in windows is DMD-Win64, and that doesn't work out of the box. We needed to mess with sc.ini for quite some time to get the stars aligned such that it would actually compile and find the linker+libs. Walter: DMD needs to internally detect installations of various versions of VisualStudio, and either 'just work', or amend sc.ini on its own. Or the installer needs to amend sc.ini. Either way, leaving it to a user to fiddle with an ini file just isn't acceptable. We had to google solutions to this problem, and even then, we had trouble with the paths we added to sc.ini; are spaces acceptable? Do they have quites around them?... I might also suggest that Microsoft supplied (ie, 'standard'), libraries should be automatically detected and path entries added in there too: C:\Program Files (x86)\Microsoft SDKs\... C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\... These are on basically every windows developers machine, and each of us had to configure them ourselves. Getting a workable environment: Unsurprisingly, the Linux user was the only person happy work with a makefile. Everybody else wanted a comfortable IDE solution (and the linux user would prefer it too). ! This has to be given first-class attention! I am completely and utterly sick of this problem. Don made a massive point of it in his DConf talk, and I want to re-re-re-re-re-re-re-stress how absolutely important this is. ! I have come to the conclusion that treating IDE integration as ancillary projects maintained by usually just one single member of the community has absolutely failed. I suggest: * These should be made central D community projects. * I think they should be hosted in the same github organisation as DMD. *** As many contributors as possible should be encouraged to work with them every day. - Deprecate DMD makefiles. Seriously! Insist that contributors use the IDE bindings to work on DMD. - The fact that you all laughed at the prior point suggests clearly why it needs to be done. It will cease to be a problem when all the druntime/phobos contributors are suffering the end-user experience. * They should receive bugs in the main github bug-tracker, so EVERY D contributor can see them, and how many there are. IDE integration absolutely needs to be considered a first class feature of D. I also suggest that the IDE integration downloads should be hosted on the dlang download page so they are obvious and available to everyone without having to go looking, and also as a statement that they are actually endorsed by the dlanguage authorities. As an end-user, you're not left guessing which ones are good/bad/out of date/actually work/etc. Obviously, we settled on Visual-D (Windows) and Mono-D (OSX/Linux); the only realistic choices available. The OSX user would have preferred an XCode integration. Overwhelmingly, the biggest complaint was a lack of symbolic information to assist with auto-completion. Visual-D tries valiantly, but it falls quite short of the mark. This goes back to the threads where the IDE guys are writing their own parsers, when really, DMD should be able to be built as a lib, with an API designed for using DMD as a lib/plugin. I think continuous code compilation for auto-completion and syntax highlighting purposes should be a service offered and maintained by DMD. That way it will evolve with the language, and anyone can use it without reinventing the wheel. Debugging: Poor debugging experience wastes your time every 5 minutes. I can only speak
Re: DMD 2.064 alpha windows build
Am 31.08.2013 20:58, schrieb Temtaime: You can get DMD source on DMD's github. I've read DMD backend license, so it forbids to distribute DMD itself. I've removed the archive. I'll investigate in LDC. it seems that the old malloc implementation was the source of the 2x speed difference between dmc and msvc build http://forum.dlang.org/thread/ktju8h$efb$1...@digitalmars.com so you're tcmalloc version is 2x faster or 4x?
Re: Replacing std.xml
On Thursday, 29 August 2013 at 18:58:57 UTC, H. S. Teoh wrote: On Thu, Aug 29, 2013 at 01:38:23PM -0400, Jonathan M Davis wrote: [...] Well, as I said, I couldn't remember exactly what the XML standard said about encodings, but if it can contain non-ASCII characters, then my first inclination is to say that it has to be UTF-8, UTF-16, or UTF-32 based on the fact that that's what we support in the language and in Phobos Take a look here: http://www.w3schools.com/xml/xml_encoding.asp XML files can have *any* valid encoding, including nastiness like windows-1252 and relics like iso-8859-1. Unfortunately, I don't think we have a way around this, since existing XML files out there probably already have all of these encodings are more, and std.xml is gonna hafta support 'em all. Otherwise we're gonna get irate users complaining why can't std.xml parse my oddly-encoded-but-standards-compliant XML file?! As this is not the first time I see it used as a reliable source, no, w3school is full of shit. Don't use that website when looking for precise high quality information.
Re: DMD 2.064 alpha windows build
Am 31.08.2013 20:58, schrieb Temtaime: You can get DMD source on DMD's github. I've read DMD backend license, so it forbids to distribute DMD itself. I've removed the archive. I'll investigate in LDC. btw: nedmalloc stated on its own homepage... http://www.nedprod.com/programs/portable/nedmalloc/ If you're running on an older operating system (e.g. Windows XP, Linux 2.4 series, FreeBSD 6 series, Mac OS X 10.4 or earlier) you will probably find it significantly improves your application's performance (Windows 7, Linux 3.x, FreeBSD 8, Mac OS X 10.6 all contain state-of-the-art allocators and no third party allocator is likely to significantly improve on them in real world results). so you're running an older OS?
Re: Had another 48hr game jam this weekend...
On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote: The only compiler you can realistically use productively in windows is DMD-Win64, and that doesn't work out of the box. We needed to mess with sc.ini for quite some time to get the stars aligned such that it would actually compile and find the linker+libs. I also spent a decent bit of effort getting Win64 to work, and I agree that this is something that DMD should attempt to bundle. It may not need to go as far as downloading VC express for you, but it should allow integration of an existing install during installation (and ideally post-installation as well). This is a pretty big deal IMO. When I was a newbie, issues with COFF vs OMF, coffimplib confusion, etc, were almost deal-breakers to me. I just couldn't get things easily working, and I'm sure many others see it the same way. Having Win64 gives us a chance to fix that, but it *has* to be integrated into the installer. The compiler should ideally detect that the VS linker / libraries are missing when you use -m64, and tell you how to download VS Express as well as directing you to a batch file bundled with DMD to update sc.ini. Going a step further, it'd be even nicer if -m64 was default but that's not feasible with external dependencies. However when it detects a library in an invalid format, it should inform you about the existence of coffimplib and a download link, as well as how this is necessary only when compiling 32-bit executables. I don't think that the core contributors realize how incredibly frustrating these issues are to beginners, and thus feel as if it's not something that needs to be solved. Getting a workable environment: Unsurprisingly, the Linux user was the only person happy work with a makefile. Everybody else wanted a comfortable IDE solution (and the linux user would prefer it too). ! This has to be given first-class attention! I am completely and utterly sick of this problem. Don made a massive point of it in his DConf talk, and I want to re-re-re-re-re-re-re-stress how absolutely important this is. ! I have to say, I don't see why you find this to be such a large issue. DMD is unique in the sense that it's the only thing I've ever been able to compile on Windows without running into many issues. So long as you have DMC installed, it just works. I've never had any makefile related issues on any platform. This is a big deal, as DMD evolves so rapidly that users should be able to get the git version with minimal effort, without having to download an IDE for it. Overwhelmingly, the biggest complaint was a lack of symbolic information to assist with auto-completion. Visual-D tries valiantly, but it falls quite short of the mark. This goes back to the threads where the IDE guys are writing their own parsers, when really, DMD should be able to be built as a lib, with an API designed for using DMD as a lib/plugin. I think continuous code compilation for auto-completion and syntax highlighting purposes should be a service offered and maintained by DMD. That way it will evolve with the language, and anyone can use it without reinventing the wheel. While yes, it would be wonderful if we could get DMD to do this (again, I don't think a lot of the core contributors realize just how incredibly important IDEs and perfect auto-completion are), it doesn't seem to be something likely in the short-term. That being said, I've actually found Mono-D to be excellent recently. It doesn't handle things like CTFE properly and other similar issues, but for my purposes it's worked rather well (that being said, I avoid mixins for the most part, largely due to this). Despite all this, I'm actually quite happy with Mono-D lately. One thing I've toyed with is the idea of using reflection for getting auto-complete information. I made a runtime reflection module (has a fair few issues still), and I wonder if it would be possible to use something similar for this purpose. Most modules could be cached, allowing us to build only the module you're altering. On top of that, some real-time parsing could be done for code modified since the last recompile (really it would need to primarily handle scanning for methods and variables). History completion from the current file, such as what editors like Sublime Text do, could perhaps be integrated to completely eliminate the issue of not being able to find a symbol in your auto-complete list. That would likely only kick in when it finds no results for anything else. Plus since you're recompiling frequently in the background, you would get early notifications of errors/warnings like you would in C#/Java. Ultimately though, I'm not sure if this would be updated fast enough (depends how long compiles take) to be feasible. Debugging: Poor debugging experience wastes your time every 5 minutes. I can only speak for the Windows experience (since we failed to get
Re: Had another 48hr game jam this weekend...
On Sunday, 1 September 2013 at 04:36:46 UTC, Manu wrote: I'm really don't like bugzilla as an end-user, but I'm not performing searching actions. As a reporter, I find it's needless friction between me and reporting bugs, and I consequently report perhaps half as many bugs as I would otherwise, because I need to open a slow website, and login with yet another account... I've always found Bugzilla to be terrible. I *still* have no clue how to actually find the latest opened issues. For my own personal stuff I use Jira ($10 for up to 10 users or free for open source projects) and I find it to be an excellent issue tracking system. The ability to create an issue just by simply pressing 'c' on any page is wonderful and things load fairly fast from my experiences. That being said, I don't see D changing away from bugzilla any time soon, if ever. And honestly, there are much bigger priorities.
Relative imports and separate compilation
I've gone on TDPL and the language reference here but still don't
get relative imports. I've isolated it to this:
./package1/package2/foo.d:
import std.stdio;
void doFoo() {
writeln(Foo!);
}
./main.d:
import package1.package2.foo;
void main() {
doFoo();
}
This works:
dmd -c main.d
dmd -c package1/package2/foo.d
dmd main.o foo.o
This does not:
dmd main.d package1/package2/foo.d
main.d(1): Error: module foo from file package1/package2/foo.d
must be imported as module 'foo'
The only way I know of to make it work in the 2nd case is to use
a module declaration at the top of foo. Which is what I've been
doing so far.
How to relative imports actually work?
Atila
Any trick for defining an operator overload in a different namespace?
I'm trying to achieve the syntax opts[...] = 123, rather than using
the more direct this[...] = 123. I can use this code:
-
class C
{
this()
{
opts = Opts(this);
opts[foo] = 1;
}
struct Opts
{
C c;
void opIndexAssign(T)(T value, string option)
{
c.assign(option, value);
}
}
Opts opts;
private void assign(string option, int value)
{
}
}
void main()
{
auto c = new C();
}
-
But this explicitly stores the 'this' reference in the struct, I was
wondering if anyone knows of a trick to avoid having to do that. As
you can tell I just want a more convenient operator-based syntax over
calling the 'assign' method, but I don't want the operator to live in
the class space itself (because then I'd have to use this[...] =
that, which is a little quirky for my taste).
Re: A little of coordination for Rosettacode
Jos van Uden: It's an old task (from 2007). The task description was changed after the D entries were made. Yes, there are about 63 Rosettacode tasks that I have not yet updated: accumulator_factory.d address_of_a_variable.d animation.d boolean_values.d call_a_function_in_a_shared_library.d collections.d concurrent_computing.d create_an_object_at_a_given_address.d create_a_file.d date_format.d delete_a_file.d distributed_programming.d echo_server.d environment_variables.d execute_a_system_command.d execute_snusp.d file_io.d first_class_functions_use_numbers_analogously.d flow_control_structures.d formal_power_series.d fractal_tree2.d globally_replace_text_in_several_files.d hello_world_graphical.d http.d image_noise.d include_a_file.d input_loop.d json.d literals_floating_point.d literals_string.d memory_layout_of_a_data_structure.d metered_concurrency.d multiple_distinct_objects.d mutex.d object_serialization.d opengl.d parallel_calculations1.d pointers_and_references.d pragmatic_directives.d quine.d rc_24_game.d rename_a_file.d rosetta_code_count_examples.d scripted_main.d secure_temporary_file.d shell_one_liner.d simple_windowed_application.d singleton.d sockets.d synchronous_concurrency.d system_time.d test_a_function.d user_input_text.d variables.d variable_size_get.d variable_size_set.d walk_a_directory_non_recursively.d walk_a_directory_recursively.d window_creation.d xml_dom_serialization.d xml_input.d xml_output.d xml_xpath.d Bye, bearophile
Re: PyD status and tutorials
Ok python3-dev was missing. Now, it is a gdc problem: [code] def: hello wrap_struct: 'RangeWrapper' class.def: __iter__ class.def: next wrapped_struct_init, S is 'struct pyd.make_object.RangeWrapper' library_dirs: [] runtime_library_dirs: [] libraries: [] gdc -fPIC -nostartfiles -shared -fdebug -o build/lib.linux-x86_64-3.3/hello.cpython-33m.so build/temp.linux-x86_64-3.3/infra/temp.o -Wl,-soname,hello.cpython-33m.so /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.8/libgphobos2.a(object_.o): relocation R_X86_64_32S against `_D10TypeInfo_m6__initZ' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-linux-gnu/4.8/libgphobos2.a: error adding symbols: Bad value collect2: error: ld returned 1 exit status error: command 'gdc' failed with exit status [/code] This line is a mess to manage.. : [code] /usr/lib/gcc/x86_64-linux-gnu/4.8/libgphobos2.a: error adding symbols: Bad value [/code] Does anyone has a clue on what has to be done ? I am on a Debian sid 64bits system.
Re: Problem with rdmd
On 2013-08-30 09:39, eles wrote:
On Linux 64
$chmod +x htest
$cat ./htest
#!/usr/bin/env rdmd
import std.stdio;
void main() {
writeln(hello world!);
}
then:
$./htest
Error: cannot read file ./htest.d
Failed: 'dmd' '-v' '-o-' './htest.d' '-I.'
OTOH:
$cp htest htest.d
$./htest.d
hello world!
It seems that rdmd expects the script to bear the .d extension. This is
not a very good choice, at least when writing git helper scripts.
For example, a $git command command would eventually try to execute
the executable (script):
$git-command
The problem is that that line expects git-command, not git-command.d.
A workaround for this?
Why don't just compile it manually once instead of using like a script?
--
/Jacob Carlborg
Re: Problem with rdmd
On Friday, 30 August 2013 at 13:32:25 UTC, eles wrote: On Friday, 30 August 2013 at 11:34:59 UTC, Jacob Carlborg wrote: On 2013-08-30 09:39, eles wrote: I'm pretty sure it's DMD that is the problem. Yes. But that's, the least to say, limiting. This: https://github.com/D-Programming-Language/tools/blob/master/rdmd.d#L160 should be solved in other manner. Maybe creating a temporary copy. Or forcing dmd in some ways. Besides, for what reasons dmd would impose a .d extension? This is an ancient dmd misfeature - it treats `dmd test` as `dmd test.d`, adding .d silently. No idea if someone actually wants this behavior..
Re: Relative imports and separate compilation
On Saturday, 31 August 2013 at 09:29:16 UTC, Atila Neves wrote: How to relative imports actually work? Atila Actually for me it looks like it is a bug in automatic module name deduction. It should always use full qualified name built from directory path from closest import folder (set by -I , current working directory by default) to actual module file. So behavior observed in separate compilation case is correct one - don't know what actually happens in second case.
Re: PyD status and tutorials
On Sat, 2013-08-31 at 12:56 +0200, Larry wrote: Ok python3-dev was missing. Are you using Python 3.3? Are you using SCons or Tup for the build? I just tried the SCons build OOTB and it fails to build PyD with DMD :-( -- 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 signature.asc Description: This is a digitally signed message part
Re: Any trick for defining an operator overload in a different namespace?
On 08/31/2013 03:07 AM, Andrej Mitrovic wrote:
I'm trying to achieve the syntax opts[...] = 123, rather than using
the more direct this[...] = 123. I can use this code:
-
class C
{
this()
{
opts = Opts(this);
opts[foo] = 1;
}
struct Opts
{
C c;
void opIndexAssign(T)(T value, string option)
{
c.assign(option, value);
}
}
Opts opts;
private void assign(string option, int value)
{
}
}
void main()
{
auto c = new C();
}
-
But this explicitly stores the 'this' reference in the struct, I was
wondering if anyone knows of a trick to avoid having to do that. As
you can tell I just want a more convenient operator-based syntax over
calling the 'assign' method, but I don't want the operator to live in
the class space itself (because then I'd have to use this[...] =
that, which is a little quirky for my taste).
This is the limitation of inner structs' not having an 'outer'
reference, right?
Even if that were automatically available, it would still need a
reference similar to your explicit 'c' reference. I think... :)
Ali
Re: Any trick for defining an operator overload in a different namespace?
On 9/1/13, Ali Çehreli acehr...@yahoo.com wrote:
This is the limitation of inner structs' not having an 'outer'
reference, right?
Right, but this was just a workaround. Anyway I did just realize I can
use opDispatch for this:
-
class C
{
this()
{
this.opts[foo] = 1;
}
private auto opDispatch(string field : opts)()
{
return this;
}
private void opIndexAssign(T)(T value, string option)
{
assign(option, value);
}
private void assign(string option, int value)
{
}
}
-
It might seem a little funny that the only thing it does is just
returns 'this', which we already had. But I wanted to avoid writing
'this[foo] = 1;'. Well at the end of the day this may or may not be
what I wanted, since I still want to hide opDispatch. Oh well.. :)
unserialize variants
Hi, i want to save data from an array of variants into a file. I saw that to!string format the array content in a nice way... There is a way of converting the resulted string back to an array of varianta? thanks, Bogdan
[Issue 10933] New: findSplitBefore/After should have needle-less overloads
http://d.puremagic.com/issues/show_bug.cgi?id=10933
Summary: findSplitBefore/After should have needle-less
overloads
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: jakobov...@gmail.com
--- Comment #0 from Jakob Ovrum jakobov...@gmail.com 2013-08-30 23:26:46 PDT
---
`find` has an overload that doesn't take a needle but requires an unary
predicate function. `findSplitBefore` and `findSplitAfter` should have
equivalent overloads.
Test illustrating use:
unittest
{
import std.algorithm : findSplitBefore;
import std.uni : isWhite;
import std.string : stripLeft;
immutable tests = [
prefix postfix lorem ipsum,
prefix\tpostfix lorem ipsum
];
foreach(test; tests)
{
auto result = test.findSplitBefore!isWhite();
assert(result[0] == prefix);
assert(result[1].stripLeft() == postfix lorem ipsum);
}
}
It would be especially useful because `until` is strictly lazy and thus can't
be used with slicing to reproduce the above results.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10881] Support %f formatting for a std.complex.complex
http://d.puremagic.com/issues/show_bug.cgi?id=10881 monarchdo...@gmail.com changed: What|Removed |Added CC||monarchdo...@gmail.com --- Comment #12 from monarchdo...@gmail.com 2013-08-31 00:20:49 PDT --- (In reply to comment #11) (In reply to comment #10) Commit pushed to master at https://github.com/D-Programming-Language/phobos Now using this formatting string, for the given matrix: [%([%(%1.3f, %)],\n %)]] It outputs: [[0.707+0.000i, 0.707+0.000i, 0.000+0.000i], [0.000-0.707i, 0.000+0.707i, 0.000+0.000i], [0.000+0.000i, 0.000+0.000i, 0.000+1.000i]] For anybody reading this on forum.dlang.org: please view the entry on the bug tracker: There *is* a space that prefixes those lines, and they are all actually perfectly aligned. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10466] Optional [] syntax for std.range.iota too
http://d.puremagic.com/issues/show_bug.cgi?id=10466 Joseph Rushton Wakeling joseph.wakel...@webdrake.net changed: What|Removed |Added CC||joseph.wakel...@webdrake.ne ||t --- Comment #6 from Joseph Rushton Wakeling joseph.wakel...@webdrake.net 2013-08-31 00:34:59 PDT --- (In reply to comment #4) Hmm, iota with FP gets tricky, because, for example, 0.1 does not have an exact representation in floating-point. So if you write iota(0.0, 1.0, 0.1), it's unclear whether 1.0 will be included or not (for example, you may end up with 0.8 and it gets included, or it may end up with 1.001 and get excluded). Surely that should be a case of, use with FP at own risk. There are cases where it might be useful, but as with all things, you need to understand the possibility of rounding error. I got bitten rather amusingly by such an example where I was doing a for () loop across [0, 1] in 0.1 increments. GDC and LDC can handle that, DMD couldn't, and I had to switch to increments that were negative powers of 2. If you can trust the user to implement a for () loop correctly, you can trust them to do the same with iota(). Bottom line -- iota() currently does allow FP numbers and excluding them would be a breaking change. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10893] Numerous DDoc parameter warnings in Phobos (as found by 10236)
http://d.puremagic.com/issues/show_bug.cgi?id=10893 Lionello Lunesu lio+bugzi...@lunesu.com changed: What|Removed |Added Keywords||pull --- Comment #2 from Lionello Lunesu lio+bugzi...@lunesu.com 2013-08-31 00:43:25 PDT --- https://github.com/D-Programming-Language/phobos/pull/1536 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10919] typeof should accept types
http://d.puremagic.com/issues/show_bug.cgi?id=10919 Temtaime temta...@gmail.com changed: What|Removed |Added CC||temta...@gmail.com --- Comment #3 from Temtaime temta...@gmail.com 2013-08-31 01:45:50 PDT --- I'm agree with Timon. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10230] Duplicated buttons for runnable examples
http://d.puremagic.com/issues/show_bug.cgi?id=10230 --- Comment #2 from github-bugzi...@puremagic.com 2013-08-31 02:50:23 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/87bd3315db559ecca11e3bf69ac0410a16da7d8b fix Issue 10230 - Duplicated buttons for runnable examples https://github.com/D-Programming-Language/phobos/commit/aa3b13ce49c84c6cae35541c72a4f44d785c49f9 Merge pull request #1328 from 9rnsr/fix10230 Issue 10230 - Duplicated buttons for runnable examples -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10466] Optional [] syntax for std.range.iota too
http://d.puremagic.com/issues/show_bug.cgi?id=10466 --- Comment #7 from bearophile_h...@eml.cc 2013-08-31 03:25:36 PDT --- (In reply to comment #6) Bottom line -- iota() currently does allow FP numbers and excluding them would be a breaking change. I understand the general meaning of your words, and I could agree, but at the moment there is no D code around shaped as iota!(](0.0, 1.0, 0.3), so formally there is no breaking. A code breaking change is when code that used to work suddenly stops working or silently has a different semantics. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10819] Invalid comparison for equality of lambda functions
http://d.puremagic.com/issues/show_bug.cgi?id=10819 --- Comment #7 from Peter Alexander peter.alexander...@gmail.com 2013-08-31 03:53:53 PDT --- (In reply to comment #6) This is probably total overkill, but what about instead of mangling to __lambda + an incrementing integer, replace the integer with the SHA hash of the lambda's AST tree? As Andrei said, we cater only to the case where the two lambdas are token-for-token identical, because the general problem of equivalence between two arbitrary lambdas is uncomputable. That works but is it OK for the lambda type to not have a module? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10555] enumerator can no longer increment beyond maximum of initializer
http://d.puremagic.com/issues/show_bug.cgi?id=10555
Henning Pohl henn...@still-hidden.de changed:
What|Removed |Added
CC||henn...@still-hidden.de
--- Comment #3 from Henning Pohl henn...@still-hidden.de 2013-08-31 04:16:03
PDT ---
I think this behaviour is correct:
Spec:
If the EnumBaseType is not explicitly set, and the first EnumMember has an
initializer, it is set to the type of that initializer. Otherwise, it defaults
to type int.
Named enum members may not have individual Types.
A named enum member can be implicitly cast to its EnumBaseType, but
EnumBaseType types cannot be implicitly cast to an enum type.
The behaviour before issue 3096 always used int as EnumBaseType even though
there is a first initializer.
enum A // int
{
A0
}
enum B // A
{
B0 = A.A0,
B1
}
In this case the base type of B is A and A does not have a member whith a value
of 1.
enum A // int
{
A0
}
enum B // A
{
B0 = A.A0,
B1 = A.A0 + 1
}
This is basically the same case as above.
enum A // int
{
A0
}
enum B // int
{
B0 = A.A0 + 0,
B1
}
This works because the type of the first initializer is int. So the base type
of B becomes int and ints can be incremented easily.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
